On Nov 9, 2014, at 1:19 AM, Franck Martin <fra...@peachymango.org> wrote:
> ----- Original Message ----- >> From: "Douglas Otis" <doug.mtv...@gmail.com> >> To: "Franck Martin" <fra...@peachymango.org> >> >> Dear Franck, >> >>> Note that an email with no RFC 5322 field is not valid, as well as one with >>> more than 1. This header is mandatory as well as the Date header. These >>> are the only 2 headers mandatory in an email. >>> >>> So rejecting an email with no RFC 5322 or more than one is just following >>> the RFC. >> >> Which normative RFC is that? > > see table under http://tools.ietf.org/html/rfc5322#section-3.6 Dear Franck, This table defines a message format accompanied with an SMTP caution not to reject messages based on perceived structural errors. Prior to DKIM creating a security hole in its mandated From header field signing, repeated From header fields often simply resulted from poorly automated responses. Since such errors directly affect DKIM's protection of header fields, DKIM should considered such messages as having invalid signatures. This would allow subsequent processes an ability to use results headers without re-examining message structure, nor does such overlooked checks appear in the Authentication results header field. >>> I'm not talking on how many mailboxes/domain there are in this header >> >> It would be wrong to assume SMTP will reject messages based on possible >> RFC5322 violations. > > While SMTP implementations have been lenient, they have been lenient in a way > which is contrary to this RFC. It is not contrary. SMTP is a store and forward protocol exchanging messages over MTAs having changed little over decades. There is no practical way to negotiate format changes, such as those created by RFC 6854 for example. For SMTP to evolve, some change must be allowed. Where the change is known to place the integrity of DKIM signatures at risk, the signatures should not have been considered valid. Although a simple configuration switch offers a low overhead solution, ignoring this change was a deliberate choice made by DKIM. > The Postel statement indicates to be lenient when there is protocol > ambiguity, not to allow anything but the kitchen sink when the protocol is > clear about what headers must be present. Why not fix the problem in the algorithm walking the header field stack from the bottom up during signature validation? It makes little since to now say all such errors should be rejected. > Therefore it is not wrong to assume SMTP will reject messages on protocol > violations. It is a protocol violation to reject messages because of some perceived error. It would not be a protocol violation to assert a DKIM signature is invalid. With that change, Authentication results headers could be trusted without subsequent processing. Why expect recipients to process messages a second time? Get it right the first time, especially where doing so is only a software switch in most cases. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
