Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





SM wrote:
As this draft is being considered as a Proposed Standard, will it be authoritative instead of RFC 5821/5322?

This presumes that there are different semantics or syntax offered by them.

What inconsistencies are you seeing, specifically, so we can fix them.

Again, we should note that 5322 and 5321 have their own redundancies and
opportunities for inconsistencies.

Would that Postel and I had coordinated better for 821/822, but alas we didn't. At the time, I thought we did, but it's been clear for a long time that we didn't.

I remember wondering about that at the time, but certainly had no concept of the long-term hassles it would cause.

Kinda makes one appreciate the benefit of being more careful. We probably should have taken another 10 or 15 years to figure it out...


In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are used to
refer to structured fields of a message. I prefer Header.From and SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC 5322 are updated. There was a similar discussion about the replacement for message/rfc822 in the EAI Working Group.

As I recall, the choice of "rfc#." versus "acronym." or "std#." was discussed during development of the draft. Perhaps separately, but it has come up in recent years.

From what I've seen, folks generally seem to prefer using the RFC number. Personally, I'd prefer acronym#, although the other side of not having to make changes when there's a new RFC is not being sure whether the meaning has changed...


In the Security Considerations Section (6.1):

"As mentioned in Section 4.1.4, it is common practice for components of this
architecture to use the [RFC0791].SourceAddr to make policy decisions
[RFC2505], although the address can be "spoofed"."

As the focus of the draft is email architecture, this doesn't fit under security considerations.

Email-arch discusses implications in various places. From what I've seen, the IETF's security geeks vastly prefer having extra Security Considerations, rather than missing important ones. And in terms of advising the community about security holes in email, more is definitely better. So I'd rather see this tidbit retained.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]