On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
Issue 135 is open for the subject topic. Please add your thoughts to this
thread and/or to the issue in Github.
Thank you.
[...]
I think both of these should be addressed as part of this issue in Security
Considerations.
It seems to me that, to the extent we are going to address this issue, there
is agreement that Security Considerations is appropriate. Here's proposed
text:
11.X External Mail Sender Cross-Domain Forgery
Both of the email authentication methods which underlie DMARC fundamentally
provide some degree of assurance that an email was transmitted by an MTA which
is authorized to do so. SPF policies just 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.
When Domain Owners authorize mail to be sent by sources outside their
Administrative Management Domain there is a risk that an overly permissive
source may send mail which will, as a result, receive a DMARC pass result that
was not, in fact, authorized by the Domain Owner. These false positives may
lead to issues with systems that make use of 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 overly permissive
sources can successfully DKIM sign the domain's mail or transmit mail which
will evaluate as SPF pass. If there are non-DMARC reasons for a domain owner
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.
That text is too long and lacks an example.
The first paragraph can be omitted without losing context. BTW, Section 11.4
of RFC 7208 is about /cross-user/ forgery, not cross-domain.
The second paragraph doesn't mention SPF. Couldn't it be more direct? For
example:
Domain Owners who set up SPF records which include sources outside their
Administrative Management Domain run the risk that an overly permissive
source may allow its users to send scam mail which will receive a DMARC
pass results that were not intended by the Domain Owner. These false
positives [...]
The third paragraph is also longer than needed. There's no need to mention
DKIM if we're talking SPF forgery. I'd also point out that the neutral
qualifier prevents quick rejection of the message, and is probably useless for
those who have ~all. (Are there MTAs who distinguish between neutral and
softfail? Are we prompting them to do so?) Perhaps mention that this is a
compromise between striking the SPF record tout-court and allowing false positives.
Most important, write "?include:example.com". An example is worth a thousand
words.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
