> On Feb 10, 2015, at 11:02 AM, Franck Martin <[email protected]> wrote: > > From: "Murray S. Kucherawy" <[email protected]> > To: "Franck Martin" <[email protected]> > Cc: "Tim Draegen" <[email protected]>, "dmarc" <[email protected]>, > [email protected] > Sent: Tuesday, February 10, 2015 9:43:52 AM > Subject: Re: [dmarc-ietf] interoperability draft for review > > On Tue, Feb 10, 2015 at 12:33 AM, Franck Martin <[email protected]> > wrote: > > I don't believe the use of X-Original-From is described in any RFC > > currently. > > If we're going to talk about it in section 4.3 we need to talk about how > > it's actually used or refer to some place that does. > > it is RFC5703 > > That's Original-From, so I guess just mention that the X- version was the > pre-standardization name and might still be in use in some places. > I'll check the text but there is something like this. > > Aside: I'm surprised that RFC5703 doesn't include the registration template > required by RFC3864. > It is listed here: > https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers
Dear Franck, Nice Draft. After attending a conference dominated by what could be described as mass mailers, few expressed concerns about DMARC's impact on often popular uses of email. As such, the draft http://tools.ietf.org/html/draft-otis-dmarc-author-align was written to bring forward plausible approaches to deal with problems created by large user email providers abusing DMARC. There really needs to be better solutions than overriding a domain's “reject” with “quarantine”. From an email compatibility perspective, having a domain level assertion (that could be similarly overridden) permitting alignment with the Sender header field when present would spur change in how MUAs expose header fields playing a significant role in message handling. Such a change may take a period of time before this method is sufficiently supported. In the meantime, many users are finding themselves retrieving legitimate messages out of their spam folder which is teaching the wrong lesson. Alternatively, DMARC could take a bold step and redefine roles of the header fields by introducing a new header field able to carry non-aligned Author roles. With DMARC, the From may be unable to retain its traditional role. By adding a header field “Author" (instead of X-Original-From) not inadvertently exposed by an MUA to unwary users, this would allow mailing-lists and international email addresses necessary sanctuary from DMARC’s overly simplistic policy scheme. It is not 2005 anymore. We are seeing bot-nets take advantage of any weakness found or induced with DKIM or SPF. We are working on better methods for detecting BGP injections, and attempting to correlate similar abuse methods. It is really unfortunate there are cases where DKIM remains vulnerable. It also seems many of the vulnerabilities being exploited are also more than 1 year old. This situation would be improved by offering a comprehensive definition of a valid DKIM signature. No spec is perfect. Once one realizes what it takes to detect BGP injections, SMTP/DANE begins to look much better. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
