On March 18, 2024 1:36:29 AM UTC, John Levine <jo...@taugh.com> wrote:
>Tightened up a little, reworded in view of the fact that your own
>mail provider (M*r*s*ft) may let people spoof you through shared IP ranges.
>
>
>>11.X  External Mail Sender Cross-Domain Forgery
>
>Add this to 11.1 Authentication Methods
>
I agree about this.

>Both of the email authentication methods that underlie DMARC provide
>some assurance that an email was transmitted by an MTA which is
>authorized to do so. SPF policies map domain names to sets of
>authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM
>signatures indicate that an email was transmitted by an MTA with
>access to a private key that matches the published DKIM key record.
>
>Whenever mail is sent, there is a risk that an overly permissive source
>may send mail which will receive a DMARC pass result that was not, in
>fact, authorized by the Domain Owner. These false positives may lead
>to issues when systems interpret DMARC pass results to indicate
>a message is in some way authentic. They also allow such unauthorized
>senders to evade the Domain Owner's requested message handling for
>authentication failures.
>
>The only method to avoid this risk is to ensure that no unauthorized
>source can add DKIM signatures to the domain's mail or transmit mail
>which will evaluate as SPF pass. If nonetheless domain owner wishes to
>include a permissive source in a domain's SPF record, the source can
>be excluded from DMARC consideration by using the '?' qualifier on the
>SPF record mechanism associated with that source.

I'm fine with this.

Thanks,

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to