[dmarc-ietf] Comportment on this list
Colleagues, The IETF has some written guidelines about management of and conduct on mailing lists. In particular, the IETF's anti-harassment policy [1] and a number of RFCs [2] [3] [4] [5] and IESG statements [6] [7] form the body of the IETF's guidelines and procedures regarding mailing list management. Although this mailing list is not presently associated with a working group, its management and policies are covered by several of these. The recurring theme among them is that the lists are to be used for technical or procedural discussion to advance a particular goal, and professionalism is expected of participants. When the debate veers off topic or into anything from the plainly impolite to the patently personal, it serves only to interfere with any progress that's being made. Multiple posts from the last 24 hours certainly have the feel of being outside of what's acceptable. In at least one case, it has resulted in a formal complaint from another participant, which has led me here as one of the two list administrators of record. I understand that it might be fun or even cathartic to beat up on people who disagree with your position, or on those who are members of the DMARC.org cabal, or any of the other the people you may wish to blame for the mess in which we find ourselves, but I believe we are all better served by cooperating to find a path forward from where we are now rather than engaging in those activities. Learning from the past is fine; pointing fingers about the past is not. Thus, I am reminding all of you of your obligation to keep this discussion professional, on topic, respectful, and friendly. You do neither yourself nor the community any favors by giving in to the temptation to be rude or one-up the other person when you get frustrated. It will not be tolerated here going forward. -MSK, list admin [1] http://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html [2] RFC 2418 [3] RFC 3683 [4] RFC 3934 [5] RFC 4633 [6] http://www.ietf.org/IESG/STATEMENTS/statement-disruptive-posting.txt [7] http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection
Hello John, what you're missing -- and its easy to miss -- is that Yahoo has an outstanding offer to help developers (this means $!) fix things. Really, that makes no difference. I don't want Yahoo or anyone else to pay us to screw up our mail software to work around them -- I want them to spend their money to fix things so we don't have to. Yahoo, in their own blog, estimates there are 30,000 mail systems that they have damaged by their DMARC actions. I would be surprised if there were more than a few hundred mail systems acting on DMARC policies, although some of those are very, very large. Is it that hard to understand why someone might think it was unreasonable to demand that the 30,000 make changes of no benefit to themselves, rather than the few hundred fix their buggy fussp? The 30K estimate is probably low, since there are likely many small mail systems they aren't aware of but that they are damaging. For example, yesterday a middle school teacher who found my old Dummmies web site wrote to me out of the blue to say that his web form that lets students and parents send mail to him stopped working for AOL and Yahoo addresses, which just disappear. It took about two seconds to figure out what was wrong when he told me that his script sends mail to his Gmail account. I told him what was wrong, and he did a hack that sticks in a fake From: address, so the mail gets through but now his script works worse since he can't write back without extra effort. If he hadn't written to me, he'd probably never have figured out what was wrong. These are real people who are really hurt by the two providers' actions. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. PS: Here endeth the rant. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
By the way, to return to the original point, it still seems vanishingly unlikely to me that if we invented per-sender whitelists that the two mail providers would implement them. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
Hi, I've been invited by Murray Kucherawy and Franck Martin to participate in these discussions, so let me introduce my affiliation briefly. I've been operating GNU Mailman lists since 1999, an occasional contributor for about 10 years, and a GSoC Mentor for Mailman since 2012. I have somewhat ambiguous authorization to speak for the developers (ie, a rolling consensus of the Mailman Steering Committee[1]). Tim Draegen writes: John, you are very difficult to communicate with, maybe because you're easily insulted, even when there is no insult. I too have been in correspondence with mailing list developers, Which ones? GNU Mailman is now here. Besides me, John is a reliable source of summaries of past Mailman list discussions in what I've read of his posting here. I'm sure in the following I'll be going over a lot of ground that's been covered before, but since you think it's controversial enough to address, I hope I'll be forgiven for a certain degree of redundancy. and also developers behind businesses that rely on email, That's insufficiently precise. To my mind, there are two kinds (at least) of businesses that rely on provision of mailboxes (other use cases follow). (1) Corporate use case: mailboxes are provided for the convenience of organizational representatives communicating directly with agents outside the organization. (2) Mail service provider (ESP) use case: mailboxes are provided to customers for personal use of customers. I have no problem with p=reject in the corporate use case because I don't believe it causes significant burdens on users or unreliablity of delivery. I believe that John has the same assessment, and it is a weak consensus in the Mailman community AFAICT. Our issue is with p=reject as used by large ESPs like Yahoo! and AOL, especially since it seems to be associated with severe security problems, either at those services or on the users' own machines. (Evidently this is a consensus here as well, I'm just making Mailman's understanding clear.) Does DMARC actually impose significant burdens on the corporate use case, contrary to my belief? Of course there are other use cases of businesses that rely on email. I understand the mailing list as user forum case, and I believe Mailman has already implemented a sufficiently broad set of measures for business use in this use case. The tradeoffs aren't pleasant, but that's a cost of doing business with Yahoo! and AOL users. A business has the usual set of options (pay the costs, find less costly customers, use alternative forum technology, etc). I don't see a real problem here. There's also the on behalf of content provision use case. Others describe a good remedy in this thread, but I would like to point out that such providers may publish p=reject to good effect, as an instance of the corporate use case. But my knowledge of business use is quite limited. Are there other business activities relying on email such that DMARC imposes burdens? Are those burdens specific to p=reject, or more general? (If this is all well-known, please point me to a reference where I can book up without disturbing the Councils of the Wise.) and also a slew of decision makers... and they're all trying to understand how they can fix things without going backwards. IMO, they're wasting their time. Email service *must* deteriorate in the presence of users who send messages from p=reject domains, unless those domains are draconian in enforcing direct transmission to final destinations that observe p=reject (see Franck Martin's post later in the thread, and the following subthread on legitmate use of 'p=reject' that follows). Unfortunately, these domains are proposing that third parties adjust to their (unilaterally imposed) policy, rather than modifying those policies or restricting their users to safe email usage. But the let third parties adjust solution is a pretty dismal option. There are just too many MXes and MTAs and services that are DMARC-incompatible. It's going to take years, maybe a decade, to modify both the software and the installations. We really can't expect help from Yahoo! and AOL. You talk about money, well, Mailman doesn't care about money, it's a volunteer project. The effort in development required is actually tiny, less than 100 new/changed SLOC in Python for any given mitigation available in Mailman (probably about 200 N/CSLOC for all of them together). Maybe we'll take their money, but the effort to actually accept and use the money in a basically pure volunteer organization may make it a net zero. The help we need is in explaining to our users that they cannot maintain past configurations and allow posting from p=reject domains at the same time. For many of our users, they get a MLM as a part of a hosting package and the only solution they can implement themselves is to refuse posts from those domains. Where's the money to compensate those list operators for lost
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
Franck Martin writes: The changes in mailman to handle DMARC came from people involved with DMARC.org. Not all of them. The message-wrapping suggestion was mine (at least I invented it independently and was an early public proponent), and it was implemented by Mark Sapiro AFAIK. A From-corrupting patch was provided by DMARC.org, but final integration and of course release management was provided by Mark Sapiro. Other From-corrupting patches have been proposed, including one provided by John Levine (not yet implemented in a released Mailman, but obviously Mark will be involved in that). None of these patches have been ported to Mailman 3 yet. That sounds like a possible use for Yahoo! and DMARC.org funds, although we don't have organizational infrastructure to manage external funding now. So we cared. Nobody has denied that DMARC consortium members have put some effort into developing mitigation strategies. Nevertheless, I describe reasons why that effort (and Yahoo!'s offer of financial support) may be properly characterized as *negligible* in my response to Tim Draegen. (N.B. I don't claim the argument has broader applicability than the GNU Mailman project. For us, the contribution of DMARC consortium members has been net negative. Sorry, Franck. Feel free to poll the other Mailman developers if you disagree; I admit my strong feelings on the matter may cause bias.) I recall clearly, you did not want to see any change happening so you could reinforce your conspiracy theory. That happens not to be the case. Conspiracy theories abound on the Mailman lists (especially Mailman-Users), it's true, but John was not the source. John's account of decision-making at the freemail ESPs is substantially the same as the rationale you have repeatedly presented yourself (a push the panic button response to a concentrated spam attack). While the mailman developers are not happy on the current solutions and are looking for better solutions, they are at the same time happy to had one, when yahoo did the DMARC policy change, and quickly extended on the possibilities based on the experience they had before Yahoo did the policy change. Indeed we are *not* happy, and yes we did respond as quickly as possible to the *denial of service* experienced by many list subscribers, not restricted to the denial of service imposed by Yahoo! and AOL on their own subscribers. However, my wrapping suggestion had already been implemented, so the DMARC.org From-corrupting setting was not the only mitigation available (both became available in version 2.1.16). And we remain unhappy, not least because list operators are unhappy. The configurations are somewhat tricky and not understood at all by most list operators -- they follow recipes that are appropriate for common cases, but may conflict with unusual settings. The requirement by some mitigations that Mailman access the DNS in order to apply them only to p=reject posters (which is frequently mentioned by list operators requesting help) introduces substantial additional complexity. This is going to be an ongoing burden for the project, I fear. Now, while mailman has some solutions, it is in the recent versions and many people are still running old versions of mailman and upgrading or patching for them is difficult. So saying people do not know how to fix things is perfectly valid too. That's misdirection. We know one simple and guaranteed fix for the problem, and it is trivial to implement: domains providing mailboxes for personal use (including sending as a mailbox user of that domain from a different one, transfers that modify Content-Transfer-Encoding, mailing lists, use of on-behalf-of content distribution services, and so on) should stop publishing DMARC policies with p=reject. There appear to be two of them, they can do this in 5 minutes, and the problem will be completely eliminated within a day or so. That is not the only solution, but it really should be on the table, despite the additional costs of spam and spam-fighting those ESPs may suffer. I don't expect them to follow it any time soon, but that's no reason why we should sanction their current policy. We can condemn the policy and implement rational countermeasures at the same time. I support adding your conditions for legitimate use of 'p=reject' to the DMARC-base document, for example. I have no hope that DMARC.org will acquiesce, of course. Time to stop these non-technical threads These threads are input to the BCP process, at the very least. In any case, p=reject cannot be treated as a technical problem since the damage it does affects third parties who are not party to the DMARC protocol. and focus on making email more secure by providing solutions for people to choose from. I've made the lists used by my students more secure (against denial of service) by filtering p=reject domains. As it happens, *all* of my users agree that is the appropriate
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On 5/29/2014 3:09 AM, Murray S. Kucherawy wrote: On Thu, May 29, 2014 at 12:06 AM, John R Levine jo...@taugh.com mailto:jo...@taugh.com wrote: By the way, to return to the original point, it still seems vanishingly unlikely to me that if we invented per-sender whitelists that the two mail providers would implement them. Has anyone tried asking them? I'm not sure what value I should put in all this (ahem) third-party speculation about their intentions or what they care about. Good point. Why don't you ask them? We need positive endorsement for 3rd party semantics which we don't have. I've implemented ATPS for ADSP and it works. Update the extension for DMARC and I'm sure Yahoo can manage 30K records if they decide to use it. That shouldn't be a problem and it will be a growth thing, not adding 30K records in one shot. It will be more manageable. A major consideration is that not all domains are YAHOOs so it they won't need the same scale, not even close. But you see, thats been the problem with all this all along -- picking who this or that protocol, DKIM itself, will be using them and leveraging its value via a policy layer. We can't do that. The protocol modeling must fit all. That doesn't mean it works for all but from a mail integration and engineering standpoint, it has to apply to all -- small and large. It has to make sense at all scales. The danger was to miss this with the large who will have a higher impact when assumed they won't be using it. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Support for DMARC p=reject
Hi Doug, At 17:07 23-05-2014, Douglas Otis wrote: I have been asked nearly the same question by others. A section will be added to explain the how and why and its impact on privacy. Senders and receivers desire a scheme that improves protection of the From header field. The business aspects of this became extremely clear to PayPal by effects on their customers then obligated to sift through massive amounts of email abuse. The benefit of timely out-of-band notification instead caused an exodus of customers. To staunch customer loss, direct appeals to major ESPs to reject non-aligned PayPal messages helped, and helped everyone. Unfortunately, direct appeal does not scale. Hence we have a limited stop-gap scheme. I was not thinking about privacy in that comment. Some time back I looked into why abuse occurred in different systems. I was not trying to understand the matter instead of trying to resolve it. Note that I have read the relevant papers. Anyway, you did not answer the question I asked. :-) PayPal is the not really a good case in my opinion. I do not get money by solving PayPal's problem. I might put it some effort as encouraging abuse is not a good idea. A problem, which you identified, is that a scheme would have to scale or else be workable at some scale. As has become extremely clear, although there was early evidence, DMARC did not fully consider important corner cases. It seemed okay to leave these issues for receivers to sort out. Now AOL and Yahoo! have made it evident receiver cooperation is in jeopardy. If you are like most others, you have had malicious and socially engineered messages from someone you know prompting you to click a link or call a number, etc. Resorting to the only functional policy scheme able to reject messages is understandable, but this came at a dear cost. As John Levine describes, a death by a thousand cuts. If you push things too strongly I (as a receiver) would be no longer be inclined to be cooperative. Asserting whether all messages must have From/Source domain alignment is somewhat analogous to the type of federation supporting single-sign-on schemes. A federation has the purpose of protecting identifiers. In other words using laissez faire protocols where the strategy of block on event is inverted to become accept on event. In the case of DMARC + TPA, accept on event is derived from DMARC feedback/log review accurately determining which domains require exception. Further review can even characterize how domains authenticate and which header elements confirm or narrow authorization. I'll say ok to the above. Cute comic. It is not really the information protected by a federation scheme. It is not even the exclusion of bad stuff. It is protection of federated identities by receivers implementing DMARC + TPA. By using this scheme, associated identities can be protected while also avoiding disruption of legitimate messages. Even Eliot Lear's mother becomes safer. (I hope this is the right example as it was discussed many years ago.) The problem might be one of trust. I won't even try to analyze that as it is going to end up being a lot of work. Unfortunately, that approach now only works for authenticated domains. :^( Dane anyone? You'll have other problems then. :-( Regards, S. Moonesamy ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
Douglas Otis writes: There are many cases that are never originally signed by the DMARC domain. Such as an accounting package that sends out invoices on behalf of some company that wants their email address in the From header since this is what their customers will recognize. I don't understand this example. This use case seems quite compatible with DMARC as it is. That is, company and accountant should have a substantial and expensive to maintain trust relationship already. I would think that the company could (a) provide an alias (subdomain) in its own domain for the accountant's host, and advertise the accountant's policy via _dmarc.invoices.example.com, or (b) maintain an authenticated channel (ie, special purpose VPN) direct to a special host under its own control in its own domain for the accountant to relay through, and the company signs there. Sure, there'd be some additional cost, but not prohibitive. Note that in either case the client can fire the accountant in an instant by changing the DNS or shutting down the authenticated channel. I suspect that many parties that implement DMARC are cheating by allowing things that look like mailing list or forwarded mail through even if they fail auth and the domain is p=REJECT. Providing a higher bar for when to cheat may be useful, then. The hurdle that seems to be in everyone's mind is how to go about facilitating feedback that is not a lot of work. Again, I seem to require an additional clue. DMARC feedback is working fine AFAICS. It may be costly, and we want to reduce those costs, of course. But p=reject OTOH is a more or less legitimate denial of service, a completely different issue. Are you talking about a different kind of feedback? Steve ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On 5/29/2014 12:09 AM, Murray S. Kucherawy wrote: Has anyone tried asking them? I'll suggest that it's premature to do such asking, just as it is premature to say that they are uninterested or would reject the idea. Absent a very concrete proposal -- along the lines of a specification -- the request would be generic. Companies don't (and shouldn't) make meaningful commitments to vague concepts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] send-to-a-friend, was Solution for
Since you don't mention it, what about the mail this article to a friend use case that has also been mentioned? Is that a problem that should be addressed here? ... Franky, that case has always been kind of ick, and is easily solved by sending From the domain in question (article-nore...@wsj.com). Granted, I don't know how many of those there are and fixing them all is certainly annoying work that its bad to force on the world... also, arguably most of those shares have been replaced by sharing to the social website of the week. There seem to be rather a lot, since it's a feature on most magazine and newspaper web sites. Since you mentioned the WSJ, they use the user's own address as the From: address (I just checked.) Some do the hack you mentioned, but a lot don't. My college class has a mailing list, and I sometimes send articles to it from my WSJ account, which would stop working if they didn't let me put my own address on the From: line. Do you have any numbers on how much if any of a spam or phish problem these things are? They've never been on my radar, I think because they do a lot of rate limiting and inbound filtering. Some also limit it to subscribers. Also please keep in mind uses like the school teacher I mentioned earlier today. Again, useful, not abusive, and I think there are likely to be a lot of little setups like his that are now mysteriously failing. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] send-to-a-friend, was Solution for
On Thu, May 29, 2014 at 10:58 AM, Brandon Long bl...@google.com wrote: There seem to be rather a lot, since it's a feature on most magazine and newspaper web sites. Since you mentioned the WSJ, they use the user's own address as the From: address (I just checked.) Some do the hack you mentioned, but a lot don't. My college class has a mailing list, and I sometimes send articles to it from my WSJ account, which would stop working if they didn't let me put my own address on the From: line. Do you have any numbers on how much if any of a spam or phish problem these things are? They've never been on my radar, I think because they do a lot of rate limiting and inbound filtering. Some also limit it to subscribers. Also please keep in mind uses like the school teacher I mentioned earlier today. Again, useful, not abusive, and I think there are likely to be a lot of little setups like his that are now mysteriously failing. I'm sure most of the big ones are well protected with abuse limits, but I'm sure there are plenty of other ones which are not. I'm sure each one that is abused is a drop in the bucket of the overall abuse. That being said, with DMARC, I see no way forward for them. Even if the WSJ and other large publishers are whitelisted by one of the schemes we're talking about, the forms like your teacher's are never going to get whitelisted. At best, a provider may provide a mechanism to whitelist things for a specific user, but I haven't imagined anything like that which would be particularly user friendly either. I'd love to see some usage statistics from one or more of them. Lately it seems to me a lot more of such link sharing happens over social media (where this is all moot) rather than over email. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists
On May 29, 2014, at 7:07 AM, Stephen J. Turnbull step...@xemacs.org wrote: Douglas Otis writes: There are many cases that are never originally signed by the DMARC domain. Such as an accounting package that sends out invoices on behalf of some company that wants their email address in the From header since this is what their customers will recognize. I don't understand this example. This use case seems quite compatible with DMARC as it is. That is, company and accountant should have a substantial and expensive to maintain trust relationship already. I would think that the company could (a) provide an alias (subdomain) in its own domain for the accountant's host, and advertise the accountant's policy via _dmarc.invoices.example.com, or (b) maintain an authenticated channel (ie, special purpose VPN) direct to a special host under its own control in its own domain for the accountant to relay through, and the company signs there. Sure, there'd be some additional cost, but not prohibitive. Note that in either case the client can fire the accountant in an instant by changing the DNS or shutting down the authenticated channel. Dear Stephen, https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly I know of many small operations with similar services and previously working strategies. With a low profit margin, no one wants to then be dealing with DNS or VPN configurations or deciding who is allowed to have access to their networks or their DKIM private keys. Think of the heating and air conditioning outfit given VPN access for the purpose of submitting invoices. That error in judgement cost hundreds of millions for a well known retailing outfit. There are also similar types of risks when anyone opens any MS Office document given to them by a spoofed party. http://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/ The intent behind TPA-Label is to permit a secure scheme without ever asking anyone to share credentials. Not ever! Instead, everyone uses what they already have, perhaps even stronger schemes than what is offered by DKIM or SPF. Large ESPs that have had a major security breach should set aside a budget related to restoring order. A TPA-Label setup could be part of that effort. Two DNS servers (for redundancy) and some DMARC and MTA log processing scripts should offer a comprehensive and fairly complete starting point. Yes, even for a large ESP. Of course there will be ongoing support issues, but this should also pale in comparison to unsolvable email complaints of affected legitimate email use. For this, there should be web-based forms to supplement DMARC feedback. By setting up a TPA-Label extension, it would also allow their users to know when they have themselves been compromised, while also preventing unauthorized use by rogue servers. This added feature seems like a nice way of saying Sorry, but we are now doing more to improve security. I suspect that many parties that implement DMARC are cheating by allowing things that look like mailing list or forwarded mail through even if they fail auth and the domain is p=REJECT. Providing a higher bar for when to cheat may be useful, then. The hurdle that seems to be in everyone's mind is how to go about facilitating feedback that is not a lot of work. Again, TPA-Label also permits a way to squelch DMARC feedback already evaluated. Perhaps a flag could even be added that basically says. Yes we know about this domain, and we think it cannot be trusted. This would be a change to the current draft. Again, I seem to require an additional clue. DMARC feedback is working fine AFAICS. It may be costly, and we want to reduce those costs, of course. But p=reject OTOH is a more or less legitimate denial of service, a completely different issue. Are you talking about a different kind of feedback? Rather than having a channel only between receiver-to-sender, there should also be a channel between sender-to-receiver. The channel can represent a single DNS resource record. Such a single resource record would offer low latency, low cost, and cacheable near the receiver for even lower latency. I know that John and Tim would have little trouble setting up such a service. The real challenge is to have an ESP do this that really needs such a solution. Once in place, this opens up a range of services others could easily offer on behalf of those who simply desire greater email security. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On Wednesday, May 28, 2014 10:13 PM [GMT+1=CET], Tim Draegen wrote: I don't believe TPA-Label hits the mark between solving a big hurt and simple. IOW, it's too complicated for the amount of pain it would resolve. Just my opinion, take care, I'm of the same opinion as above. In my own words, I would say the TPA-label draft Otis posted reads like perfectly polished Klingon to me. Id est, overly too complex for very little gain. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On Thu, May 29, 2014 at 1:28 PM, J. Gomez jgo...@seryrich.com wrote: I don't believe TPA-Label hits the mark between solving a big hurt and simple. IOW, it's too complicated for the amount of pain it would resolve. Just my opinion, take care, I'm of the same opinion as above. In my own words, I would say the TPA-label draft Otis posted reads like perfectly polished Klingon to me. Id est, overly too complex for very little gain. +1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
My Klingon may be rusty, but I think that makes it a +[cid:image003.png@01CF7B67.32E414D0] (apologies for those seeing this in text as I don’t have Klingon.ttf on my work laptop). From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, May 29, 2014 5:23 PM To: J. Gomez Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection On Thu, May 29, 2014 at 1:28 PM, J. Gomez jgo...@seryrich.commailto:jgo...@seryrich.com wrote: I don't believe TPA-Label hits the mark between solving a big hurt and simple. IOW, it's too complicated for the amount of pain it would resolve. Just my opinion, take care, I'm of the same opinion as above. In my own words, I would say the TPA-label draft Otis posted reads like perfectly polished Klingon to me. Id est, overly too complex for very little gain. +1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New Non-WG Mailing List: Domain-based Message Authentication, Reporting, and Compliance (DMARC)
Just so nobody gets excited, this announcement is because the entry for the mailing list was missing from the non-wg page and now it's been added: http://www.ietf.org/list/nonwg.html d/ On 5/29/2014 3:21 PM, IETF Secretariat wrote: A new IETF non-working group email list has been created. List address: dmarc@ietf.org Archive: http://www.ietf.org/mail-archive/web/dmarc/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/dmarc Purpose: Summary Description: Discussion related to the development, clarification, and implementation of the DMARC protocol, and operational uses of it. Detailed Description: Discussion related to the development, clarification, and implementation of the DMARC protocol, and operational uses of it. DMARC (Domain-based Message Authentication, Reporting, and Compliance) is an overlay on top of email and some current authentication protocols, which allows for limited policy enforcement and anomaly reporting. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On Thursday, May 29, 2014 1:19 PM [GMT+1=CET], Stephen J. Turnbull wrote: And we remain unhappy, not least because list operators are unhappy. The configurations are somewhat tricky and not understood at all by most list operators -- they follow recipes that are appropriate for common cases, but may conflict with unusual settings. The requirement by some mitigations that Mailman access the DNS in order to apply them only to p=reject posters (which is frequently mentioned by list operators requesting help) introduces substantial additional complexity. This is going to be an ongoing burden for the project, I fear. Missuse of DMARC's p=reject by Senders is here to stay. It won't go away. It will only grow.[*] On the other hand, when hard pressed, [I think] email users are going to choose to keep their mailbox/address over a mailing list subscription, therefore mailing list software will have to adapt to the new theater of operations -- provided DMARC gets deployed in the real world by some significant measure, of course. In my opinion, the least disruptive adaptation which mailing list software can do is to take ownership --in a DMARC-compatible way-- of the Header-From, just like they already take ownership of the envelope's ReturnPath-From. And, also in my opinion, that mailing list adaptation to DMARC should be the new default out-of-the-box behaviour of mailing list packages from now on, and the old behaviour should be regarded as legacy and deprecated. Why? Because we cannot count on the average mailing list operator to stop to ponder the fine points of the DMARC issue while he is setting up his VPS server in a haste.[**] Therefore [in my opinion], a sane, out-of-the-box DMARC-compatible behaviour should be the default for mailing list software, from now on. [*][**] Because that's the way the world goes by. We know one simple and guaranteed fix for the problem, and it is trivial to implement: domains providing mailboxes for personal use (including sending as a mailbox user of that domain from a different one, transfers that modify Content-Transfer-Encoding, mailing lists, use of on-behalf-of content distribution services, and so on) should stop publishing DMARC policies with p=reject. There appear to be two of them, they can do this in 5 minutes, and the problem will be completely eliminated within a day or so. Yes, but it just won't happen. Once someone publishes p=reject, if he is too-big-to-reject, then he is not going to go back to the previous situation. He expects the world to accomodate him, and this is EXACTLY what will happen if he just happens to be, by definition, too-big-to-reject. I think we should accept this as a fact, and move forward, and take the neccesary countermeasures as the new by-default situation. I've made the lists used by my students more secure (against denial of service) by filtering p=reject domains. As it happens, *all* of my users agree that is the appropriate solution for us (the Yahoo! users didn't even think about fighting before switching, they already had GMail addresses). Of course I hesitate to recommend that policy to anybody else, but it *is* technically simple, and was the optimum response in my case. That solution is good, but can only be expected from savvy mailing list operators who fully understand the fine details of the DMARC issue -- I think we cannot expect that to be the case for the vast majority of mailing list operators world-wide. Also, the support costs of such a solution are high (disgruntled users calling the help desk), and may even be unbearable if the mailing list operator happens not to have a more or less captive user base. Regards, J.Gomez ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On 5/29/2014 4:28 PM, J. Gomez wrote: On Wednesday, May 28, 2014 10:13 PM [GMT+1=CET], Tim Draegen wrote: I don't believe TPA-Label hits the mark between solving a big hurt and simple. IOW, it's too complicated for the amount of pain it would resolve. Just my opinion, take care, I'm of the same opinion as above. In my own words, I would say the TPA-label draft Otis posted reads like perfectly polished Klingon to me. Id est, overly too complex for very little gain. Mr. Gomez, TPA has a wider scope and an overly described functional specification. But the main idea should not be thrown away due to lack of fundamentally understanding the long time problem and proposed solutions. In its simplest terms, the idea is to lookup a 3rd party domain for authorization to sign or resign originating author domain mail. The earliest suggestions like in the 2006 DSAP proposal used an Allowed Signer List (ASL) asl= tag in the policy records. So applying this simpler idea to DMARC, an example policy for your domain, seryrich.com, might be _dmarc.seryrich.com TXT (v=dmarc1; p=reject; asl=ietf.org; ...) This would expose to the world the policy that says: Only domains seryrich.com and ietf.org are authorized to sign mail for seryrich.com. If you see anything else, reject it. Simple idea. No extra lookup beyond the DMARC lookup. The problem with ASL is that it works for the shorter list domains. It would not scale for the larger domains, i.e. can't fit Yahoo's 30K potential authorization list. I think its an optimization idea for the majority of domains who are smaller than YAHOO. This is where Doug's TPA (Third Party Authorization) and Murray's simpler version of TPA called ATPS (Authorized Third Party Signer, RFC6541) comes into play. TPA and ATPS is basically the same when it comes to the lookup formula, which is to combine the signer domain as a subdomain zone of the author domain. I have implemented ATPS but its basically the same as TPA with a query formula of: BASE64(SHA1(signer-domain))+.+author-domain So for you, your DMARC and ATPS subdomain records for seryrich.com zone would be: _dmarc TXT (v=dmarc1; p=reject; atps=y;) PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps TXT (v=atps01; d=ietf.org;) So the ideas has been worked out. The problem has been to get the IETF List Operators and Administrators to support this. So why not? Note, we also develop list software, so I have no problem doing what is necessary to get it all to work right. The main problem is that list operators prefer to use a TRUST model by looking up the signer domain. Not the author domain. They currently do neither, but they prefer to use the signer domain and this was the DKIM standard suggestion. Use the SIGNER domain. Forget about the author domain. Again, I am just looking for a total mail integrated solution between all parts. So lets go ahead and lookup the signer domain. What's the problem then? Well, what happens when any of these simple use cases occur: a) The signature does not exist in the message. Its missing. b) Signature exist, but it doesn't hash verify. Its broken. c) Signature exist and its valid, but its not your signature. Its some unknown signer that wants to tell the world its signing on your behalf. So the basic argument against depending on a signer domain only is that may not exist nor be valid. It can be completely fake. Now, Levine's VBR was a step in the right direction with the combo author and signer lookup but again, what happens when the signature is missing or invalid so that there is no signer domain to lookup? The trust advocates don't have an answer for these simple first level security issues that are easily detectable as failure. In summary, this has been examine all ways and the best and original idea was looking up the author domain because its the single identity that MUST exist in the message. It is the most important header of them all, the 5322.From header. This is the reason it is also the only header that MUST be hash bound to the signature. No other header is required to be hashed to the signature. But the resigners don't want to look it up. They want the freedom to resign mail. The policy advocates wants a more flexible 1st and 3rd party resigner framework, but one with options to lock down the 3rd party signers. I believe the latter is the more protocol strong solution. Its require more wider support and it will clamp down on the laissez-faire resigners who want to resign and don't wish to even check to see if its valid. Yes, there is the problem of the legacy users that has long used public, but also highly spam polluted big email brand domain. The Yahoos are not the only one who domains are polluted and they wish to finally take control and increase its security quality value. The IETF need to stop trying to make policy itself on what parts of the mail
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On May 29, 2014 3:09:44 AM EDT, Murray S. Kucherawy superu...@gmail.com wrote: On Thu, May 29, 2014 at 12:06 AM, John R Levine jo...@taugh.com wrote: By the way, to return to the original point, it still seems vanishingly unlikely to me that if we invented per-sender whitelists that the two mail providers would implement them. Has anyone tried asking them? I'm not sure what value I should put in all this (ahem) third-party speculation about their intentions or what they care about. I think Yahoo's communications have been very clear about what they care about. No speculation is needed. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On 5/28/14, 6:46 PM, Barry Leiba wrote: Anything that requires mailing list software to change won't work. I'm going to push back on this statement. I think we keep getting stuck on the mantra that the mailing list software won't change. However, the majority of the mailing list software packages that are out there now DO generate proper List-* headers. It took some time, and it may not be 100% coverage, but by gosh and by golly, most of them do so and do it correctly. Why? There were a few things: 1) a well defined spec about what change was desired, AND 2a) there was perceived benefit to adding those headers, or 2b) there was perceived harm in not adding those headers. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. I think this is exactly the correct solution for mailing lists to pursue. This is an excellent start of a spec for what mailing lists should be doing in a world where systems are using DKIM and SPF, and more systems are expecting such mail to pass validation. (A post-DMARC world, if you will.) There may be alternative solutions that are less optimal that will also get mailing list messages delivered more reliably. (For example, delete all DKIM signatures and force the From: header to use the originator's name in the comment but with the mailing list address instead of the originator's address. It works, but isn't pretty.) It might be worth doing some investigation of those alternatives, and showing their advantages and disadvantages. Mailing lists have an expectation of being able to get their mail delivered. That is no longer the case. The benefit of them making changes is that their messages will get delivered more reliably. The harm in not making changes is that their service will continue to be unreliable. But clear specs detailing what they CAN do and SHOULD do is the starting point. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. I agree completely that a change to DMARC is needed in conjunction with having clear ML specs. When HeartBleed came out recently, it was discovered that openssl had rather poor support, even though everyone and their neighbor seems to use it in some fashion or another. A consortium was then formed to provide some needed support and to improve the quality control for openssl. I've heard it said that the majority of the mailing lists out there are managed by only a handful of ML management systems. I maintain that these ML packages are in the same boat as openssl. It sure would be nice if we could get some of that consortium money thrown at that handful of ML management systems. That's a political solution for this current technical problem. However, before it can happen: we NEED clear specs as to what should be done by ML systems, at least in the face of DKIM and SPF (and DMARC) Tony Hansen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change)
On Thursday, May 29, 2014 23:11:28 Tony Hansen wrote: On 5/28/14, 6:46 PM, Barry Leiba wrote: Anything that requires mailing list software to change won't work. I'm going to push back on this statement. I think we keep getting stuck on the mantra that the mailing list software won't change. However, the majority of the mailing list software packages that are out there now DO generate proper List-* headers. It took some time, and it may not be 100% coverage, but by gosh and by golly, most of them do so and do it correctly. Why? There were a few things: 1) a well defined spec about what change was desired, AND 2a) there was perceived benefit to adding those headers, or 2b) there was perceived harm in not adding those headers. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. I think this is exactly the correct solution for mailing lists to pursue. This is an excellent start of a spec for what mailing lists should be doing in a world where systems are using DKIM and SPF, and more systems are expecting such mail to pass validation. (A post-DMARC world, if you will.) There may be alternative solutions that are less optimal that will also get mailing list messages delivered more reliably. (For example, delete all DKIM signatures and force the From: header to use the originator's name in the comment but with the mailing list address instead of the originator's address. It works, but isn't pretty.) It might be worth doing some investigation of those alternatives, and showing their advantages and disadvantages. Mailing lists have an expectation of being able to get their mail delivered. That is no longer the case. The benefit of them making changes is that their messages will get delivered more reliably. The harm in not making changes is that their service will continue to be unreliable. But clear specs detailing what they CAN do and SHOULD do is the starting point. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. I agree completely that a change to DMARC is needed in conjunction with having clear ML specs. When HeartBleed came out recently, it was discovered that openssl had rather poor support, even though everyone and their neighbor seems to use it in some fashion or another. A consortium was then formed to provide some needed support and to improve the quality control for openssl. I've heard it said that the majority of the mailing lists out there are managed by only a handful of ML management systems. I maintain that these ML packages are in the same boat as openssl. It sure would be nice if we could get some of that consortium money thrown at that handful of ML management systems. That's a political solution for this current technical problem. However, before it can happen: we NEED clear specs as to what should be done by ML systems, at least in the face of DKIM and SPF (and DMARC) The reason there is no IETF working group is that the people behind DMARC were unwilling to entertain participation in a working group that had a charter that allowed for any chance of a change to the DMARC protocol. DMARC change is even more off the table than MLM software change (which does, as you suggest, evolve over time). Yahoo's view, based on their public statements clearly seems to me to be that using DMARC p=reject is beneficial to them and they are big enough that 3rd parties will adapt rather than suffer the consequences of not adapting. I believe they are right on both counts. Mailing lists and other related systems that are affected by this are adapting. It's painful and the solutions inevitably involve regressions in functionality, but they are one of the few 800 pound gorillas and they can get away with it. I am entirely sympathetic to people that are unhappy about this state of affairs (I'm unhappy about it too), but it is what it is. I wrote the other day asking what IETF work is there around DMARC and didn't get much of an answer. I think that's instructive. I'm increasingly convinced that there isn't any. At this point, while there's value in a central point for operators and developers to exchange information about how to mitigate the damage caused by what is in my opinion irresponsible use of DMARC, I don't think there is anything to standardize. Eventually, there's probably a BCP in this, but it's premature. If the IETF tries to go off and write a BCP on DMARC work arounds now, we'll end up looking silly by the time the metaphorical ink is dry. We've all got lots of ideas on practices that would be a good idea, but many of them are new enough they can only barely be described as current and knowing what among them is best is premature. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
