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 12:45:59 GMT
Paul,

It doesn't get round open relays, anyone administering a mailserver should
know enough to prevent it from relaying, if they don't then there's a good
chance they won't know how to configure it to use CALL-ME-BACK.

I like the idea, but think it should go like this:

FYI here is a conversation I just logged

<quote>
220 mx3.dircon.net ESMTP Mirapoint 1.1.0; Fri, 1 Mar 2002 12:11:57 GMT
EHLO tarbolton.demon.co.uk
250-mx3.dircon.net Hello tarbolton.demon.co.uk [212.229.119.215], pleased to
meet you
250-8BITMIME
250-SIZE 31457280
250-DSN
250-ETRN
250-AUTH LOGIN
250-AUTH=LOGIN
250 HELP
ETRN thought.co.uk
250 Queuing for node thought.co.uk started
</quote>

this forces the server to send what it has queued for thought.co.uk but not
to us, it sends it to the correct host for that domain..
The old TURN command could be used to hijack other peoples mail, Coo what a
faux pas :-)

What we need to do is have a response to MAIL or HELO or EHLO that tells the
original to go away while we ponder its worth, we can then call it and use
ETRN

so looking at rfc 1893 we find these two paras:
<quote>
4.X.X   Persistent Transient Failure

       A persistent transient failure is one in which the message as
       sent is valid, but some temporary event prevents the successful
       sending of the message.  Sending in the future may be successful.

X.7.1   Delivery not authorized, message refused
          The sender is not authorized to send to the destination.
          This can be the result of per-host or per-recipient
          filtering.  This memo does not discuss the merits of any
          such filtering, but provides a mechanism to report such.
          This is useful only as a permanent error.
</quote>

from which we cobble together this response:
471 host.domain is not authorised to deliver here we need to validate your
credentials, we will call back and use ETRN once we have succeded
which suggests that the sender should give up, but may try again

So ..
then we take the IP of the machine we've just been talking to, plus its HELO
name and check them using whatever tools we want (DNS, abuse lists, try an
SMTP connection, whatever you can think of,
our server would add this server to a list of approved hosts, which might
usefully have a TTL attached so we don't trust them forever.

and then we would call back using ETRN to make them send again what they
have for us, only this time their machine is in our little list
and they get through, or we ditch the ETRN altogether and wait until they
try again themselves.

How about that? it should succede where servers support ETRN, but also where
they dont, and whats more we can protect ourselves without relying on other
people.

Its not more than a partial answer tho.

d.





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


Mime
View raw message