At 12:26 AM +0900 4/12/07, Stephen J. Turnbull wrote: > I think it's odd that RFC 2821 section 3.6 fails to mention that it > contradicts RFC 1123 section 5.2.2. Nor does RFC 2821 claim to > supersede or update RFC 1123 or STD 3. The fact that in both 3.6 and > throughout section 5 it implausibly restricts primary names to A RRs > (omitting IPv6 AAAA RRs) suggests to me that there was a long > political battle, and everybody was too tired to even kick the tires > to make sure there was air in them before publishing the RFC. :-/
I was on the DRUMS working group for a while, and I know that there's a lot of stuff that fell through because of certain interpersonal conflicts between some of the individuals involved. It got to the point where my contributions were nothing but taking the opposite position of another person on the WG, regardless of what their positions were. That was the point at which I decided it was no longer practical for me to remain on DRUMS, although since that particular individual had long-running arguments with several other people, I have to assume that the same sort of thing continued even after I left. > Late-breaking news: somebody who I suspect knows what they're doing > agrees with me that RFC 2821 should say it updates RFC 1123: > > >http://mirror.switch.ch/ftp/mirror/internet-drafts/draft-klensin-rfc2821bis-01.txt I'll have to take some time to read that properly. Now is not that time. > Well, it is required by RFC 1123, but RFC 2821 clearly envisions a > world where CNAMEs are always resolved by the client at the time of > contacting the server, with the exception of the ELHO command, which > must already be a primary host name. That does seem likely, but that is also a paradigm shift from the first twenty-something (or whatever) years of Internet e-mail, and there's going to be a very long time before most MTAs implement the new behaviour. In the meanwhile, we have to continue to deal with the issue of the old behaviour. > I believe that the restrictions on address fields in messages in RFC > 2822 format are much weaker, ie, purely syntactic. There's no reason > to suppose that the MUA will have an Internet connection or be > available to revise addresses if the MTA doesn't like them; on the > other hand, the MTA should not rewrite headers. The MTA needs to rewrite headers that the MTA needs to rewrite. The question is which headers should the MTA be rewriting? -- Brad Knowles <[EMAIL PROTECTED]>, Consultant & Author LinkedIn Profile: <http://tinyurl.com/y8kpxu> Slides from Invited Talks: <http://tinyurl.com/tj6q4> ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
