(As you top-post, I'll do it too.) I want to use DMARC as a sender to explicitly convey policy to the receiver regarding what to do when they get email which purports to be from my domains and which is not signed with DKIM, or which carries an invalid DKIM signature.
SPF already allows to convery that policy with its "-all" mechanism. But for DKIM the help of DMARC is needed for senders to publish their policy regarding failures in DKIM checking or DKIM absence. The first paragraph in DMARC draft specification says: "The email ecosystem currently lacks a cohesive mechanism through which email senders and receivers can make use of multiple authentication protocols in an attempt to establish reliable domain identifiers. This lack of cohesion prevents receivers from providing domain-specific feedback to senders regarding the accuracy of authentication deployments. Inaccurate authentication deployments preclude receivers from safely taking deterministic action against email that fails authentication checks. Finally, email senders do not have the ability to publish policies specifying actions that should be taken against email that fails multiple authentication checks." So I think my use case falls in the DMARC ballpark. Also, my use case would be to achieve that from above, without breaking mailing lists. Regards, J. Gomez On Monday, April 01, 2013 8:22 PM [GMT+1=CET],Michael Adkins wrote: > Could you please describe the phishing problem you have that you would > like to use DMARC to prevent? It sounds like you have a different use > case in mind than it was designed to cover. > > On 3/31/13 3:24 PM, "J. Gomez" <[email protected]> wrote: > > > On Sunday, March 31, 2013 11:45 PM [GMT+1=CET],Steve Atkins wrote: > > > > > On Mar 31, 2013, at 2:32 PM, "J. Gomez" <[email protected]> > > > wrote: > > > > > > > My suggestion of a "SoftFail" result for DMARC would happen when > > > > both SPF-by-itself passed AND DKIM-by-itself passed, AND when > > > > neither is aligned with the RFC5322.From header organizational > > > > domain. This suggested DMARC "SoftFail" would only be searched > > > > for by the receiver if a DMARC "Fail" has previously been > > > > found, i.e. if a DMARC "Pass" has previously been found then > > > > all DMARC processing (including searching for this suggested > > > > DMARC "SoftFail" condition) should end. Also, this suggested > > > > DMARC "SoftFail" processing would only take place if the > > > > suggested optional second policy for DMARC has been explicitly > > > > declared by the domain owner AND is different from the > > > > mandatory DMARC first policy. This suggested DMARC "SoftFail" > > > > result is to accommodate for mailing lists in the DMARC > > > > specification. > > > > > > > > (Additionally, it would be interesting to requiere that in this > > > > suggested "SoftFail" result for DMARC, the RFC5322.From header > > > > had to be part of the DKIM-signed headers in the email, even if > > > > its organizational domain was not aligned with the "d=" domain > > > > in the DKIM signature.) > > > > > > > > Obviously, to get SPF-by-itself to pass AND DKIM-by-itself to > > > > pass, DNS records for both have to be fine and dandy. So I don't > > > > understand your comments about DNS being screwed up. > > > > Regards, > > > > > > The main point of DMARC is to make decisions based on the content > > > of the From: header. If you're not looking at the From header, > > > you're outside the scope of DMARC. > > > > > > As far as defending against hostile attackers is concerned you've > > > raised the bar solely to requiring them to have a domain name, or > > > having access to a smarthost with a domain name. That's a low > > > enough bar as to be pretty much useless. > > > > Well, if you would think it was useless, then you would not opt > > into the optional second policy for SoftFail and stay with the > > default of only declaring the mandatory first policy for Fail in > > DMARC. > > > > This way, you are not lowering any bar whatsoever, if you feel you > > have no need to do it. _______________________________________________ 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)
