On 5/7/15 5:15 PM, Terry Zink wrote: >> Roughly 80% of those reports are from Google, Yahoo!, and Microsoft. >> >> Is 20% success sufficient for me to switch to p=reject? I guarantee you it >> is >> not. At the end of the day, without the large providers on board, any >> solution that requires change at both the sender and the receiver needs the >> large providers on board or it's useless. > And from Murray: > >> There's still that pesky registration problem to address. > Checking DNS for third party authorization may be workaround for this problem > at a large provider (Microsoft) but publishing them on behalf of Microsoft > would be a tough (probably impossible) sell. If I own my own domain, I can > keep track of mailing lists for a few dozen users. But something like > outlook.com has millions of [users]. The registration problem means that > either we have to review hundreds or thousands of additions per day (or a > bootstrap of tens of thousands) or automate it. But if we automate it, that > has its own problems: > > - What's the threat model? How do we prevent malicious sign ups? > - The outlook.com sign-up is self-serve; this means that anyone can sign-up > for outlook.com and create their own mailing lists and subscribe to it, and > then outlook.com would need to automatically add that to its DNS zone. In > other words, a complete outsider can register something in the zone that is > maintained by Microsoft. This can be abused (a spammer could blow up the zone > by doing this tens or millions of times per day using a botnet). > - When do we remove things from DNS? > > That's a big risk. I can't speak for the company, but I think we'd rather > live with the DMARC p=reject inconvenience than allow a regular user to > publish anything to its DNS zone. Dear Terry,
Many third-party services now munge who authored a message to sidestep inappropriate DMARC restrictive policies. When a DMARC domain can't conclude which third-party services employed by their users aren't causing any phishing threats when they have the benefit of DMARC feedback, outgoing logs, and a sizable spam trap infrastructure, their lack of effort creates a dangerous situation. DMARC now means people have less ability to communicate effectively using third-party services. Some receiving ESPs mitigate some of their complaints by changing "reject" to "quarantine". Looking into a spam folder is likely to reveal rather nasty malware looking like messages unfairly rejected due to inappropriate DMARC assertions. There are some choices that should help make the situation better. 1) define reasonable fallback profiles for ESPs who miss-apply restrictive DMARC policy to permit acceptance based on a validated Sender header field clearly shown to users. 2) define a replacement From header field. The example I gave included a field to track current resources when conveyed over a channel that normally handles IM as well as having a group friendly display to play the role of Subject Tag. 3) We have had experience providing almost exactly what would be needed to support a TPA-Label lists. We tracked behaviors of all known mailing-lists, differentiated those from bulk senders, news feeds on behalf of friends, etc. While you may have millions of users, the number of third-party services in use is much much less. I am convinced doing a good job at simply applying the information known by the DMARC domain would allow all headers to be safely used by email while at the same time making mail safer. If you are interested, perhaps we could get together to demonstrate how the feedback can be automated and managed. Doing this while at the same time guarding access to user accounts should attract happy and even paying customers. I am not a fan of ATPS. IMHO nothing justifies a special DKIM signature, changes to Authentication headers or optional hashes for labels. How in the heck would a third-party keep track of which hash is needed? The reasons claimed for using special DKIM signatures can be replaced by simple DMARC assertions to indicate which conventions are adopted. There would not be any increased DDoS risk nor a need to have everyone change how DKIM is used. But of course, people want to leave their 'd' mark:^) Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
