[Lost DMARC-discuss in the response...] Thanks for your reply. Not responding inline due to email client evilness - sorry.
Re: maintaining a list of valid forwarding domains... It's not just large providers that want to use DMARC, and it's not a constant list of the same "service" domains doing the From address munging. It's not only mailing list configurations that currently fail to interoperate with DMARC - it's newspaper "send this to a friend" services and individual websites who might implement the same type of service (e.g. a photography website might have an email to a friend link, or an independent shop); if a user has to have at least one fail (and an active site admin) before they can send links from any given site, this doesn't seem like the road to nirvana. An effective (for both providers and users) solution in my mind would make this automated or unnecessary rather than eternal. Re: preventing authorized domains from going rogue... Again, is this the way things have to be - or just the way things are because of choices we've made that are relatively easily altered despite a long history of "we've always done it that way"? For some DMARC uses, even a short period of time with a rogue site sending mail on their behalf is Bad. Same for someone who abuses an author advertised exception in order to phish away against a major target like eBay. An ideal solution would automatically prevent rogue sites from anywhere outside of the control of the domain. Solutions such as encapsulation of the original message or noting how to recreate the message in a manner that would pass DKIM, or addressing as the site actually sending the message all meet a "least work" standard that various whitelist proposals all seem to fail as far as I've seen. Just MHO, -- Les Barstow, Senior Software Engineer Return Path, Inc. - The Global Leader in Email Intelligence -----Original Message----- From: Douglas Otis [mailto:doug.mtv...@gmail.com] Sent: Thursday, May 22, 2014 9:41 AM To: Les Barstow Cc: Shal Farley Subject: Re: [dmarc-discuss] reputation axioms, was DMARC woes Dear Les, Thank you for the good questions. See comments inline: On May 22, 2014, at 5:25 AM, Les Barstow <les.bars...@returnpath.com> wrote: > For any proposal that allows sending domains to allow third party web sites > to resend (with or without authentication): > > 1) How does the sending domain maintain a list of so many sites? How do they > learn about them, even? And - each separate sending domain listing each > permitted resender? Will this result in a lot of network traffic? When an Author Domain has a valid reason to assert a restrictive DMARC record for a domain being used by typical email users, the TPA scheme offers a way to ensure services currently being used are not disrupted. By collecting their DMARC feedback and comparing it against their outbound logs, this should identify which "abuse" is actually legitimate messaging from their domain. This should be part of a normal review prior to asserting any restrictive DMARC policy request. This would allow the Author Domain to collect the purported ~30K or so domains being used. The network traffic from the Author Domain would be of a single DNS transaction that is cached. This would represent a very small contribution going toward their users' desire to use an otherwise likely free service and toward the feedback they receive about potential abuse. This would benefit almost every aspect of the DMARC process for both senders and receivers. At the same time, it would allow them to boast th! ey are protecting both their users and their users' recipients. This would turn a negative caused by loss of passwords into a fairly nice positive for anyone else considering their service and still wanting to use email as normal. I managed a system responding to the traffic of several very large ISP's entire user base. It offered not just 30K records, but several million. There was no problem dealing with that level of traffic. Since we were using this approach to block traffic, some malefactors would attempt to DDoS the system as they launched a new botnet cluster. Since TPA represents something allowing traffic rather than blocking, there should be minimal DDoS incentive. Of course any system can be attacked, but even so the process was still able to endure a fairly high level of abuse. What we were doing was not as transactionally clean as TPA either. We assigned every client their own synthetic domain. Something along the line of gstatic.com. > 2) How quickly will the mechanism respond if the purportedly responsible > third party is hacked or goes rogue? Is staying on top of this the > responsibility of each and every DMARC sender who permits third party > resending? Any large Author-Domain will be monitoring for abuse. In this case, they can send a notification to the domain with the problem. If the problem continues, after the notification, they can simply disable their authorization. Sorry, but this is now things work today. DMARC would make this more effective. > 3) What mechanism does the user see that this behavior was explicitly allowed > by the sender, and what path did it take? Is this simply the "on behalf of" > that some MUA's show for mailing lists? Is that sufficient? The MUA should not matter that much. This would dramatically reduce the attack surface helping all those involved. I suspect at this point, DMARC no longer is being applied as they might have desired for their domain. TPA would allow protections to be sustained. > This feels like applying lots of bandages to a mostly internal wound. Sure it > might stop some bleeding, but it's not addressing the problem and could hide > problems if not done correctly. eBay just announced a breach. These issues are affecting everyone. Large providers represent high reward targets, and bad actors keep continuing trying until they find a way in. After bad actors have details about who communicates with whom, true evil becomes real and is no longer just an "internal" wound. It quickly becomes a global threat causing real harm. DMARC + TPA could be a real game changer. > -- > Les Barstow, Senior Software Engineer > Return Path, Inc. - The Global Leader in Email Intelligence > > > -----Original Message----- > From: dmarc-discuss [mailto:dmarc-discuss-boun...@dmarc.org] On Behalf > Of Douglas Otis via dmarc-discuss > Sent: Wednesday, May 21, 2014 3:42 PM > To: Shal Farley > Cc: dmarc-discuss@dmarc.org > Subject: Re: [dmarc-discuss] reputation axioms, was DMARC woes > > > On May 8, 2014, at 11:34 AM, Shal Farley <s...@roadrunner.com> wrote: > >> Douglas, >> >>> A marketing advantage would be afforded to domains willing to do the >>> "right thing" by indicating to recipients via a lightweight >>> transaction whether a specific domain should be excluded from >>> receiving a reject or quarantine. >> >> I know nothing of the legal argument, but as an email user I would argue >> that should be a Sender domain, instead of or alternative to a From domain. >> That would let me exclude the email lists of which I'm a member. >> >> That is, I'm perfectly content to let DMARC take out all the scam/spam >> messages with forged AOL addresses, even those pretending to be from lists. >> I expressly do /not/ want to whitelist all of AOL. But I want to allow into >> my Inbox messages from AOL via lists that I know. It would be icing on this >> cake if the list's own SPF or DKIM signature (if present) were used to >> authenticate that the message came via the list I know. >> >> Making the whitelist personal to each receiving user avoids the costs and >> other disadvantages of setting up a "list authority", but it does violate >> the "you can't teach the user anything" principle, and it is also outside >> the scope of DMARC itself. > > Dear Shal, > > Sorry about being slow to respond. I am working on a document that should > permit Author-Domains a means to assert exceptions permitted for specific > authenticated domains (based on their review of DMARC feedback as a means to > permit actual user behaviors.). This is information recipients simply do not > have and represents something that only the Author-Domain should be making. > Authentication can use any number of methods such as SPF, DKIM, or even TLS > and also stipulate content of a List-ID and/or Sender header field. I should > have a version ready shortly to be published as an I-D. This might move > rfc6541 to historic (if things go well). Regards, Douglas Otis _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
