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)
