On Apr 25, 2013, at 11:51 PM, Matt Simerson <m...@tnpi.net> wrote: > > I noticed there's a dearth of DMARC implementations. I wanted to try DMARC so > I wrote my own. Mostly. I haven't completed the reporting feature. Yet. The > code is here: > > https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/dmarc > > The implementation is a plugin for qpsmtpd, a MTA with a handy plugin > architecture. The man page is inline at the bottom of this message. > > Due to the scarcity of DMARC implementations, I've been thinking I should > package this up as a perl module, so others could use it. This might be a > place to gauge interest in such an endeavor. I'm not sure how to handle > implementation, as this DMARC plugin depends on the SPF and DKIM plugins, > which validate and store results before this plugin runs. I'm interested in > feedback. > > Matt > > I have processed 17,140 messages with DMARC (most connections get terminated > for policy reasons long before content scanners like DMARC). Of those > messages, 11,095 (65%) had no published DMARC policy. Another 1,024 skipped > checking because they were authenticated senders. Twenty seven of the > messages passed relaxed alignment (amazon.com) and 881 passed DKIM strict > alignment. 61 messaged passed SPF strict alignment. 367 messages were > rejected by the domain existence test. The rest were rejected because they > forged the From header of a domain that published DMARC records (mostly > google.com). The only 'odd' failures were two of these: > > dkim: fail, tolerated, domain: dmarc.org, selector: clochette, result: fail > (message has been altered), policy: o=~, name: sender, policy_result: > neutral, policy: o=~, name: author, policy_result: neutral, policy: > r=msk+d...@blackops.org; dkim=unknown; atps=y, name: ADSP, policy_location: > blackops.org, policy_result: neutral > dmarc: skip, no policy for blackops.org (same org) > > Not a DMARC failure, but a DKIM failure, coming from an email list. Not > terribly surprising, except that it's the DMARC discuss list. :-) > > --------------------- > > NAME > Domain-based Message Authentication, Reporting and Conformance > > SYNOPSIS > DMARC is an extremely reliable means to authenticate email. > > DESCRIPTION > From the DMARC Draft: "DMARC operates as a policy layer atop DKIM and > SPF. These technologies are the building blocks of DMARC as each is > widely deployed, supported by mature tools, and is readily available to > both senders and receivers. They are complementary, as each is > resilient to many of the failure modes of the other." > > DMARC provides a way to exchange authentication information and > policies among mail servers. > > DMARC benefits domain owners by preventing others from impersonating > them. A domain owner can reliably tell other mail servers that "it it > doesn't originate from this list of servers (SPF) and it is not signed > (DKIM), then reject it!" DMARC also provides domain owners with a means > to receive feedback and determine that their policies are working as > desired. > > DMARC benefits mail server operators by providing them with an > extremely reliable (as opposed to DKIM or SPF, which both have > reliability issues when used independently) means to block forged > emails. Is that message really from PayPal, Chase, Gmail, or Facebook? > Since those organizations, and many more, publish DMARC policies, > operators have a definitive means to know.
Dear Matt, Murray rightfully decided ATSP as it is will not get off the ground. IMHO, requiring mailing lists to change DKIM signature was a poor choice. A better approach is to signal ATPS within DMARC policy assertions. It would limit ATPS transactions to only when a message failed DMARC && DMARC indicated use of ATPS which would entail one additional DNS transaction for mailing lists to remain functional. To really get DMARC to work as advertised, DKIM needs to be repaired. See: http://www.bungi.com/Dom-v6.pdf 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)
