----- Original Message ----- > From: "Hector Santos" <[email protected]> > To: "Franck Martin" <[email protected]>, [email protected] > Sent: Wednesday, April 29, 2015 11:26:06 AM > Subject: Re: [dmarc-ietf] New Version Notification for > draft-ietf-dmarc-interoperability-02.txt > > I think overall, there are two concerns I have: > > 1) The over estimated use of the idea for "rewriting" and > 2) the word or term "common" is used for mitigation methods. > > Common means most and its not the case. Rewriting is a major industry > taboo, in all mail or communications concept. Just because one or two > renegade MLM wrote a kludge for their site, puts it on a wiki, does > not make it legit at all, not one iota.
I would avoid the words "renegade" and "kludge". I think you could better phrase the above paragraph. I'll tone down the use of common, however I'd like to point: 1)Google Groups and Yahoo Groups are doing rewriting, if not mistaken, to cite only one data point, these are large deployments. 2)Common, as in the sense, many MLM software have the option today. Will make it more clear in the doc > > The doc infers that RFC6377 provides guidance, and it immediate jumps > to a Rewriting "common mitigation policy." Thats not right. In fact, > RFC6377 preaches ADSP or in general the DKIM Policy framework. I > don't support Rewriting, its not common, its not a BCP. It reeks with > IETF appeal problems. I don't think the doc should legitimize any > idea of rewriting. In the realm of things to do to fix the issue, I think rewriting is an operationally used technique on several lists, but I have no data how popular it is compared to other methods. However, and I think this is your point, many more did not change anything and have to manually deal with the issues. I know a few ticketing systems that have done rewriting before DMARC existed. Anyone wants to comment or has data on what people did? I think this may be helpful. Looking for more guidance. > > Other comments... > > The doc should make a note that DMARC is an informational status > domain. It is not a proposed standard nor a BCP. It is very > incomplete and it is missing lots of considerations. The 3rd party > issues was intentionally in an attempt to avoid a complex design > issue, but that it could not avoid. yes it should be noted that [DMARC] is informational > > The doc fails to mention technical history with SSP ADSP, ATPS, or any > of the RFC documents products such as: > > rfc4686 Analysis of Threats Motivating DKIM > rfc5016 Requirements for a DKIM Signing Practices Protocol > rfc5518 Vouch By Reference > rfc5863 DKIM Development, Deployment, and Operations > > and possibly others. > > The docs should explain why ADSP was abandoned and why its "Super > ADSP" [sic] version called DMARC replaced it. I don't think the purpose of this doc is to describe history, but to explain what may break, how to avoid it, and what are the drawbacks of each solution, if any. https://datatracker.ietf.org/wg/dmarc/charter/ "Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them." "The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. " I think an history of email authentication would be interesting and could be an awesome informational RFC. Are you volunteering? _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
