On May 22, 2014, at 9:09 PM, John Levine via dmarc-discuss <[email protected]> wrote:
>> 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. > > The encapsulation plan appears to assume that every MUA in the world > will be rewritten to recognize and unwrap anti-DMARC encapsulated mail. > > That seems kind of optimistic. > > With a shared whitelist, MTAs that interpret DMARC policies check the > whitelist to know when to skip the policy checks. The MUAs, mailing > lists, mail-an-article etc. don't change at all. The usual handles > for whitelists are DKIM signatures or IPs, neither of which need to be > tied to "forwarding domains". > > I agree that a whitelist published per sender is a poor idea, > combining the worst scaling aspects of just about every other > suggestion. Dear John, Calling what is needed a white-list would be a bit misleading. The list would indicate From-X by-Y (perhaps with Y-List-ID or Y-Sender) should not be rejected due to DMARC mis-alignment. This could be provided by a sender or whoever they designate. One list should be able to handle several large ISPs' traffic related to DMARC failures. A small number of servers could even handle the world's traffic This reduces feedback collection and support issues caused when legitimate mail is erroneously refused. By using a very lightweight scheme, email can continue to be used normally, while at the same time protecting all eventual recipients from being spoofed. This seems like a ideal solution for cleaning up after a massive compromise. Over time, the scheme could be retired, but sustaining the effort also provides their customers real benefits. Perhaps their way of saying sorry. Envision extensions that communicate pending needs, rather than waiting for DMARC feedback as a signal. For even very large domains, the overhead would be relatively small, especially when the related packets are kept to a minimum. I have managed a system responding to queries regarding each and every IP address seen entering an MTA while responding with millions of reject recommendations. This was being done for several fairly large ISPs with relatively short TTLs to be responsive to changes. DMARC mis-alignment issues would be child's play in comparison. The receiver has already done the heavy lifting dealing with IP reputation, SPF, DKIM, and DMARC. The sender only needs to respond to a single small query questioning the hash of the source identifier which relates to any of their DMARC mis-alignment issues. Regards, Douglas Otis _______________________________________________ dmarc-discuss mailing list [email protected] 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)
