What sort of phishing problem do you have? On 4/1/13 12:43 PM, "J. Gomez" <[email protected]> wrote:
>(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) _______________________________________________ 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)
