Re: [exim] Callouts, NULL DSN

On Mon, 22 Aug 2005, Steve Brown wrote:

> Okay, so why would one ever do a sender callout rather than just
> *always* doing a header_sender callout?

As far as an MTA is concerned (for example, if it has to create a
"bounce"), the envelope-sender is the critical address. What appears
in mail headers is of only secondary concern to it, as the MTA itsef
wouldn't use those addresses for itself - they are for a human
recipient, not for the MTA itself. In the case of spam, these
addresses are sometimes very, very different from each other.[0]

If our MTA needed to create a "bounce" it would, of course, create it
with a null sender, so in this case we are particularly interested in
the response of the relevant MTA to a null-sender callout. That all
hangs together.[1]

If (as seems to be traditional for Chinese MTAs, for example) it
refuses null senders on principle, then we know we'll never be able to
send a "bounce" to it, so we know that reliable mail exchange with it
isn't possible: so, generally speaking[2], we err on the safe side and
set things up for it to reject our callouts, which in turn means that
we tell it that their sender verification has failed, goodbye.

(Sure, there are a few rogue MTAs closer to home which behave that way
too, but where we'd have some reason to want to hear from them, and
that reason might be strong enough to override our normal reluctance
to accept mail from such a rogue. In the past this has been the case
for some potential sources of research funding, for example: our
manglement would not have been happy if we'd rejected their mail on
such grounds, or even if we had tried to throw the RFCs at them!).

hope that's useful


[0] most recent example in the rejection log, an envelope-sender of
www-data@??? with a From: header which read:
From: info@??? <zwulff@???>

Hmmm... fortunately, that header fails syntax checks, so we didn't
need to bother spamassassin with the content of this pink stuff...


[1]Conversely, a real user would be expected to reply to a header
address using their own address as sender. Users manually creating
mail with a null sender is improper. So if you want to verify a header
"from" or other kind of header sender address under realistic
conditions, it would be logical to do the callout with a non-null
sender. One that you're not going to try a callout on when the remote
MTA tries it back at you, naturally.


[2]Just to recap that we don't simply throw sender verification
callouts at every mail offer that we get: we use them selectively,
typically where the caller domain is in a local list of domains where
callout has been proved efficacious to reduce spam and other kinds of
abuse. We *do* understand that callouts in response to spam, where
envelope senders are widely faked, represent a certain level of misuse
of a third-party's MTA, and that it would be rude of us to over-use
that facility, so we try to repel spam on other grounds first; but we
do feel that on balance a controlled use of callouts is the lesser
evil, compared with the potential consequences of accepting such faked
mails. Only today we had a naive user, despite our best efforts at
education, trying to reply to a fraudulent mail (fortunately, the
reply failed) *and* visiting the cited fraudulent web page, where an
exploit was waiting to catch any unpatched victim. Only then did the
user ask for advice from support staff. Ouch! We now know that if
this item's envelope sender domain had been in our callouts list, the
callout would have caused it to be rejected.