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.