> Ok, you are right that both DSNs and MDNs are further exceptions to the
> general rule that e-mail messages are supposed to have a valid, non-null
> reverse path.
>
> > Also note the following text in RFC 821:
> >
> > MAIL (MAIL)
> >
> > ... In some types of error
> > reporting messages (for example, undeliverable mail
> > notifications) the reverse-path may be null (see Example 7).
> >
> > This suggests that there could be messages other than bounces that
> > have a null MAIL FROM.
>
> Sure. This leaves room for later RFCs to introduce other kinds of error
> messages which can also be sent with a null reverse-path.
>
> But note the wording "In _some_ types of error reporting messages (...)
> the reverse-path may be null". This does not give any arbitrary software
> package the right to invent new types of error reporting messages and
> send them with null reverse path without having the new type of error
> reporting message properly reviewed and specified in an RFC so that
> people who develop spam filters (like e.g. Ron) and those who develop
> bounce-handlers (like e.g. me) and also developers of others kinds of
> software that might be affected by this are properly warned and enabled
> to make their software react properly to the new types of messages.
>
> So far, the only situation when an entity A can legally send something
> with null return path to another entity B is when A needs to make some
> kind of status report about an e-mail message (with non-null return
> path) which was sent by B.
>
> -- NB.
That is debatable, I think. There is no wording in RFC 821 that says
that only types of messages authorized by a standards-track RFC may use
a null MAIL FROM. When RFC 821 was written, spam did not exist, so the
issue wasn't considered. But even the draft revision to RFC 821 does
not take a firm position on this issue. See the document at
http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpupd-07.txt
The mailing list for the working group is [EMAIL PROTECTED] To be
added, write to [EMAIL PROTECTED] But the working group is
trying to get both this document and the RFC 822 revision out the door,
so it may well not want to consider this issue at this late date.
