On Fri 17/Sep/2021 15:42:12 +0200 Scott Kitterman wrote:
On September 17, 2021 1:15:40 PM UTC, Benny Lyne Amorsen
<[email protected]> wrote:
Scott Kitterman <[email protected]> writes:
How do you define "First Hop" without enabling spoofers to trivially
bypass DMARC checks by forging more than one hop of headers?
It wouldn't matter. Sensible mailing lists would reject non-first-hop
mails for domains with p=validate. Spoofers can still spoof directly,
but they cannot use mailing lists to spread their spoofed mails.
Indeed, it might be better to specify that the policy is intended for MLMs and
similar mediators. They usually happen to be the first external hop, which
helps authentication but is not the key.
This is a marked upgrade from p=none which most domains are forced to
use at the moment.
Yes. Although authentication results take part in most local filtering
recipes, this policy provides for clear, protocol level behavior.
Then as infrastructure improves, recipients will start to reject
incoming non-first-hop mail with p=validate if it does not have a valid
ARC header.
ARC has different problems.
If the point is that intermediaries that expect to be the first hop should
reject failures for p=None, they can already do that by rejecting on SPF fail.
spf=pass does not imply first hop. Actually MLM mail often passes SPF check.
No need to add complexity to DMARC to get there.
The added complexity is really minimal. I agree that this proposal may
conflict with the need to simplify DMARC.
If there's consensus that adding something like this to DMARC as an
intermediate step for intermediaries only would be useful, then I think there
are multiple issues. One, which is resolvable, is that validate isn't the
right name.
I had thought p=mlm-validate, then I simplified it. Do you have better names?
I think getting the naming and semantics right would be critical.
Indeed.
I don't think this can get past backwards compatibility problems though. The p
tag is a mandatory part of the record and any new value will be seen as invalid
by all existing DMARC implementations, so you'd have to bump the version.
I don't think we need a different version to say something so trivial as:
Unrecognized values must be ignored.
That point is missing in the DKIM spec. RFC 7489 just says:
DMARC records follow the extensible "tag-value" syntax for DNS-based
key records defined in DKIM [DKIM].
But RFC 7376 only says:
Unrecognized *tags* MUST be ignored.
It doesn't say that unrecognized values, in general, must be ignored. It says
so for individual tag values, such as unrecognized canonicalization algorithms,
Unrecognized query mechanisms, Unrecognized algorithms, Unrecognized key types,
and Unrecognized flags.
For the receiver behavior, to consider the record invalid would be equivalent
to p=none, which is correct. However, feedback reports tags shouldn't be
invalidated.
I don't think we want to do that.
Agreed.
Also, doing anything based on an ARC header field from anything other than a
trusted source is a recipe for failure. I've already seen cases where spoofed
email got accepted due to ARC from an untrusted source. Don't forget the
limitations of ARC.
100% agreed. While this proposal doesn't solve the MLM problem, it can
partially help a recipient to learn whether a message was DMARC aligned when it
arrived at the list, which is one of ARC's aims.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
