Lisa Dusseault wrote:
Charter-bashing should be done *early* if you disagree
Okay. Fixing the known errata and bugs - there are quite a lot -
in RFC 2821 is a good idea, and there should be no major issues
with this goal.
One of the major problems with RFC 2821 is that it's too long.
It could be an idea to extract all legacy features into a new
"history" document: SEND, SOML, SAML, HELO, source routes,
reverse paths (excl. the cases still in use today), anything
else in appendix F (e.g. TURN), and probably more (e.g. EXPN).
After the cruft has been removed from the picture in a history
document updating RFC 2821 it will be easier to tackle the rest.
However there's no way that this rest can be a "draft standard"
without fixing another major problem in RFC 2821, the design
flaw to favour "accept and bounce" instead of "reject".
In an ideal world "try to deliver as long as there's a chance
that it works out" is a good strategy. In the real world with a
spam ratio near 80% - and most spam uses forged reverse paths -
"in case of doubt reject a.s.a.p." is a good strategy. And any
"accept on probation because it's always okay to bounce later"
strategy is today considered as net abuse.
I don't see how a future 2821bis can swap this fundamental - and
today known to be wrong - assumption of RFC 281, the "accept and
bounce" before "reject" axiom, and still be a "draft standard".
And what should a future 2821bis do with 3.10.1, in essence the
same as 1123 5.3.6(a) ? It's at the core of the "forged reverse
path" issue, related to the removal of source routes in RFC 1123.
Just because RFC 2821 inherited this design flaw it's still a
design flaw, costing billions of dollars, and intentionally NOT
fixing it in a DS is a legal hazard and poor engineering.
Frank