Alan, May be best is to separate authentication from policy.
So DMARC does not replace any existing protocol authentication scheme. It just replace any protocol policy scheme. DKIM is purely authentication, ADSP is policy upon DKIM SPF has authentication and policy DMARC is an extra bit of authentication (the alignment part) and mainly policy So when you have so many policies to choose from, it is better to remove ambiguity and as DMARC is built on top of SPF and DKIM and more recent, then best to ignore the policy components of the underlying protocols. Of course as a receiver you can do how you feel (and not follow the spec), and can just state it in the aggregate report by the disposition type. On 7/6/12 12:47 PM, "Alan Maitland" <[email protected]> wrote: >Michael, > >Thank you for your thoughtful response. I was apparently under the >mistaken impression that DMARC built upon the other technologies (e.g., >SPF, DKIM, Domainkeys, etc) to extend and combine their usefulness >rather than serving as an outright replacement for them. > >For our own modest needs to ensure domain name reputation protection >from miscreants misusing domain names when sending out their UCE, SPF >has always been sufficient and has worked well for its stated purpose. >Certainly, the scope and needs of other environments are going to differ >and that may well make the difference in a desire to adopt DMARC. > >Best, > >Alan M > >On 7/6/2012 11:49 AM, Michael Adkins wrote: >> We thought through this very thoroughly. One of the goals of DMARC is >>to >> put a predictable system in place. Leaving older mechanisms that were >> found to be insufficient in play opens an enormous can of worms in terms >> of implementation complexity and variability of results. >> >> Systems that don't support DMARC can keep doing what they are doing >>today. >> Systems that support DMARC and receive email for domains that don't >>have >> DMARC records can keep doing what they are doing today for those >>domains. >> Those are both fine. >> >> If SPF is sufficient for you, but you would like to get reports, then >> leave your SPF record the way it is, don't sign your email, and set p= >>to >> an action that equates to your SPF directive. >> >> If ADSP is sufficient for you, but you would like to get reports, then >> leave your ADSP record the way it is, don't publish an SPF record, and >>set >> p= to an action that equates to your ADSP policy. >> >> If neither SPF or ADSP is sufficient for you, and you would like to use >> DMARC, then your DMARC record should be considered a replacement for the >> other mechanisms. Domains that currently have SPF or ADSP records are >> likely to leave them in place as they roll out DMARC, and probably for >> much longer, so that they continue getting whatever benefit those >>records >> currently provide at mailbox providers who haven't deployed DMARC. >>Trying >> to use them in conjunction can only introduce bugs, unwanted >>variability, >> and more false positives than the DMARC mechanism should cause. >> >> >> On 7/6/12 9:14 AM, "Alan Maitland"<[email protected]> wrote: >> >>> On 7/6/2012 8:55 AM, Chris Lamont Mankowski wrote: >>>> Murray, >>>> >>>> The use case that I'm trying to address is when a sender is sending to >>>> DMARC enabled receiving MTAs and also to non-DMARC enabled MTAs. My >>>> understanding is that SPF ~all and -all (as well as ADSP) are >>>> currently not stringently adhered to by receiving MTAs. Those >>>> directives may only end up being a weight in the grand scheme of >>>> things. >>>> >>> >>> One would hope the SPF -all syntax is indeed respected by any MTA that >>> supports SPF. >>> >>> If what you state is true, then when a domain holder publishes a DNS >>>txt >>> RR which says "v=spf1 -all", the receiving MTA would save itself a boat >>> load of work by simply interpreting that correctly as what it is and >>> send the incoming spam message right to the bit bucket (arguably also >>> recording the source of the send for use in whatever crime and >>> punishment plan your MTA is configured to perform in response to such >>> behavior). >>> >>> Alan M. >>> >>> _______________________________________________ >>> 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) _______________________________________________ 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)
