Thank you Michael. Last week DKIM was described as a solution for transactional email. Its not ideal for situations involving end user emails. (Murray please correct my mis statement if I got it wrong)
I'm a little confused by that paraphrased statement and yours.. mainly where the first and second generation of authentication policy (SPF and ADSP) [not calling it legacy ;) ] are being used in contexts that seem incompatible with this proposal. Is there any validity to this confusion or is your statement and the one regarding transactional email true? The following blurb relates for me wanting to use DMARC in a non transactional setting. It could be for reporting of my user domain. When I send messages to a receiver that uses DMARC versus one that doesn't use DMARC I want to have identical mail dispositions. I'm under the impression that a different DNS configuration is needed, namely when I'm sending from a domain that has end users who send to mailing lists, alumni lists, lotus notes or exchange server DLs , Unix forwards (etc) the final disposition may change. Sent via BlackBerry from T-Mobile -----Original Message----- From: Michael Adkins <[email protected]> Sender: [email protected]: Fri, 6 Jul 2012 17:49:07 To: Alan Maitland<[email protected]>; [email protected]<[email protected]> Subject: Re: [dmarc-discuss] Clarification needed; Does p=none override -all and ADSP in all cases? 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)
