On Oct 14, 2004, at 16:11, Greg A. Woods wrote:
>> Oh, I can come up with an excuse, all right (basically, a fair amount
>> of phishing/spam is sent "From: postmaster@..." -- with alarming
>> subjects like "your account will be disabled" etc..; there is
>> backscatter).
> Well, first of all it's _extremely_ rare (for now, at least in my
> experience) for such junk to be sent with a null return path.
You keep missing the point. It is not about the original spam; the
issue is the "backscatter" (a.k.a. collateral spam) generated by
post-SMTP spam/virus filters elsewhere. These send a DSN to the
original sender addresss (in some cases, that could be
"postmaster@???").
> In any case that's still _not_ a valid excuse for rejecting the mail
> transaction.
According to "rfc-ignorant.org" it is
(
http://rfc-ignorant.org/policy-postmaster.php):
Further, if a postmaster address is inbound-only, (i.e., it is never
used in any of the following: SMTP Envelope From, RFC 2822 'From'
Header, or the RFC 2822 'Sender' header), then it is permissible under
our policy to reject mail to the postmaster address from the
null-envelope ('<>'). It is acknowledged by RFC-Ignorant that there are
plenty of legitimate reasons why '<>' would be sending a message to
<postmaster>, but they are not that prevalent in the field.
> If you need/want to block that kind of junk then there are a zillion
> other better and more effecitive ways to do so which don't also block
> legitimate use by human testers, etc.
Not really. It is much harder to weed out collateral spam from
legitimate DSNs.
For "real" users, it can be done with "envelope sender signatures" -
i.e. attach a hash or cryptographic letter sequence in the "MAIL FROM:"
address of outgoing mail:
MAIL FROM:<woods=signature@???>
On incoming DSNs (i.e. mail with no envelope sender), you check this
signature; if valid, send it to the user. Otherwise, you reject the
mail.
A side benefit/issue is that DSNs to "postmaster" would also be
rejected.
Or maybe you make this scheme optional for your users, but then
outright reject incoming DSNs to "system" users and aliases such as
"postmaster", "root", "daemon", etc. (Bounces should not go to these;
they don't send outgoing mail).
> As I'm sure you're awayre RFC 2505 is only a "Best Common Practice"
> guideline. :-)
Yep. As far as I am concerned, there is no "best" about many of the
practices proposed.
> The SMTP envelope must be the sole domain of the MTA and a sane MTA
> will
> not allow applications to set a null return path, be they privileged or
> not. Confusing the layers here is the kind of mistake that has lead to
> much of the recent insanity of ill-begotten bogus attempts at sender
> address verification.
I don't get this. Sender Address Verifcation (in Exim terminology
"Sender Callout Verification") never happens on NULL senders. These
are automatically accepted (sans other checks).
(Note, I am not trying to defend such verifications - they are dubious
in any case - but I simply do not get the connection between this
mistake and the mistake of allowing applications to set NULL return
paths...)
> The envelope sender address has one and only one purpose in SMTP, and
> that's to give _an_ address where error reports are to be sent by
> another MTA. The null return path is only to be used when by an MTA
> sending a delivery error report. Attempts to read _anything_ more into
> the authenticity of a sender address, or the use of a null return
> path, is simply wrong.
Precisely. That's why it is perfectly OK to reject NULL senders in for
inbound-only addresses (like, usually, "postmaster").
> Furthermore unless your MTA explicitly blocks relaying of any message
> transaction attempting to use <postmaster@???> then you
> cannot say authoritatively that no mail is ever sent from your
> domain(s)
> using the postmaster mailbox as the return path. :-)
Aw! That hurt.
You are right; I will institude this check right away.
-tor
