Andy Fletcher wrote:
>
..[snip]...
>
> As above, make a decision whether you'd happy to let that 5xx at MAIL TO
> time slip by, as you may want to verify sender regardless of the remote
> server rejecting/accepting a null MAIL TO.
This cannot be done in any kind of safe way, as pointed out before, the
reasons for NULL senders in callouts is to a see if NDR's can be delivered,
and two, to prevent callout loops, how do you propose to not inject callout
loops if this were the example:
S => server, C => client
(for simplicity sake both are MX MTA's for the respective domain)
**CASE 1 HOW IT WORKS NOW**
C connects to S
S OK ESTMP ready
C HELO client.domain
S OK
C MAIL FROM:<user@???>
**** Now the callout starts ****
S connects to C
C OK ESMTP ready
S Helo server.domain
C OK
S MAIL FROM:<>
C 550 Bad Sender
S QUIT
**** Now the callout is done ****
S 550 Sender Rejected
C QUIT (or new mail from or noop, or whatever ;)
**CASE 2 WHAT SOME HAVE WANTED**
C connects to S
S OK ESTMP ready
C HELO client.domain
S OK
C MAIL FROM:<user@???>
**** Now the callout loops start ****
**** Server does callout ****
S connects to C
C OK ESMTP ready
S Helo server.domain
C OK
S MAIL FROM:<>
C 550 Bad Sender
S MAIL FROM:<user@???>
**** Client now does callout ****
C connects to S
S OK ESMTP ready
C Helo client.domain
S OK
C MAIL FROM:<user@???>
**** Server does callout ****
--see above---
**** Client does callout ****
--see above--
**** Callout loop never ends ****
Yes that is a simple example, and arguments such as , my server accepts
MAIL FROM:<> is not an answer to stoping the loop, as once you give someone
the ability to define the MAIL FROM: command used, they will, and some will
never try a NULL sender before trying something else. So how would you
propose to keep this from hapening?
> I suppose this is changing
> the purpose of what the sender callout was for (I gather it was to check
> bounces can be delivered), but as we've seen in responses to the list,
> that's not what it seems to be used for so much now.
This takes us WAY away from what the sender callout checks were intended
for. All they were originally intended for (from what I have read or seen
Phillip say), is to determine if an NDR could be delivered to the address
given in the MAIL FROM: command, that is it.
As nice as it would be, sender callouts by themselves cannot and should not
be used to try and find UCE or Malware of any kind, as there are just too
many systems that have one of two problems (if not both):
1. they accept everything and DNR after the DATA regardless of a valid
recipient user.
2. They do not accept MAIL FROM:<>, thus rejecting ALL NDR's from others
Trying to determine if a connection is sending SPAM just by that one check
is not rational.
There are many easy Perl modules/scripts that could be used for more
deterministic approaches as to what kind of email another system would
accept, or use a run command to a shell script to do this. Sure it won't
use exim db cache but you could build your own.
I do sender callout checks, but do not reject on this alone, I add it a
list of things that get checked for every connection, such as proper helo,
proper DNS, etc, if you fail too many checks then I reject the message. I
have found that is a lot easier to tell a client that we did not accept
email from so-and-so because they have no DNS PTR, the helo given was bob,
and we could not verify the sending address because they rejected the NULL
sender so they will not accpet NDR's, etc, etc, etc.
--
--EAL--
