On Monday, September 20, 2021 2:15:58 PM EDT Alessandro Vesely wrote: > 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.
That's not specified in RFC 7489, so it's an assumption that this is how the world works. At best it's undefined and I don't think we can engineer interoperability based on assumptions about how current implementations address undefined behavior. Also, in my experience anyway, mailing lists aren't a significant source of problematic spam and so I don't think doing things to solve what is mostly already a non-problem is really needed. Let's not do this. Scott K > > 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
