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&amp;file=faq01.027.htp

Reply via email to