On Friday, July 06, 2012 09:19:35 AM Chris Lamont Mankowski wrote:
> Does ADSP proessing, weight-based huristics, and -all *always* get
> overridden.. even when a DMARC record is discovered with a p=none?
>
> Does it matter what the value of pct is?
>
> To eliminate confusion, I think the following paragraph should be
> edited to read:
>
> Section 7, Policy Enforcement Considerations
>
> [Old]
> DMARC-compliant Mail Receivers MUST disregard any mail directive
> discovered as part of an authentication mechanism (e.g., ADSP, SPF)
> where a DMARC policy is also discovered. {R7}
>
> [Revised]
> DMARC-compliant Mail Receivers MUST disregard any mail directive
> discovered as part of an authentication mechanism (e.g., ADSP, SPF)
> where a DMARC policy is also discovered EXCEPT when "p=none" and "pct="
> is missing or has any value. If the "p=" is equal to quarantine,
> reject, monitor,
> then only specified percentage of messages defined in "pct=" will have
> DMARC policy applied. (note that a missing pct= value implies 100%) {R7}
>
> Thoughts?
I confess I hadn't noticed this in the spec before. I don't think it makes
any sense. If you don't want mail rejected due to SPF fail or an ADSP
discardable result, why would you ever publish DNS records that might suggest
that?
I think it's out of scope for DMARC to try and impose these kinds of
requirements. Personally, I publish (and have for years) SPF -all records and
don't have any problems with them. I published a DMARC record to get the
associated feedback information. That by no means was meant to indicate that
I wanted receivers to deal with SPF differently on it's own.
This is particularly relevant to SPF because virtually all the 'bad' feedback
I'm getting in my DMARC reports is about email lists. In the case of email
lists, my SPF record doesn't even enter into it because mailing lists use
their own.
Receivers that don't want mail rejected due to ADSP or SPF should deal with
that in the appropriate DNS records. I think it would be appropriate for the
spec to point that out, but not to try and impose such limits on recievers.
Scott K
_______________________________________________
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)
