I wrote:
> > b) Such a "probe failed" message MUST NOT be sent with MAIL FROM:<>
> > In fact, RFC821 is very clear that e-mail messages are supposed to
> > have a good reverse-path
> > [..]
> > and later the exception of bounces is introduced with the words
Roger Fajman <[EMAIL PROTECTED]> writes:
> RFC 821 isn't the whole story on this issue. Other RFCs have introduced
> the principle that some messages may be sent with a null MAIL FROM.
Ok, but still there is no RFC which would allow any software product to
start sending arbitrary kinds of error messages with a null envelope
sender.
> RFC 1894 states that Delivery Status Notifications (DSNs) are to be sent
> with a null MAIL FROM address. While a DSN may be a bounce message, it
> may also be a report of successful delivery. RFC 2298 states that
> Message Disposition Notifications (MDNs) are also to be sent with a
> null MAIL FROM address.
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.
