Stuart D. Gathman writes:
Having gotten into the business of generating my own DSNs, I have
examined DSNs and replies from other mailer more carefully. I see that > the biggest offender for sending out replies instead of DSNs is Microsoft
SMTPSVC. The subject says "Delivery Status Notification (failure)", but
the MAIL FROM is <postmaster(_at_)example(_dot_)com> instead of <>. Ugh.
(Even worse, they don't reject the mail they are rejecting, but accept it,
then send it to me wrapped as a non-DSN claiming to be a DSN saying
"we don't want it".)
Heh. Almost a violation of RFC 1891:
(c) is stable, in that a failed attempt to deliver a DSN should never
result in the transmission of another DSN over the network,
however, definitely in direct violation of:
NOTE: A DSN MUST NOT be returned to the sender for any message for
which the return address from the SMTP MAIL command was NULL
("<>"), even if the sender's address is available from other sources (e.g.
the message header). -- snip!
but they could be attempting to follow the rest of the above paragraph:
However, the MTA which would otherwise issue a DSN SHOULD inform the
local postmaster of delivery failures through some appropriate
mechanism that will not itself result in the generation of DSNs.
at any rate its dodgy and non-standard behaviour likey because following
logically defined and imperative guidelines for writing Internet services
software isn't "User Friendly", but of course we expect nothing less from
our super friends over in Redmond.
Now, a question for all you rfc2821 gurus. If I translate
<postmaster(_at_)(_dot_)(_dot_)(_dot_)> to <> in an attempt to work around the M$
braindamage, what other problems will that cause? Since I sign
outgoing return paths, I would end up rejecting all direct (non DSN)
email from <postmaster(_at_)anydomain> (which is good when they come
from braindead M$ servers.) Is this a problem? Would someone ever
need to send me email (as opposed to a DSN) with a MAIL FROM of
<postmaster(_at_)(_dot_)(_dot_)(_dot_)>?
Well, if you don't care for what John Levine has to say (amazingly John uses
on occaison it seems, to send mail as "postmaster(_at_)abuse(_dot_)org" to at least one
mailing list that I know of), no probably not :-) There exist (or did
exist) a bunch of automated software (in the late 90's) that would
auto-generate responses that were failures to a request to perform some
abstracted (from SMTP) task such as creating a user account on a forum. I
noted a serious decline in this behaviour as the waves of mail to
"postmaster@" began. A quick browse of google returned an article about
TDMA's dealing with bounces from "postmaster@" where a user desires NOT to
bounce mail FROM "postmaster@":
http://mla.libertine.org/tmda-users/2003-01/msg00203.html
To the best of my knowledge there is no language stipulating that you must
accept RECEIPT of a mail FROM "postmaster@", its all bound to mail DESTINED
to. You do need to consider more than just 2821 however, if you haven't
already give RFC 1891 a read as it talks about ESMTP extensions which if
enabled alter the behaviour of DSN with behaviour such as requesting DSN's
etc. I would like to think that you read it in view of what you are
attempting to do, but I recall that I overlooked it initially when I was
looking into a similar but related issue where I was generating DSN's under
conditions where none was warranted and in one particular case where a DSN
generation was forbidden. Additionally I recall some stipulations that
differ between an email address with a single alias and one with multiple
aliases. At any rate I'm not even sure how involved you are in relation to
generating DSN's so perhaps you need not consider this at all. :-)
Cheers,
James
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------