Hi, there's a fresh attempt in the IETF to promote RFC 2821 (SMTP)
and 2822 (mail) to "draft standards", the second step in the IETF
standards process. Full standard (STD) is the third step, at the
moment RFC 821 belongs to STD 10, and RFC 822 is STD 11.
The actual drafts 2821bis-03 and 2822upd-01 are available at
<http://tools.ietf.org/html/draft-klensin-rfc2821bis> and
<http://tools.ietf.org/html/draft-resnick-2822upd>
The drafts are discussed on the traditional ietf-smtp and ietf-822
lists shown on <https://datatracker.ietf.org/public/nwg_list.cgi>:
<http://www.imc.org/ietf-smtp/> and <http://www.imc.org/ietf-822/>
The lists are also available on GMaNe, see <http://news.gmane.org>
If you for some reason or another feel that something with mail is
not as it should be, and if you're willing to review these drafts,
then now would be a good time to chime in.
Example for folks interested in Sender-ID, the 2822upd draft still
says that Resent-* header fields MUST NOT be used in "other such
automatic actions on messages".
Example for folks interested in misdirected bounces, the 2821bis
draft still favours accept instead of reject, and mandates to send
non-delivery reports to the originator as indicated in the reverse
path.
Example for folks interested in NetNews, the 2822upd draft still
allows control characters (NO-WS-CTL) and unnecessary "quoted-
pairs" (backslash escapes) in Message-IDs.
Example for folks interested in SPF, the 2821bis draft still does
not clearly admit that the RFC 821 alias-forwarding to 3rd parties
was designed for an SMTP with "return routes", and whatever that
was, it was killed by RFC 1123 together with the "source routes".
So there are some "minor" points in these drafts which should be
relevant for most readers of this list. Please help to get it
right this time. Don't let them get away with "it's as it is, and
we can't change it because a promotion to 'draft standard' doesn't
allow serious fixes." RFC 3986 and RFC 3629 are examples where
serious fixes worked, and if all else fails a fixed new "proposed
standard" is better than any broken by design "draft standard".
Frank
-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com
and 2822 (mail) to "draft standards", the second step in the IETF
standards process. Full standard (STD) is the third step, at the
moment RFC 821 belongs to STD 10, and RFC 822 is STD 11.
The actual drafts 2821bis-03 and 2822upd-01 are available at
<http://tools.ietf.org/html/draft-klensin-rfc2821bis> and
<http://tools.ietf.org/html/draft-resnick-2822upd>
The drafts are discussed on the traditional ietf-smtp and ietf-822
lists shown on <https://datatracker.ietf.org/public/nwg_list.cgi>:
<http://www.imc.org/ietf-smtp/> and <http://www.imc.org/ietf-822/>
The lists are also available on GMaNe, see <http://news.gmane.org>
If you for some reason or another feel that something with mail is
not as it should be, and if you're willing to review these drafts,
then now would be a good time to chime in.
Example for folks interested in Sender-ID, the 2822upd draft still
says that Resent-* header fields MUST NOT be used in "other such
automatic actions on messages".
Example for folks interested in misdirected bounces, the 2821bis
draft still favours accept instead of reject, and mandates to send
non-delivery reports to the originator as indicated in the reverse
path.
Example for folks interested in NetNews, the 2822upd draft still
allows control characters (NO-WS-CTL) and unnecessary "quoted-
pairs" (backslash escapes) in Message-IDs.
Example for folks interested in SPF, the 2821bis draft still does
not clearly admit that the RFC 821 alias-forwarding to 3rd parties
was designed for an SMTP with "return routes", and whatever that
was, it was killed by RFC 1123 together with the "source routes".
So there are some "minor" points in these drafts which should be
relevant for most readers of this list. Please help to get it
right this time. Don't let them get away with "it's as it is, and
we can't change it because a promotion to 'draft standard' doesn't
allow serious fixes." RFC 3986 and RFC 3629 are examples where
serious fixes worked, and if all else fails a fixed new "proposed
standard" is better than any broken by design "draft standard".
Frank
-------------------------------------------
-----------------------------------------------------------------------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735
Powered by Listbox: http://www.listbox.com