Mailing List Archive: SPF: Discuss

FYI: 2821bis and 2822upd

Index | Next | Previous | View Threaded

nobody at xyzzy

Apr 29, 2007, 6:31 PM

Post #1 of 2 (820 views)
Permalink

FYI: 2821bis and 2822upd

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

julian at mehnle

May 1, 2007, 7:19 AM

Post #2 of 2 (762 views)
Permalink

Re: FYI: 2821bis and 2822upd [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> 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.
>
> [...]
>
> 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, thanks a lot for your initiative!

Unfortunately I currently do not have enough time to fight those battles
myself, even though I recognize that it is important.

Thus, the least I can do is to encourage other participants of this list
(spf-discuss) to help Frank setting things right with RFC 2821bis and RFC
2822upd.

So, please, anyone, if you have the time, pick one or two of the issues
Frank mentioned and that you personally consider important (I'm sure Frank
will gladly point out more!), join the ietf-smtp and/or ietf-822 lists,
and try to get them fixed!

Julian.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGN0yAwL7PKlBZWjsRAlU4AKCF0pN5AdtEvLWPZsANlSg7GGpdhwCfacei
Y/t5vxI/wxIcbPaVqqceQMQ=
=58im
-----END PGP SIGNATURE-----

-------------------------------------------
-----------------------------------------------------------------------
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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads