[Top] [All Lists]

Re: Advancing RFC2821 to Draft Standard -- outline of work

2007-01-22 23:54:21

At 17:15 -0500 on 01/22/2007, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote about Re: Advancing RFC2821 to Draft Standard -- outline of work:

Would tagging "accept and bounce" as a SHOULD NOT (with appropriate text
attached) be doable without resetting back to Proposed?  I know "MUST NOT"
would cause such a reset, and even I'm not ready to stick *that* label on
"accept and bounce" - mostly because I've spent too much time working with
large-scale mail systems where the mailbox *was* valid when we sent the
far end the '250 OK', but had been race-conditioned into oblivion by the
time actual final delivery was attempted.

IMHO, so long as you validate at receive time that the Return-Path (that is eventually going to end up getting used to send the Bounce to due to an recipient email address that was valid at receive time going invalid in the time span before you attempt final delivery situation [as you state in the above quote]) is valid and an accurate reflection of where the message is coming from, I do not see any problem with as being a SHOULD NOT but allowed with that "Valid the Return-Path" IF YOU SUPPORT IT caveat.

<Prev in Thread] Current Thread [Next in Thread>