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)
