On Mon, Jun 9, 2014 at 12:06 AM, Hector Santos <hsan...@isdg.net> wrote: > On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote: >> >> >> To express how strong I feel about this.... >> >> If there is a charter for a new DMARC WG work, you can bet I will >> request that any form of 5322.From-Corruption concept be >> considered OFF TOPIC and OUT OF SCOPE in the new WG charter except >> to be aware of intentional From-Corruption is to be considered a >> new security exploit and threat to be mitigated. And for the >> record, I will also appeal any IETF work that begins to suggest >> From-Corruption concepts as a means to bypass security protocols. >> I will appeal it. >> >> Setting aside for the moment how premature this threat is given that >> there's not even a skeleton charter under proposal right now, > > > Its better to get this bud nipped now.
Yes, always best to act before thinking about the problem Always best to make sure that the group considers only the problem it is allowed to consider. How can the IETF be a consensus organization if people are allowed to block consideration of alternatives? My understanding of the remit of this group is to consider what to do about the DMARC situation. The reason I proposed looking at changing the mailing list scheme is that the DMARC 'discussion' consists of one group of folk saying 'we have to stop this' and another pointing out that it has already happened. Most Internet users do not care whether mailing lists work or not. So expecting them to accept tons of spam from criminals trying to cheat them to preserve the equivalent of vinyl records is not going to succeed. The Internet does not have a rule that the people who got here first make the rules. There is a traffic jam in Cambridge/Boston several times a day as the lifting bridge opens to let some plutocrat sail his yacht through at rush hour. Several thousand people have to wait half an hour to get to work for one person to enjoy their hobby. I think that is a rotten and selfish way to run things. So given the fact that DMARC is causing problems for mailing lists we should not automatically assume that the solution is to change DMARC. I think that this point is completely on topic for a pre-WG list that is discussing ways to address a problem. Chances are that the conclusion is going to be that NO DMARC WG is formed because the people using DMARC are not interested in the changes that are going to be proposed. Mailing lists are not an optimal solution. They have high administrative burdens, the mail they send is often caught in spam filters because a mailing list is a bulk sender. These problems were recognized when NNTP was designed. Though as Dave Crocker points out, flood filling is hardly an approach we should endorse for the modern Internet. But given that we have the attention of Google and Yahoo here we do have the critical mass that could make a major change in mailing list technology stick. And it is to their interest to do so. So I am not just proposing a better solution, I am proposing a solution that has more chance of being adopted. Though since 'shut DMARC down because we says to' is not going happen pretty much anything has a better chance of deployment. >> I >> suggest you read Section 6.5 of RFC2026 to figure out what the >> official basis would be for such an appeal. > > > Murray, > > Fundamentally, any From-Corruption (good term to use) concept is bad. 30 > years of mail software/product/hosting development across multiple networks > tells me so, it ethically burns inside me as wrong and I have strong > confidence the IETF/IESG wise ones will agree. I hope you agree too. > > You will need to add security information to your DMARC document as this > From-Corruption concept would be a security exploit that can potentially get > by RFC5322 validation checks that can hurt DMARC publishers and create bad > PR for the DMARC protocol itself. DMARC receivers will need to be warned. > > You will need to provide guidelines for mitigating it, not for allowing it > unless there is an explicit policy defining language authorizing it, and > even then, that can be cracking open a loophole. > > You may want to make it a boundary layer check thing. The exploit will need > to be described just like it was done for DKIM's Double From situation with > RFC5322 validation checks done at receivers. > > Consider it a "to-do" note for when the anticipated official DMARC WG > begins. > > Thanks > > -- > Hector Santos, CTO > http://www.santronics.com > > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
