John C Klensin wrote:
[David Skoll]
A proper failure report SHOULD consist of a notification sent
to the Return-Path of the original message. Where this is not
possible (because of a blank Return-Path) or not desirable
(because the Return-Path is untrusted for local policy
reasons), the server MUST record enough information for a
human operator to reconstruct the nature of the delivery
failure, the original Return-Path and the addresses of the
original recipients.
Without commenting on whether or not this is the best approach,
or even a good idea, one could probably replace the strong
clause starting with ", the server MUST..." with some words that
non-normatively advised that behavior. There are two problems
with the strong version: one is that it would be a new
requirement, as you suggest and the second is that we have
carefully avoided imposing requirements on post-delivery (or
post-acceptance) behavior such as logging because such behavior
is not observable on the wire.
OK; fair enough. I think, though, that if we're going to make it
permissible to silently drop undeliverable messages (which is what
people want to avoid backscatter but is IMO totally against the spirit
of the original RFC), then we must put something in writing that says
what a well-behaved server is expected to do. I could live with a
SHOULD.
If we avoid defining what a "proper failure report" is and leave it up
to SMTP implementors, I fear that e-mail will become completely
unreliable (instead of somewhat unreliable as it is today.)
Regards,
David.