smtp server options - link to mod patch

[vi...@mdve.net]

Hi.  I wrote a couple of modifications to the James SMTP server / handler which 
help deflect Stuff Posing As Mail.

The mods consist of two additional options, and are controllable through boolean 
fields in the smtpserver section of the configuration XML file:

<!--  Uncomment this if you want to only accept recipients in the local domain. -->
<!--  Note that leaving this out will cause all recipients to be valid, but     -->
<!--  messages to other domains will still process per the above configuration, -->
<!--  usually to the spam log. Leave this off while debugging, but if you find  -->
<!--  a huge number of SPAM messages to other domains,                          -->
<!--  you might want to turn it on.                                             -->
<!--
<acceptOnlyLocal>true</acceptOnlyLocal>
-->

<!--  Uncomment this if you want to ensure a reverse DNS Hostname exists   -->
<!--  for the IP addresses of incoming connections.  Most legitimate email -->
<!--  will have a rDNS hostname defined, but often the casual spammer will -->
<!--  not.  Note that this will cause connectivity problems if a sender's  -->
<!--  hostname cannot be determined by IP, or if the DNS service is        -->
<!--  unreliable.                                                          -->
<!--
<doReverseLookups>true</doReverseLookups>
-->

The patch affects 4 files:
src/conf/james-config.xml
src/java/org/apache/james/smtpserver/SMTPHandlerConfigurationData.java
src/java/org/apache/james/smtpserver/SMTPHandler.java
src/java/org/apache/james/smtpserver/SMTPServer.java

The patch file is compared to CVS as of yesterday and available at:
http://www.mdve.net/jakarta-james/jakarta-james-cvsdiff.txt

The code is pretty tame, it works well for me and I don't think it introduces any bugs.

The James subproject is pretty new to me, so if there's a better way to do these, I 
beg forgiveness for wasting your time and request enlightenment on the Proper 
Way.  I see a lot of goofy connections and receive a lot of open relay tracers, these 
mods are helping me a lot.

I also have a mailet which drives a system command to add a rule to a firewall 
which blocks sending addresses, I can clean it up and post if there's any interest in 
this.

Roger Venable
roger@mdve.net



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: smtp server options - link to mod patch

[vi...@mdve.net]

In response to Noel:

Hi, I'm intrigued by the quick response.  It appears you understand my intentions 
perfectly... to short circuit undesirable traffic ASAP.

I desire the ability to use any filter conceivable, programmable, and available to me 
in order to block unwanted traffic.  In order to respond to various threats in a timely 
fashion, I also wish it to be dynamically configurable.  I am not sure if there's a way 
or plan to have the james VM reread it's configuration or enable and configure filters 
on the fly, but I can always restart the process.  Personally I wish Julian Haight at 
Spamcop.net would code up a nice mailet that sends incredibly nasty legal notices 
to the originator's ISP on spam detection.  I might have to think about that one.

Concerning the 'acceptOnlyLocal' option, this functionality exists in other mail 
services, and I hate leaving out options.  It does sound as if you've got  better 
mechanism for it planned.  It sends the immediate message that non-local mail is 
not accepted.  If disabled per default, the mail client program knows that the 
message did go into the system even if it doesn't get relayed.  This will not send a 
brain-dead kiddie-script operator the message that he shouldn't bother thwacking 
that server with a further 50K messages.  Sending back a 503 on RCPT will cause 
that error message, and he'll skip me for the next server on his hit list.

The 'doReverseLookups' is just another tool, and you are quite correct, one of 
limited usefulness.  Perhaps a much more verbose and explanatory text description 
of the option is in order, as it will indeed cause false positives and undetected 
negatives.  For the undetected negatives, hopefully another filter or the 
'acceptOnlyLocal' option will catch and kill them.  As for false positives, clearly this 
option should not be used for larger or more public servers where this could occur.  
However, for a more private server or one with less traffic, or where the majority of 
the traffic comes from known locations, this can be useful.  This still leaves open a 
source for public email input as opposed to a private AUTHed system.

A matcher which would be interesting would be the reverse of the 
InSpammerBlacklist, accessing a whitelist DNS server which contains only those 
servers from which we will accept traffic.  Does not require AUTH, but affords 
limited acceptibility.  The Habeas Users List would also fit this category ( 
InSpammerBlacklist supports the Habeas Infringers List very well ).  Rename 
InSpammerBlacklist and reverse the two return conditions.  This also sounds like a 
candidate for the new filtering in v3.  Chroot'ing a bind server and adding these 
whitelisted hosts is not difficult, but could be done within the code as well.

On the Firewall block mailet: the mailet I have is getting older by the word as I 
realize more clearly what needs to be done... a configurable command line string 
with replaceable token parameters for the desired IP to block, timeout in seconds, 
and any other pertinent data.  I'm using a small shell script to add iptables rules, and 
a daemonized perl script to time out the rules. I didn't think this mailet was 
particularly limited to use on Linux... although I don't know of other firewall 
mechanisms which permit rule addition/deletion via command line.  I would only be 
able to provide the Linux iptables example, not sure why ipchains wouldn't be 
extremely similar. This is still limited to Linux, can someone suggest a Windows 
possibility?

PATCH script in next email, but still available on http://www.mdve.net/jakarta-
james/jakarta-james-cvsdiff.txt

Thank you again for your response, it has helped me a great deal.

Roger Venable
roger@mdve.net



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: smtp server options - link to mod patch

["Noel J. Bergman" <no...@devtech.com>]

Roger,

> I beg forgiveness for wasting your time and request
> enlightenment on the Proper Way.

Hey, we all appreciate contributions and thoughts.  If I understand
correctly ...

  <acceptOnlyLocal>true</acceptOnlyLocal>

is an option for the SMTPHandler to disallow e-mail intended for relay at
all, rather than using SMTP AUTH?

  <doReverseLookups>true</doReverseLookups>

is an option that is intended to disallow e-mail from servers for which
there is not a valid reverse lookup?  The value of this is what?  Most of
the spam I see comes from systems that have valid reverse DNS; it just
resolves to a name related to a DHCP pool in Brazil or South Florida.  And
there are legitimate servers that don't have a DNS associated name.

My personal view is that the first patch is basically an incoming only
James, and that can be done already by the current configuration.  Just send
all e-mail not intended for local users to the Null mailet.  I do appreciate
the desire to cut things short earlier, and so I can see adding it to the
short-circuit filter mechanism in the works for James v3.  The second one
bothers me because it doesn't appear to be an effective filter from my own
experience.  Too many false positives, and too many negatives that aren't
detected.

So I am personally disinclined at the moment to use either of those two
changes as-is, although I'd tweak at least one of them to fit into the
filtering mechanism.

> The patch file is compared to CVS as of yesterday and available at:

Please post the patch to the mailing list.  :-)

> I also have a mailet which drives a system command to add a rule to a
firewall
> which blocks sending addresses, I can clean it up and post if there's any
> interest in this.

Please submit that one, too.  :-)

I've been doing that by hand in the past, and planned to add something like
it to the list of filters to provide a proper reject notice, rather than
block them at the firewall.  Is yours ipchains or iptables based?  Do you
handle timeout?  The firewall rule should expire, since many spam sources
are in DHCP pools.

I should note, however, an RFC violation.  There is a reason why the
solution I would put into the James distribution is in the SMTPHandler
filtering mechanism, and not in the firewall: it is a violation of RFC 2821
sections 3.6 and 4.5.1 to reject e-mail for postmaster except in the most
narrow of circumstances (DoS attack or attempted security breach).  By
blocking e-mail at the firewall, you are in violation of the RFC.  I don't
mind that you do, but I have questions regarding the degree to which James
should encourage RFC violations.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: smtp server options - link to mod patch

[Danny Angus <da...@apache.org>]

Pls could you post the patch to this list, that way it will be archived along with the mail..

d.

> -----Original Message-----
> From: visualecho@mdve.net [mailto:visualecho@mdve.net]
> Sent: 24 January 2003 17:53
> To: james-dev@jakarta.apache.org
> Subject: smtp server options - link to mod patch
> 
> 
> Hi.  I wrote a couple of modifications to the James SMTP server / 
> handler which 
> help deflect Stuff Posing As Mail.
> 
> The mods consist of two additional options, and are controllable 
> through boolean 
> fields in the smtpserver section of the configuration XML file:
> 
> <!--  Uncomment this if you want to only accept recipients in the 
> local domain. -->
> <!--  Note that leaving this out will cause all recipients to be 
> valid, but     -->
> <!--  messages to other domains will still process per the above 
> configuration, -->
> <!--  usually to the spam log. Leave this off while debugging, 
> but if you find  -->
> <!--  a huge number of SPAM messages to other domains,            
>               -->
> <!--  you might want to turn it on.                               
>               -->
> <!--
> <acceptOnlyLocal>true</acceptOnlyLocal>
> -->
> 
> <!--  Uncomment this if you want to ensure a reverse DNS Hostname 
> exists   -->
> <!--  for the IP addresses of incoming connections.  Most 
> legitimate email -->
> <!--  will have a rDNS hostname defined, but often the casual 
> spammer will -->
> <!--  not.  Note that this will cause connectivity problems if a 
> sender's  -->
> <!--  hostname cannot be determined by IP, or if the DNS service 
> is        -->
> <!--  unreliable.                                                 
>          -->
> <!--
> <doReverseLookups>true</doReverseLookups>
> -->
> 
> The patch affects 4 files:
> src/conf/james-config.xml
> src/java/org/apache/james/smtpserver/SMTPHandlerConfigurationData.java
> src/java/org/apache/james/smtpserver/SMTPHandler.java
> src/java/org/apache/james/smtpserver/SMTPServer.java
> 
> The patch file is compared to CVS as of yesterday and available at:
> http://www.mdve.net/jakarta-james/jakarta-james-cvsdiff.txt
> 
> The code is pretty tame, it works well for me and I don't think 
> it introduces any bugs.
> 
> The James subproject is pretty new to me, so if there's a better 
> way to do these, I 
> beg forgiveness for wasting your time and request enlightenment 
> on the Proper 
> Way.  I see a lot of goofy connections and receive a lot of open 
> relay tracers, these 
> mods are helping me a lot.
> 
> I also have a mailet which drives a system command to add a rule 
> to a firewall 
> which blocks sending addresses, I can clean it up and post if 
> there's any interest in 
> this.
> 
> Roger Venable
> roger@mdve.net
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>