Frank Ellermann wrote:
Eliot Lear wrote:
I would be curious as to what needs "fixing" before it
becomes a full standard
The issues you find when you enter "2616" in the form at
http://www.rfc-editor.org/errata.html That sends you to
the outsourced http://purl.org/NET/http-errata
I now understand what you mean by outsourced. Most of these comments
are truly editorial in nature, but that happens with FULL standards as
well. See, for instance, 3414.
Long hard work went into 2821 to correct known problems.
Try the URL mentioned above and enter 2821. Some issues
fixed in the 2821bis draft, some missing, others are not
formally listed as errata, but you could find them in the
SMTP list archive (some weeks in 2005).
All of those are typos that people can work around without great
difficulty. However, the below is not:
You've to read 2821 very often to find the most important
point between the lines, not mentioned clearly: _Never_
accept mail unless you're sure that you can deliver it or
bounce it to the originator (which is today rarely related
to anything you see in the MAIL FROM).
Otherwise, following the official 2821 rules, what you do
would be net abuse by design: Either you drop accepted
mail silently, or you bounce it to innocent bystanders.
Unlike the old 821 SMTP, where it still worked as designed.
Of course 2821 couldn't fix 1123 5.3.6(a) anymore, but at
least 2821bis has to document it very clearly.
Between the lines, "let's assume the MAIL FROM is related
to the originator", won't fly, that's not true anymore for
several years now.
There are many instances when an MTA can and should accept mail when it
is not known to be deliverable. The most obvious example is when it is
acting as an MSA. And I do not understand why you believe that it is
rarely if ever related to the originator. It is certainly the case for
nearly every mail I send or receive. The only question is who is the
originator in the case of mailing lists, and that is well covered.
Mailing lists SHOULD modify the mail from because the originator in
those cases may have no responsibility for having sent the mail to the
address that caused the error.
Are you saying that RFC 2821 inadvertently perturbs this behavior?
Eliot
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf