Dave Crocker wrote:
Anything in rfc2821bis that attempts to deal with message rejection
on the basis of rules that are not absolutely required, for core
functioning of the service, should be dropped from the spec, since
they already fail to represent consensus behaviors.
I very much doubt that the alternatives like removing RFC 1123 5.3.6a,
or rather the corresponding section 3.9.1 in 2821bis, as a "technical
oversight" (in 1123), is anywhere near to a consensus.
Attempting to write new rules will be difficult, if not impossible,
will take a long time, and probably would require moving the draft
back to Proposed.
The STD 10 alternative "in any case, the SMTP adds its own identifier
to the reverse-path" also won't fly, even if that's no "new" rule.
Nothing's wrong with a PS addressing the issues experienced by many
email users daily. Everything's wrong with a DS _not_ addressing
the core SMTP issues. There's a complete chapter in BCP 72 outlining
what might need to be addressed.
Dropping text, however, is simple and let's the draft proceed to
Draft.
If the IESG etc. allow this. OTOH a "if in doubt reject a.s.a.p."
is only a consequence of "the originator of the undeliverable mail
(as indicated in the reverse-path)". That wasn't obvious enough
in 2821, it should be made as obvious as possible in 2821bis, no
matter what its status will be:
The SMTP _cannot_ accept responsibility for delivery if both the
forward-path and the reverse-path are unverified. There's even
an error code 551 for a part of this problem, specified in STD 10:
551 User not local; please try <forward-path>
This reply indicates that the receiver-SMTP knows the user's
mailbox is on another host and indicates the correct
forward-path to use. Note that either the host or user or
both may be different. The receiver refuses to accept mail
for this user, and the sender must either redirect the mail
according to the information provided or return an error
response to the originating user.
Frank