ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-03 Issue 25: Re: Recap Issues 0b/21/25

2007-04-30 14:22:03

David F. Skoll wrote:

| 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.
[...] 

+1
 
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.

SHOULD, should, recommended, or RECOMMENDED, what's going to happen
with those huge log files, apart from deleting them by a cron-job ?

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.)

Yes, but it's your proposal to say "SHOULD bounce" instead of the
"MUST bounce" in 2821.  I fear that this is another a loophole to
avoid real (and painful) solutions, based on "reject at the border".

I wouldn't be happy if an SPF PASS ends up in a log file deleted by
a cron job.  Maybe your SHOULD needs a qualifier:  "If the receiver
cannot validate the return-path then" etc.  

Or "if the receiver cannot assess the validity of the return-path"
etc.  This needs some wordsmithing, it could be also "if the 
receiver isn't in a position where it can assess the plausibility".

For the "normal" case (in my parallel universe that's an SPF PASS
or a similar case :-) I'd like to keep the "MUST bounce" as it was.

Frank