Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
Dear Brandon; See comments inline: On Jun 2, 2014, at 2:22 PM, Brandon Long wrote: > On Sun, Jun 1, 2014 at 7:56 PM, Douglas Otis wrote: > It seems wrong to describe a mailing-list adding Subject Tags, List Footers, > while retaining the From header field so people have an easer task of knowing > who is talking and at reviewing past conversations as putting recipients in > grave risk. Causing a massive number of people to find different email > providers so they can retain their effectiveness at using a mailing list is > far more likely to create risk simply due to the resulting confusion. > > There is also the case of Intuit sending "From" invoices on behalf of various > individuals and using their customer's email address given to them by their > Internet provider, only to find someone now thinks DKIM can't possibly be > considered valid when signing the Sender header field. That is exactly the > intended purpose for this field. This is essentially the same issue with > mailing-lists. In both cases, there is a valid reason for the From header > field to contain that of their client or the speaker, because that is what > the recipient is able to recognize. There are also MUAs that will create a > synthetic From on behalf of . Most MUAs can also optionally > display both headers. > > The real effort involved in the sequence of these messages is establishing > trust anchors. While there is going to be a massive number of individuals > involved, there are several orders of magnitude fewer trust anchors. For any > domain wanting to assert strict alignment for their messages, it is only fair > for them to work out relationships between their users messages and the > non-aligned third-party services (trusted domain --> worthy third-party > service). Their out-bound logs and DMARC/User feedback should arrive at a > reasonable estimate about which domains are being trusted. Rogue services > will be excluded and any mistakes can be quickly corrected. > > Rather than describing this as a permission to sign, think of this as a type > of server federation aimed at protecting the federated identity much like > single-user-sign-on. In this case, it would be which of these services are > normally used and maintain practices that protect the federated identifiers. > The TPA-Label scheme allows this type of federation to be centralized or > handled separately by each trusted domain (senders) as described in > http://tools.ietf.org/html/draft-otis-tpa-label. > > Why should I, or my users, trust Intuit? Why is From domain alignment the only header trusted for user accounts? For those you need to trust, ask them to use OAR. This can be a stipulation included in the Authorization. Users may wish to correspond with more than just transactional messaging after all. At least allow TPA-Labels to permit exceptions. Be less dogmatic and consider a TPA-Label exception for Sender. There are many MUAs able to display both Sender and From. Some MUAs even create a synthesis of From on behalf of . A configuration script can be provided to users to ensure they are aware of this option. One might even suspect there is a reasonable number of users making use of these headers as well. :^) > Perhaps I do because I have friends who have worked there and I use their > software. What about the next payments start-up? Or the Russian or Chinese > equivalent of Intuit that I know nothing about and at best rely on the google > translate version of their home page? IMHO, it is wrong to say WE have decided that messages aligned with the Sender header field will now be rejected, when for decades this represented proper use. Yes, it means an email provider will be making decisions. Welcome to email. :^) We have been making these types of decisions for about two decades without the valuable resource of outbound domain logs and DMARC feedback. Much of the information needed to do this properly will be found in the feedback and logs. Once digested, what has been determined to be an informally federated domain needs to be shared with recipients so they can make better decisions without disrupting venerated services. Since doing this better ensures recipients will be less confused or upset when things needless change. > Do you expect that we would pass 30k domains through some sort of human > vetting process, and that even if we were willing to do that, we would be > capable of actually vetting them all? Yes. Start with the easy stuff. Eventually, this will catch up. Ignore newly created domains or have them contact your abuse desk for escalation. There are far fewer systems identified by domain. There should be enough redundant confirmations to the point not much human vetting should be needed. These numbers should not be overwhelming. Start with sources offering the most compliance information in their messages. We did our best with much less for t
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
Dear Hector, See comments inline: On May 30, 2014, at 4:44 PM, Hector Santos wrote: > On 5/30/2014 5:49 PM, J. Gomez wrote: > >>> Ah, but "just like" is a complete misstatement of the situation. >>> There's a big difference. Users on a mailing list think of the >>> poster, not the mailing list, as responsible for the content. So >>> according to RFC 5322, the poster's mailbox belongs in From:. >>> Remailed or not, the author belongs there. >> >> That is debatable. As long as the mailing list program tampers with the >> message's content, rendering its DKIM signature invalid, it can be argued >> that the mailing list program is rewriting the message's content, and >> therefore that the mailing list program now becomes "the system responsible >> for the writing of the message" (as per RFC 5322 parlance, section 3.6.2), >> and thus the mailing list address would earn its legitimate place in the >> Header-From field, making interoperability with rogue DMARC Senders a solved >> problem. > > In my book, this is mail tampering. It will be hard to justify adding support > for this radical behavior in our mail list server product which puts > customers at risk. You are putting yourself at product liability risk but > intentionally defying a security protocol against the wishes of the > publishing restrictive domain. Of course, its only becomes a problem when > its used as a loophole to further spread harmful mail and someone actually > gets harmed. Thats all you have to prove in a courtroom. If you had all > the tools before you to tell you definitively, "This is unauthorized mail" > and you intentionally, deliberately and neglectfully ignore it, do nothing > about it but further distribute to end points, well, who knows what a young > punk, tech savvy, high tech, new age lawyer will think about suing you. If > you got deep pockets, well, don't think it can't happen. > > It is this sort of mentality that completely makes this old game no more fun > to work with. Seriously. > > We can do it right. All we have to do is LOOKUP the policy and follow it. > Give the YAHOOs the tools to authorize the resigners and you and I won't have > these new ethical problems to content with. It seems wrong to describe a mailing-list adding Subject Tags, List Footers, while retaining the From header field so people have an easer task of knowing who is talking and at reviewing past conversations as putting recipients in grave risk. Causing a massive number of people to find different email providers so they can retain their effectiveness at using a mailing list is far more likely to create risk simply due to the resulting confusion. There is also the case of Intuit sending "From" invoices on behalf of various individuals and using their customer's email address given to them by their Internet provider, only to find someone now thinks DKIM can't possibly be considered valid when signing the Sender header field. That is exactly the intended purpose for this field. This is essentially the same issue with mailing-lists. In both cases, there is a valid reason for the From header field to contain that of their client or the speaker, because that is what the recipient is able to recognize. There are also MUAs that will create a synthetic From on behalf of . Most MUAs can also optionally display both headers. The real effort involved in the sequence of these messages is establishing trust anchors. While there is going to be a massive number of individuals involved, there are several orders of magnitude fewer trust anchors. For any domain wanting to assert strict alignment for their messages, it is only fair for them to work out relationships between their users messages and the non-aligned third-party services (trusted domain --> worthy third-party service). Their out-bound logs and DMARC/User feedback should arrive at a reasonable estimate about which domains are being trusted. Rogue services will be excluded and any mistakes can be quickly corrected. Rather than describing this as a permission to sign, think of this as a type of server federation aimed at protecting the federated identity much like single-user-sign-on. In this case, it would be which of these services are normally used and maintain practices that protect the federated identifiers. The TPA-Label scheme allows this type of federation to be centralized or handled separately by each trusted domain (senders) as described in http://tools.ietf.org/html/draft-otis-tpa-label. 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
J. Gomez writes: > Users won't care about the politics of the email system, but about > relevant and wanted email landing on their inbox -- hopefully in an > easily readable manner. If you have users like that, configure your lists accordingly. The options are available (in GNU Mailman, at least). > That proposal is fine from a technical point of view - it solves > the problem and is interoperable. However, that proposal is not > perfect from a usability point of view - how well will an attached > message/rf822 part be legible when the final recipient is using > webmail, Works fine in GMail and SquirrelMail, IIRC (another developer did the testing). > is that proposal convoluted for the final Recipient's comfort? No. The proposal is intended to ensure delivery of messages posted from an ESP whose DMARC policy is in conflict with mailing list policy, with the message as posted by the author and modified by the mailing list, and comfortably readable in any MUA conforming to RFC 1341 (published in June 1992). A more pleasant reading experience is available in MUAs conforming to RFC 1806 (June 1995). If the list operator knows that she has users with MUAs that don't conform to 20-year-old standards, she can change the options easily at any time. > I guess that once the interoperability issue is agreed to be > important, now the ergonomics of the proposed solution should get > the focus. And that proposal is not very ergonomical, in my humble > opinion. So tell the MUA developers about it. It takes a moderate amount of code to DTRT with nested MIME parts and Content-Disposition: inline, but it's not rocket science, not compared with supporting text/html. ___ 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 Saturday, May 31, 2014 2:18 PM [GMT+1=CET], Stephen J. Turnbull wrote: > J. Gomez writes: > > > Furthermore, what is more important - to deserve or not to deserve > > the prize of being sanctioned as kosher, or keeping a world-wide > > system interoperable? > > In the face of bullying by large operators counting on the fact that > ostracizing them would seriously annoy millions of *our* users and > customers, I think calling it "bullying" is one of the more important > steps we can take to keep that system interoperable. I don't mind calling it bullying, but I would not focus on that, but on the interoperability side of the issue. Users won't care about the politics of the email system, but about relevant and wanted email landing on their inbox -- hopefully in an easily readable manner. > > Yes, that is true. But a default out-of-the-box always has to > > exist, and in my opinion that default should be the most > > interoperable which is possible --interoperable with the real > > world, not with how we would like the world to be--, while keeping > > as much valuable features as possible, and while keeping operator's > > duties as straight forward and simple as possible. > > There's interoperability and there's interoperability. GNU Mailman > has a feature such that (1) a DNS query checks for "p=reject" and (2) > if found, the message is wrapped as a message/rfc822 part in a message > from the mailing list and containing the header (if any) and footer > (if any) as separate MIME parts. This is fully RFC conformant (it's > basically a one-message digest) and almost all MUAs should be able to > handle it. It is what I propose as default for Mailman. > > Do you see any defects in that proposal? That proposal is fine from a technical point of view - it solves the problem and is interoperable. However, that proposal is not perfect from a usability point of view - how well will an attached message/rf822 part be legible when the final recipient is using webmail, or a mobile device with a simple MUA? - how much a non-technical user will freak out when he gets such a message from a mailing list? - will he call the help desk about it, incurring support costs and being a burden for that help desk? - will that proposal unnecessarily consume time in the Recipient side of the communication, basically off-loading into the final innocent Recipient the cost of solving "the DMARC issue"? - is that proposal convoluted for the final Recipient's comfort? I guess that once the interoperability issue is agreed to be important, now the ergonomics of the proposed solution should get the focus. And that proposal is not very ergonomical, in my humble opinion. > > > according to RFC 5322, the poster's mailbox belongs in From:. > > > Remailed or not, the author belongs there. > > > > That is debatable. As long as the mailing list program tampers with > > the message's content, rendering its DKIM signature invalid, it can > > be argued that the mailing list program is rewriting the message's > > content, > > It can be and is argued, but the argument is clearly incorrect. The > most recent RFCs state quite clearly that "same message" is in the eye > of the users, and I cannot imagine that addition of a "[list]" tag to > Subject or an unsubscribe footer to the message body would be > interpreted by anyone involved in the list as making the list the > author. If DKIM signatures were not involved, you would be right. Now that DKIM signatures are indeed involved, and considered useful in the email ecosystem, any tampering with a message's content means taking responsibility of the result of such tampering, therefore taking ownership of the Header-From. 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
J. Gomez writes: > Furthermore, what is more important - to deserve or not to deserve > the prize of being sanctioned as kosher, or keeping a world-wide > system interoperable? In the face of bullying by large operators counting on the fact that ostracizing them would seriously annoy millions of *our* users and customers, I think calling it "bullying" is one of the more important steps we can take to keep that system interoperable. > Yes, that is true. But a default out-of-the-box always has to > exist, and in my opinion that default should be the most > interoperable which is possible --interoperable with the real > world, not with how we would like the world to be--, while keeping > as much valuable features as possible, and while keeping operator's > duties as straight forward and simple as possible. There's interoperability and there's interoperability. GNU Mailman has a feature such that (1) a DNS query checks for "p=reject" and (2) if found, the message is wrapped as a message/rfc822 part in a message from the mailing list and containing the header (if any) and footer (if any) as separate MIME parts. This is fully RFC conformant (it's basically a one-message digest) and almost all MUAs should be able to handle it. It is what I propose as default for Mailman. Do you see any defects in that proposal? > > according to RFC 5322, the poster's mailbox belongs in From:. > > Remailed or not, the author belongs there. > > That is debatable. As long as the mailing list program tampers with > the message's content, rendering its DKIM signature invalid, it can > be argued that the mailing list program is rewriting the message's > content, It can be and is argued, but the argument is clearly incorrect. The most recent RFCs state quite clearly that "same message" is in the eye of the users, and I cannot imagine that addition of a "[list]" tag to Subject or an unsubscribe footer to the message body would be interpreted by anyone involved in the list as making the list the author. 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 Saturday, May 31, 2014 1:44 AM [GMT+1=CET], Hector Santos wrote: > On 5/30/2014 5:49 PM, J. Gomez wrote: > > > > Ah, but "just like" is a complete misstatement of the situation. > > > There's a big difference. Users on a mailing list think of the > > > poster, not the mailing list, as responsible for the content. So > > > according to RFC 5322, the poster's mailbox belongs in From:. > > > Remailed or not, the author belongs there. > > > > That is debatable. As long as the mailing list program tampers with > > the message's content, rendering its DKIM signature invalid, it can > > be argued that the mailing list program is rewriting the message's > > content, and therefore that the mailing list program now becomes > > "the system responsible for the writing of the message" (as per RFC > > 5322 parlance, section 3.6.2), and thus the mailing list address > > would earn its legitimate place in the Header-From field, making > > interoperability with rogue DMARC Senders a solved problem. > > In my book, this is mail tampering. It will be hard to justify adding > support for this radical behavior in our mail list server product > which puts customers at risk. You are putting yourself at product > liability risk but intentionally defying a security protocol against > the wishes of the publishing restrictive domain. I am not sure I am following you here. When I say that mailing list programs should take ownership of the Header-From if they tamper with the original message content rendering its DKIM signature invalid, and that this behavior should happen irrespective of the original Sender's published DMARC policy, I am not saying that mailing list programs should relay to its subscribers fake or phishing email from unverified sources. It would go something like this: 1.Sender -> 2.MTA at mailing list host -> 3.ML processes message -> 4.ML program relays message. DMARC/DKIM/SPF checking should happen at stage 2, not at stage 3. Fake/phishing email should be detected and rejected at stage 2, and only clean legitimate email should arrive at stage 3, and at that point the mailing list program would "do its work" adding subject tags, body footers, AND taking ownership of the Header-From (hopefully indicating the original Sender in the description inside the Header-From), and then go to step 4 and relay to the list members that message. And "that message" would be a clean, wanted, legitimate email which ALSO would solve the DMARC issues with mailing lists. The only check the mailing list program should do (step 3) is to ascertain whether the original Sender is or is not a subscribed address. Checking the validity/authentication of that address belongs to step 2 and to the MTA just before the mailing list program sees the message. So I think that your worries of "putting customers at risk" are not warranted, unless I do not understand what you are saying. > It is this sort of mentality that completely makes this old game no > more fun to work with. Seriously. Please, do not get frustrated. It is not helpful to the conversation. 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/30/2014 5:49 PM, J. Gomez wrote: Ah, but "just like" is a complete misstatement of the situation. There's a big difference. Users on a mailing list think of the poster, not the mailing list, as responsible for the content. So according to RFC 5322, the poster's mailbox belongs in From:. Remailed or not, the author belongs there. That is debatable. As long as the mailing list program tampers with the message's content, rendering its DKIM signature invalid, it can be argued that the mailing list program is rewriting the message's content, and therefore that the mailing list program now becomes "the system responsible for the writing of the message" (as per RFC 5322 parlance, section 3.6.2), and thus the mailing list address would earn its legitimate place in the Header-From field, making interoperability with rogue DMARC Senders a solved problem. In my book, this is mail tampering. It will be hard to justify adding support for this radical behavior in our mail list server product which puts customers at risk. You are putting yourself at product liability risk but intentionally defying a security protocol against the wishes of the publishing restrictive domain. Of course, its only becomes a problem when its used as a loophole to further spread harmful mail and someone actually gets harmed. Thats all you have to prove in a courtroom. If you had all the tools before you to tell you definitively, "This is unauthorized mail" and you intentionally, deliberately and neglectfully ignore it, do nothing about it but further distribute to end points, well, who knows what a young punk, tech savvy, high tech, new age lawyer will think about suing you. If you got deep pockets, well, don't think it can't happen. It is this sort of mentality that completely makes this old game no more fun to work with. Seriously. We can do it right. All we have to do is LOOKUP the policy and follow it. Give the YAHOOs the tools to authorize the resigners and you and I won't have these new ethical problems to content with. -- HLS ___ 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 Friday, May 30, 2014 12:09 PM [GMT+1=CET], Stephen J. Turnbull wrote: > J. Gomez writes: > > > Missuse of DMARC's p=reject by Senders is here to stay. It won't go > > away. It will only grow.[*] > > I'm not so sure. Anyway, that doesn't mean we need to sanction it. To maneuver towards being interoperable with something (the misuse of DMARC's p=reject as a sad fact of life), does not equal sanctioning that something. Furthermore, what is more important - to deserve or not to deserve the prize of being sanctioned as kosher, or keeping a world-wide system interoperable? > > 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, > > I disagree. The least disruptive adaption is whatever the users of > the mailing list think is the least disruptive adaptation. That's why > Mailman provides multiple mitigation options, and will probably add > more as we think of them or they're contributed to us. Yes, that is true. But a default out-of-the-box always has to exist, and in my opinion that default should be the most interoperable which is possible --interoperable with the real world, not with how we would like the world to be--, while keeping as much valuable features as possible, and while keeping operator's duties as straight forward and simple as possible. > > just like they already take ownership of the envelope's > > ReturnPath-From. > > Ah, but "just like" is a complete misstatement of the situation. > There's a big difference. Users on a mailing list think of the > poster, not the mailing list, as responsible for the content. So > according to RFC 5322, the poster's mailbox belongs in From:. > Remailed or not, the author belongs there. That is debatable. As long as the mailing list program tampers with the message's content, rendering its DKIM signature invalid, it can be argued that the mailing list program is rewriting the message's content, and therefore that the mailing list program now becomes "the system responsible for the writing of the message" (as per RFC 5322 parlance, section 3.6.2), and thus the mailing list address would earn its legitimate place in the Header-From field, making interoperability with rogue DMARC Senders a solved problem. 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
Stephen! Welcome! No one said making sausage was pretty. :-( On May 29, 2014, at 6:21 AM, Stephen J. Turnbull wrote: > 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? I don't think it would be appropriate to name people, but to a larger point, I have to apologize if I come across like a jerk. There are a lot of people trying to deal with DMARC across many forums, and my attempt to imbue a sense of breadth and depth was ham fisted. I live and learn. > >> 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). I was thinking of businesses that rely on the perfectly acceptable (but now at loggerheads with DMARC-based controls) practice of sending on behalf of customers. For example, "stationary" businesses (described towards the end of this mail: http://www.ietf.org/mail-archive/web/dmarc/current/msg00923.html). There are also businesses that perform "SMTP Cleaning" ala anti-spam filtering, plus "SMTP backup" services that people find enough value in to pay for. My ham-fisted point was that mailing lists are interesting for sure, but the scope of email (potentially) impacted by DMARC is bigger, and maybe we should think about the space a bit more generically. > Does DMARC actually impose significant burdens on the "corporate use > case", contrary to my belief? I don't personally carve up the email space along corporate vs non-corporate lines. People at corporations communicate via mailing lists. Before Yahoo and AOL went to p=reject policies, the advice was to keep DMARC-reject policies to "transactional" domains. "Transactional" in this context mapped to "email that isn't likely to be impacted by things that break DMARC like mailing lists" stuff like account notifications, receipts, not people-to-people. But it turns out that quite a few people create mini mailing lists to map a single recipient of a transactional piece of email to multiple recipients... like receipts going to bi...@family.org, where the parents and an archive are the final recipients. So, dang. > 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. >From your mouth to the Internet.God's ear! > 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.) One giant problem that ISPs face is that they have large numbers of customers that send email through their infrastructure but for domains that are not related to the ISP. Imagine a residential network providers with lots of customers that configured their email clients 20 years ago. It's largely worked up until now. Is the ISP supposed to contact each customer and get them to use the correct outbound SMTP servers? What is the right thing to communicate? Council of the Wise?! I always thought the IETF was a bunch of people hanging off the edge of the world, getting together every once in a while to maybe allow an accidental shared piece of understanding to be written down. > >> 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"
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
J. Gomez writes: > Missuse of DMARC's p=reject by Senders is here to stay. It won't go > away. It will only grow.[*] I'm not so sure. Anyway, that doesn't mean we need to sanction it. > 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, I disagree. The least disruptive adaption is whatever the users of the mailing list think is the least disruptive adaptation. That's why Mailman provides multiple mitigation options, and will probably add more as we think of them or they're contributed to us. > just like they already take ownership of the envelope's > ReturnPath-From. Ah, but "just like" is a complete misstatement of the situation. There's a big difference. Users on a mailing list think of the poster, not the mailing list, as responsible for the content. So according to RFC 5322, the poster's mailbox belongs in From:. Remailed or not, the author belongs there. According to the RFCs, Return-Path does not correspond to From, it's more similar to the semantics of Sender (but not identical). Whoever is going to handle delivery issues belongs in Return-Path. The remailing agent belongs there, because the poster, in general, doesn't know where the message is being sent, and can't help debug problems between the remailer and the subscriber. > 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. Actually, in GNU Mailman I suspect that going forward the default behavior will be either no mitigation (as now, just by momentum), or wrap-in-a-new-message-if-p=reject-detected, which is fully RFC conformant, although not iDevice-Apple-Mail-friendly. Some developers are just prickly curmudgeons.[***] cPanel and Plesk and RHEL are welcome to patch their versions, of course. [***] And that, too, is the way the world goes by. 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
Kurt Andersen writes: > I have to confess that I have not (yet) waded through the details > of TPA or ASL or ATPS, but from a corporate perspective, it would > be extremely unworkable for any but the smallest company to manage > DNS records to whitelist every list server on the internet that my > employees would happen to use. I don't see that a small company, or any company, would want to. Your employees are representatives of the organization when using (most of) your subdomains and your main domain, and "p=reject", with no mitigation on your part, seems perfectly reasonable to me.[1] Use a subdomain like just-for-fun.example.com or list-post.example.com with "p=none" if you want to permit personal posts to 3rd-party mailing lists. If companies can agree on a single such subdomain (or even 5 or 10 of them), the MUAs-for-people-prone-to-entering-passwords- in-email-forms can recognize it and treat that subdomain as suspicious. Eg, disabling all links in the email, or redirecting to a page which explains why clicking on these links is dangerous. If your employees find it tedious to switch return addresses, let them use XEmacs![2] The idea is that Yahoo! and AOL can use these protocols to mitigate the damage they are doing, not just in actual DoS, but in causing people to run around saying "The sky is falling! The sky is falling! Let's change the semantics of RFC5322.From!". I find the thought of "p=reject" domains putting their own resources on the line appealing. Footnotes: [1] The exception would be the small set of vendors like QuickBooks who provide you with value-added services, so that you have a business reason for whitelisting them. [2] Yes, I know what happened to Marie Antoinette. Just kidding. However, Emacsen-based MUAs are proof of concept. It is not that hard to write an MUA smart enough to automatically switch personalities when posting to a list or writing home to Mom. ___ 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 May 28, 2014, at 8:48 PM, Douglas Otis wrote: > Dear Tim, > > All that is needed is a few bandaids? Hi Doug, I don't see the problem space as allowing bandaid approaches. The widespread ability to build controls on top of stable domain level identifiers is relatively new. In my view, people that want to use these controls are stuck in one of two ways: 1. They're trying to modify how their email is structured so that controls can safely be put into place, and there is some sort of relationship that allows change to happen. Franck Martin wrote previously about this here: http://www.ietf.org/mail-archive/web/dmarc/current/msg00878.html 2. They're trying to address "legitimate-but-unauthorizable" email. In this bucket I'd put everything that is mostly beyond the ability for individual domain owners to change: mailing lists, forward-to-friend, services that send on behalf of users. Scott Kitterman wrote about this and asked about the scope of IETF work in this bucket: http://www.ietf.org/mail-archive/web/dmarc/current/msg00872.html Pain due to inaccurate deployment of controls is the domain owner's problem (#1 above). There (should be!) plenty of feedback available for domain owners to recognize their own problems. Pain due to everything else (#2 above) is something domain owners can't expect to solve on their own. It's in this area that "bandaids" might work in the short term (like publishing lists of exceptions), but long term I'd personally prefer not to see a codified model of exceptions. I think it would be better to specify how impacted email in bucket #2 can be dealt with, but not with a goal of preserving all existing email use cases. IMO a better goal would be to specify how specific categories of email should be presented. For example, codify how mailing lists go about their business (maybe: adhere to relevant RFCs + DKIM sign with ML's domain + perform OAR-like checks). A different example: analyze the use of "Reply-to:", determine what is preferable behavior, and codify what should be expected. The resulting specifications would at least tell developers (across the spectrum from MTA through MUA) what they need to do to interoperate. > > The motivation behind TPA-Label was to ensure both quick and efficient > methods to offer necessary feedback to receivers. DMARC already expects > receivers to offer failure feedback to DMARC domains. Unfortunately, once > the DMARC domain has decided which third-parties need to be granted > exceptions, there is no way to do so. It seems dangerous to suggest this > can be hard-coded in the form of informal lists indicating which DMARC > domains should be ignored. I think I understand the motivation. I guess I'm in the horrible position of viewing TPA-Label as a bandaid, given my own view of the scope and amount of work involved in making email suck less. I don't mean to disparage TPA-Label -- I just mean that given a finite amount of focus and fuel, I'd prefer to work out what I wrote about above: "specifying how impacted email in bucket #2 can be dealt with". > > In the case of Yahoo, there is a real issue they are attempting to mitigate. > It would be nice to have a solution able to deal with massively compromised > user accounts, as ugly as that is. This is an issue that is not going away > any time soon. The issue is much worse in China, for example. Please don't > decide being helpful in such situations is simply too hard. Is it really > better to create lists about which domains get ignored? It seems this quickly > degrades DMARC's initial intent, which was to offer results receivers felt > safe to act on. Is this still a worthy goal? One facet of the problem that Yahoo & AOL are addressing via DMARC-based controls goes beyond "compromised user accounts". A malware-infected PC's local address book gets scraped, and the infected PC emits spam/malware that spoofs the owner of the PC's email address (because fraud appearing to be from a known friend/colleague is pretty effective fraud). This fraud does not flow through Yahoo or AOL. I hope the above shows that the size and scope of difficult problems is not something I'm looking to work around. IMO bandaids are exception-lists and mechanisms like TPA-Label, and the difficult (but necessary) work remains in proposing, researching, specifying, implementing, and advocating for how well established mailing practices can interoperate in an email environment where stable domain-level identifiers are the norm. -= Tim ___ 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 May 29, 2014, at 5:05 PM, Kurt Andersen wrote: > On 2014-05-29, 16:26 , "Hector Santos" wrote: > >> . . .the idea is to lookup a 3rd party domain for >> authorization to sign or resign originating author domain mail. >> >> . . .The problem . . . is that . . . [i]t would not >> scale for the larger domains > > I have to confess that I have not (yet) waded through the details of TPA > or ASL or ATPS, but from a corporate perspective, it would be extremely > unworkable for any but the smallest company to manage DNS records to > whitelist every list server on the internet that my employees would happen > to use. > > Even if I did, why would I want to give blanket permission for all of > those list services to sign on my behalf? I doubt that I would trust them > not to be exploited - even such a highly esteemed organization as IETF :-) Dear Kurt, There seems to be some confusion about how TPA-Labels would operate. It is an Authorization scheme. At no time would any other domain be able to sign on your behalf. It simply permits specific alignment exceptions regarding both domains and headers for those domains your company allows employees to use. This could also be setup to automatically authorize mailing-lists used by your industry, and all outsourced services without exchanging any credentials or granting network access. I doubt any company executive will today blithely exchange credentials to permit an HVAC firm to submit invoices. By requiring a Sender header field, Outlook will modify what is seen on the From header to say Intuit.com on behalf of Linkin.com when sending out invoices on your behalf. Recipients should not have a hard time understanding who both signed and sent the message. Most MUAs will even allow you to normally display the Sender header when it is there. Would this be a major issue for Linkedin? At least there would be a far greater certainty rogue messages will continue to be rejected as desired. 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 May 29, 2014 3:09:44 AM EDT, "Murray S. Kucherawy" wrote: >On Thu, May 29, 2014 at 12:06 AM, John R Levine >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] 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
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On 5/29/2014 4:19 AM, Stephen J. Turnbull wrote: >Franck Martin writes: >> Time to stop these non-technical threads > > These threads are input to the BCP process, at the very least. +1 d/ -- 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
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 mailto: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
On Thu, May 29, 2014 at 1:28 PM, J. Gomez 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
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 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] 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 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] 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 agre
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 th
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
On Thu, May 29, 2014 at 12:06 AM, John R Levine 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. -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
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
On May 28, 2014, at 1:13 PM, Tim Draegen wrote: > On May 28, 2014, at 12:37 PM, John Levine wrote: >>> Its not clear to me that gmail.com needs to tell another service to trust >>> the OAR from a given third party, the choice to trust that service could >>> easily be up to the receiving service. >> >> Good point. That's why I keep saying that one or a few shared >> DMARC-bypass whitelists would work a lot better than anything >> per-sender. The set of senders where it makes sense to skip DMARC >> checks for Yahoo or AOL or Gmail addresses are likely to be the same. > > Doug, > > I read through the spec, and it is clear a lot of work went into it. I think > I echo Brandon and John's above opinions. > > From my PoV, there exists an immense pile of work to get through before the > draft under discussion becomes a solution. Aside from support, tooling, > getting senders to deploy accurately and getting receivers to perform > additional checks.. what is missing is the justification for the additional > work. > > DMARC is a tradeoff between keeping things as simple as possible (as > unnecessary complexity acts as a giant barrier to adoption), building on > existing technologies (as new code/libraries in the world of email means > tacking on additional calendar years), and solving a problem that hurts > enough to warrant doing anything at all. > > 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, Dear Tim, All that is needed is a few bandaids? The motivation behind TPA-Label was to ensure both quick and efficient methods to offer necessary feedback to receivers. DMARC already expects receivers to offer failure feedback to DMARC domains. Unfortunately, once the DMARC domain has decided which third-parties need to be granted exceptions, there is no way to do so. It seems dangerous to suggest this can be hard-coded in the form of informal lists indicating which DMARC domains should be ignored. In the case of Yahoo, there is a real issue they are attempting to mitigate. It would be nice to have a solution able to deal with massively compromised user accounts, as ugly as that is. This is an issue that is not going away any time soon. The issue is much worse in China, for example. Please don't decide being helpful in such situations is simply too hard. Is it really better to create lists about which domains get ignored? It seems this quickly degrades DMARC's initial intent, which was to offer results receivers felt safe to act on. Is this still a worthy goal? 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
- Original Message - > From: "Dave Crocker" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 3:48:39 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use > while still offering its normal > protection > > On 5/28/2014 3:45 PM, Franck Martin wrote: > > Before one can move to p=reject, it needs to take control of all the email > > streams. > > > OK. Thanks for the clarification. You are welcome > > The examples you provide are for third parties that have a business > relationship with the domain owner. > > The interesting challenge is when a random user sends legitimate mail > from an un-associated third party. > In many cases the domain owner IT department does not know an employee decided to use/contract someone to send emails... This case is not too far from the one Jim pointed to, and amount to detect and then inform the third party to pick from a set of possible solutions. ___ 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/28/2014 3:45 PM, Franck Martin wrote: > Before one can move to p=reject, it needs to take control of all the email > streams. OK. Thanks for the clarification. The examples you provide are for third parties that have a business relationship with the domain owner. The interesting challenge is when a random user sends legitimate mail from an un-associated third party. d/ -- 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
- Original Message - > From: "Dave Crocker" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 3:29:30 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use > while still offering its normal > protection > > On 5/28/2014 3:28 PM, Franck Martin wrote: > > how you get third parties sending emails on your behalf to become > > compliant. > > > Please clarify what that means. Before one can move to p=reject, it needs to take control of all the email streams. Here are a few use cases: -sending marketing emails via an ESP -sending surveys to employees and non-employees -contracting a third party helpdesk -contracting a third party Customer Relation Manager -contracting a third party travel system -Apps in the cloud and their notifications system -mobile phones using the telecom provider email system -service providers sending email to employees (HR, health, insurance, retirement,...) to their employee address or personal address -sending emails to interns/contractors, who like to forward everything to their primary email account - Some solutions: add to spf/give dkim key, delegate a subdomain, delegate records in a subdomain, use the third party domain. ___ 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/28/2014 3:28 PM, Franck Martin wrote: > how you get third parties sending emails on your behalf to become compliant. Please clarify what that means. d/ -- 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
- Original Message - > From: "Jim Fenton" > To: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 3:18:04 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use > while still offering its normal > protection > > On 5/28/14 2:54 PM, Dave Crocker wrote: > > On 5/28/2014 2:52 PM, Scott Kitterman wrote: > >> How do we define the scope of work for this list? > > > > Merely as an example, one line of effort could be towards methods of > > DKIM signature survival through mailing lists. > > > > It's not a new topic and it's not an easy one, and it doesn't even have > > the string D-M-A-R-C in it, but any real progress for this could be > > quite helpful in mitigating collateral damage with especially aggressive > > DMARC use. > > 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? > > I want to make sure that isn't forgotten just because it doesn't affect > IETF directly. > It should not be forgotten. There are also all the use cases on how you get third parties sending emails on your behalf to become compliant. There are so many options available. The question, I have, is if the format of an RFC is the proper format to give implementation advice to "webmasters". Will they read it? or should it be a nice glossy email marketer style blog/white paper? ___ 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/28/14 2:54 PM, Dave Crocker wrote: > On 5/28/2014 2:52 PM, Scott Kitterman wrote: >> How do we define the scope of work for this list? > > Merely as an example, one line of effort could be towards methods of > DKIM signature survival through mailing lists. > > It's not a new topic and it's not an easy one, and it doesn't even have > the string D-M-A-R-C in it, but any real progress for this could be > quite helpful in mitigating collateral damage with especially aggressive > DMARC use. 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? I want to make sure that isn't forgotten just because it doesn't affect IETF directly. -Jim ___ 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/28/2014 2:52 PM, Scott Kitterman wrote: > How do we define the scope of work for this list? Merely as an example, one line of effort could be towards methods of DKIM signature survival through mailing lists. It's not a new topic and it's not an easy one, and it doesn't even have the string D-M-A-R-C in it, but any real progress for this could be quite helpful in mitigating collateral damage with especially aggressive DMARC use. d/ -- 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 Wednesday, May 28, 2014 14:11:36 Dave Crocker wrote: > On 5/28/2014 2:07 PM, Tim Draegen wrote: > >> > I have been in extensive correspondence with the people who develop and > >> > maintain the Mailman discussion list software, and can only find that > >> > suggestion gratuitously insulting.> > > 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, and also developers behind > > businesses that rely on email, and also a slew of decision makers... and > > they're all trying to understand how they can fix things without going > > backwards. > All these background technical discussions sound like they are fascinating. > > Given that this list is supposed to be for technical discussion of > matters relating to DMARC -- with an eye towards possible > standardization -- and given that specification of methods for > interworking with mailing lists is such an extremely salient issue, > perhaps folks could consider moving presentation and review of design > choices into this forum? This may sound like a flip question, but it's a serious one: Since, as I understand it, DMARC will not be an IETF specification, what is the IETF work here? Is there a clear boundary between the independent submission's requirements and what the IETF should be doing? It feels like the demarcation (pun intended) is DMARC is immovably what's currently deployed by a number of large providers that invested in it and the IETF work is to clean up the side effects. Now that's not a very pretty way to put it, but I don't think it's completely wrong either. How do we define the scope of work for this list? Scott K ___ 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/28/2014 2:07 PM, Tim Draegen wrote: >> > I have been in extensive correspondence with the people who develop and >> > maintain the Mailman discussion list software, and can only find that >> > suggestion gratuitously insulting. > 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, and also developers behind businesses that rely > on email, and also a slew of decision makers... and they're all trying to > understand how they can fix things without going backwards. All these background technical discussions sound like they are fascinating. Given that this list is supposed to be for technical discussion of matters relating to DMARC -- with an eye towards possible standardization -- and given that specification of methods for interworking with mailing lists is such an extremely salient issue, perhaps folks could consider moving presentation and review of design choices into this forum? d/ -- 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 May 28, 2014, at 12:37 PM, John Levine wrote: >> Its not clear to me that gmail.com needs to tell another service to trust >> the OAR from a given third party, the choice to trust that service could >> easily be up to the receiving service. > > Good point. That's why I keep saying that one or a few shared > DMARC-bypass whitelists would work a lot better than anything > per-sender. The set of senders where it makes sense to skip DMARC > checks for Yahoo or AOL or Gmail addresses are likely to be the same. Doug, I read through the spec, and it is clear a lot of work went into it. I think I echo Brandon and John's above opinions. >From my PoV, there exists an immense pile of work to get through before the >draft under discussion becomes a solution. Aside from support, tooling, >getting senders to deploy accurately and getting receivers to perform >additional checks.. what is missing is the justification for the additional >work. DMARC is a tradeoff between keeping things as simple as possible (as unnecessary complexity acts as a giant barrier to adoption), building on existing technologies (as new code/libraries in the world of email means tacking on additional calendar years), and solving a problem that hurts enough to warrant doing anything at all. 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, =- Tim ___ 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 May 28, 2014, at 12:07 AM, Brandon Long wrote: > So... > > I think this buries the lede a bit more than the OAR suggestion does. I > could imagine something like this for broadcasting who a service trusts the > OAR header from. > > This basically would require someone like Yahoo/Gmail to host some 30k DNS > records granting any one of those third party services the ability to send > mail for yahoo.com/gmail.com. > > For a service at this scale, you'd need to only do this for places where you > "trust" their Authentication-Results header. There is a potential issue of > conflicting AR headers, which is one benefit of the OAR. > > Its not clear to me that gmail.com needs to tell another service to trust the > OAR from a given third party, the choice to trust that service could easily > be up to the receiving service. > > Finally, doesn't this imply a potentially large number of DNS queries? Given > the various mechanisms for finding the domain, and given that you have to > look up the tpa record to know whether that mechanism is supported, it would > seem you would need to look up tpa records for up to 7 possible domains, and > potentially more with sub-domain checking. Dear Brandon, http://tools.ietf.org/html/draft-kucherawy-original-authres-00 You'll see statements in the TPA-Label draft about including authentication-results and indeed this new header should be referenced as well. Sorry about the omission. When there is a problem, the DMARC domain is still unable to respond to what might cause expensive damage when misplaced trust leads to customer attrition whenever uncontrolled sources are allowed to flood inboxes spoofing their identity. The TPA-Label draft permits an effective response in minutes. TPA-Label does not imply a large number of DNS transactions, unlike SPF or even DKIM. TPA-Label is a single transaction directed toward a DMARC domain. There should only be one DMARC domain recognized per message. Of course, as with any DNS transaction, this can be redirected to other domains. It is still a single transaction, unlike SPF which can result in more than 100 transactions with any number of additional redirections involving other domains completely unrelated to domains seen in the exchange. The TPA-Label can assert which validation methods should be used to help further reduce the number of DNS transactions needed. A shared DMARC-bypass whitelists would remove control away from the DMARC domain that has an incentive to ensure protection. Community white-lists would make responding to any abuse impractical, to say the least. In today's environment, an ability to respond should not be overlooked. A TPA-Label authorization would not be granting anyone the ability to send email for a domain. This authorization simply permits alignment exceptions for specific third-party services that must still permit the validation of their own domain. The authorization can also stipulate third-party domains must include their domain in a Sender or a List-ID. If a problem is seen by any of their messages, the DMARC domain can retract authorization in minutes. Those who apply DMARC alignment checks would be able to make exceptions for these third-party messages based on advice given directly from the DMARC domain. TPA-Labels as a disruption remedy can be done fairly rapidly since this would involve only those implementing DMARC. Changing 30K mailing lists where one might be running in the basement of a local church should be expected to take much longer. Google already provides free recursive DNS for anyone to use. It seems possible, Google could even get the ball rolling by offering a "_smtp._tpa.gmail.com" zone that others might wish to reference. This would allow an easy and immediate solution for any DMARC domain willing to allow Google to manage their third-party services. TPA-Labels will require the support of some large ISP before is likely to gain adoption. I'll update the draft to include draft-kucherawy-original-authres-00. Regards, Douglas Otis > On Tue, May 27, 2014 at 7:49 PM, Douglas Otis wrote: > Dear DMARC WG, > > A draft has been submitted for review. It covers past failures while also > providing a path forward. > > I have experience with similar systems operating at much higher scale without > difficulty or using much in the way of resources. Serving several very large > ISPs worth of users making queries against every received message that then > returned about 2 billion unique resource responses. Originally, the service > was free. > > In the wake of a massive compromise of accounts, some fairly large ISPs are > doing perhaps the only thing that is not (yet) ignored, DMARC. > > However, this new scheme only needs to sustain queries against already > validated third-party domains, but that then fail DMARC alignment assertions. > The number of resource records likely needed by large ISPs will be
Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection
>For a service at this scale, you'd need to only do this for places where >you "trust" their Authentication-Results header. There is a potential >issue of conflicting AR headers, which is one benefit of the OAR. > >Its not clear to me that gmail.com needs to tell another service to trust >the OAR from a given third party, the choice to trust that service could >easily be up to the receiving service. Good point. That's why I keep saying that one or a few shared DMARC-bypass whitelists would work a lot better than anything per-sender. The set of senders where it makes sense to skip DMARC checks for Yahoo or AOL or Gmail addresses are likely to be the same. Also, considering the complete lack of interest that two large mail providers have shown in mitigating the costs of their DMARC policy decisions, it seems pretty unlikely that they'd implement anything like this for their own domains. >Finally, doesn't this imply a potentially large number of DNS queries? For per-user lists, hard to say. For a shared list, it should be insignificant, no more than one per message. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
