james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@thought.co.uk>
Subject RE: SPAM handling.
Date Fri, 01 Mar 2002 13:56:18 GMT

we could put bad hosts into a blacklist and then send "571 host.domain has
been blacklisted contact postmaster@me.com" next time a blacklisted machine
connected (5xx is permanent error, i.e. "go away and stay away" BTW)

we could also parse message headers and test originating and intermediate
hosts ourselves too, returning 471 to the DATA command when they are
untested, and 571 when any of them are blacklisted.

And if we combined this with public blacklists it might be quite ferocious.

I think we need to test the reaction of other MTA's to various errors, after
all we need non ETRN MTA's to try again if they get 471.

I suspect we need to attach mailet processing to SMTP handling as well as
spool processing in order to use the mailet API in this role and to make
configuration consistent with the spool mailet processing.

I also think that we could extend the mailet API to allow this kind of
config to be supported..

<processor protocol="SMTP">
<handler command="MAIL" match="All" class="SMTPMAILHandler">

This would allow us to develop a clean set of overlapping command handlers,
more than one for each SMTP Verb, and matched against the contents of the
command where necessary.

Then we can do user checking, vhosts, and other stuff in an independant,
extensible and versatile way.

Something like this could validate users before mail is recieved (only
simpler I hope :)..

<handler command="RCPT" match="All" class="SMTPRCPTHandler">
	<domain name="thought.co.uk">
       <repository name="LocalUsers"

	<domain name="apache.org">
      <repository name="list-james"


Obviously it would help clarify things if we could have..

1/ a seperate config for domains and their mail & user repositories
2/ a seperate config for each protocol
3/ fewer Global parameters (after all postmaster and servernames in a vhost
setting are relative to the host you are pretending to be)

Just some thoughts..


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message