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 [EMAIL PROTECTED] with a From: header which read: From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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. -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
