Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
It appears that Alessandro Vesely said: >TL;DR: p=validate: reject on fail, but only on first hop. New ticket: >https://trac.ietf.org/trac/dmarc/ticket/122 I'm with Scott and Mike. Let's not. In most cases MLMs can do strict DMARC enforcement on *incoming* mail with good results since it is rare to have a hop between the sender and the MLM that breaks DMARC. On the other end, we know what the problems are, so let's not. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
On Mon, Sep 20, 2021 at 2:32 PM Scott Kitterman wrote: > > 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 > +1 It does more than assume how current implementations address undefined behavior. It also makes assumptions about curren behavior that is somewhat known and defined but not necessarily consistent across participating entities. It assumes for example that outbound mail only does a single hop except for going through MLMs. It assumes that there aren't multiple hops on the inbound side (Think for example cloud based or hybrid security solutions where the ultimate receiver may have limited control or no control over behavior before ultimate delivery. So as Scott succinctly puts it, " Let's not do this." Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
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 wrote: > >>Scott Kitterman 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
On Fri 17/Sep/2021 15:42:12 +0200 Scott Kitterman wrote: On September 17, 2021 1:15:40 PM UTC, Benny Lyne Amorsen wrote: Scott Kitterman 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
Benny said: "At present, I DKIM sign outgoing mail, but since p=none, the recipients are unlikely to find the DKIM signatures particularly helpful." On the contrary, it helps evaluators. A well-authenticated message might be eligible for whitelisting, and will never be blocked based on sender authentication criteria. An evaluator's options are not limited by the sender's policy position. Doug Foster Details: An incoming mail stream can be broken into these phases: - In phase 1, the message source is evaluated. "Source" is any combination of identifiers that can be used to establish a reputation. In this phase, known-bad sources are blocked.A subset of known-good sources are tracked for whitelisting (bypass most or all of the content scanning), but this is only safe if the relevant identifiers are not spoofed (i.e. authenticated). Authentication for whitelisting has nothing to do with the sender's p=policy, only with the ability to authenticate. Using DKIM as well as SPF gives you greater opportunity to be in this category, if the evaluator considers your messages to need whitelisting. (Note that for the evaluator, sender authentication is not limited to SPF and DMARC. A trusted source IP, or a trusted and forward-confirmed host name, can be sufficient for authentication.) - In phase 2, messages that were not whitelisted are subjected to content filtering. Messages with objectionable content are blocked. Objectionable content often indicates an objectionable source, so the content blocks are used to update the message source block rules. False positives are used to adjust content filtering rules or add to the source whitelisting rules. - In phase 3, sender authentication failures are considered, and may be determinative. Note that there at this point there are no known objections to the message other than the sender authentication problem. The evaluator wants to block malicious impersonation whether or not the sender has a DMARC policy. Similarly, the sender does not want to block desired messages, and there are many reasons why a critically-important message can fail sender authentication. A sender authentication failure becomes an opportunity to review. A review could lead to several outcomes - The message is unacceptable and the offending source needs to be blocked. A sender block rule is created in phase 1. - The message is acceptable but does not require whitelisting. A sender authentication exception is created for this identifier set. for use in phase 3. Content filter rules may also be added in phase 2. - Since the message passed content filtering, an acceptable message with sender authentication failure is unlikely to identify the need for a new whitelisting rule, but anything is possible. When the volume of unathenticated messages becomes overwhelming, evaluators are more likely to apply automatic (stupid) rules. So it is in everyone's interest to minimize the volume of unauthenticated messages. On Fri, Sep 17, 2021 at 12:23 PM Benny Lyne Amorsen wrote: > Scott Kitterman writes: > > > 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. > > I am not particularly worried about spoofing of domains under my > control. They are at p=none and cannot change to quarantine or reject > due to the mailing list issue. > > In the past, the stance of DMARC has been clear, saying that use cases > like mine cannot be handled by DMARC policies and therefore p=none is > the only option. p=validate offers me a chance to get on board, at least > some of the way. > > At present, I DKIM sign outgoing mail, but since p=none, the recipients > are unlikely to find the DKIM signatures particularly > helpful. > > > /Benny > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
Scott Kitterman writes: > 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. I am not particularly worried about spoofing of domains under my control. They are at p=none and cannot change to quarantine or reject due to the mailing list issue. In the past, the stance of DMARC has been clear, saying that use cases like mine cannot be handled by DMARC policies and therefore p=none is the only option. p=validate offers me a chance to get on board, at least some of the way. At present, I DKIM sign outgoing mail, but since p=none, the recipients are unlikely to find the DKIM signatures particularly helpful. /Benny ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
On September 17, 2021 1:15:40 PM UTC, Benny Lyne Amorsen wrote: >Scott Kitterman 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. > >This is a marked upgrade from p=none which most domains are forced to >use at the moment. > >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. 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. No need to add complexity to DMARC to get there. 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 think getting the naming and semantics right would be critical. 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 want to do that. 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. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
Scott Kitterman 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. This is a marked upgrade from p=none which most domains are forced to use at the moment. 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. /Benny ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
On September 17, 2021 12:09:51 PM UTC, Alessandro Vesely wrote: >TL;DR: p=validate: reject on fail, but only on first hop. New ticket: >https://trac.ietf.org/trac/dmarc/ticket/122 > > >It appears that John Levine via Arc wrote: >(Yes, it appears, because I cannot be sure --see below) >> >> One time I asked one of the authors of ARC why they don't just >> whitelist mail from known mailing lists. They said the problem is that >> lists do lousy spam filtering, and legit lists leak bursts of spam all >> the time. For example, spammer steals someone's address book and >> starts sending spam to a mailing list with a From: that happens to be >> a subscriber. Most lists only check the From: address and let the spam >> through. ARC lets the final recipient peek back and see whether a >> message was DMARC aligned when it arrived at the list. Real mail from >> the sender would be, the spam wouldn't. > > >Without taking anything away from ARC, since IETF's MLM does check DKIM >signatures, why does it let fake senders through? The answer is, because >John's domain has p=none. Many domains have p=none. Some do so exactly >because of mailing lists. Meanwhile, several mailing lists are adopting the >practice of rewriting From:. > >Now, if my server checked ARC signatures, and if it was configured to trust >IETF's MLM, and if a...@ietf.org produced ARC headers, and if my mail client >recognized ARC authentication, then I'd be sure it was really John who wrote >the text quoted above. Quite some if's, eh? > >Alternatively, although my mail client displays DKIM authentications, I have >to look for non-automatically trusted Authentication-Results: in the header in >order to check the text was John's. > >However, if I knew IETF's MLM rejected fake senders, I wouldn't have to >recourse to search the header. Knowing that the IETF rejected DMARC failure >would be enough. > >Indeed, most of the times DKIM signatures are valid. On first hops, there's >the additional opportunity of SPF. Still, there are a number of failures. I >see stuff such as: > > Old-Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail > (2048-bit key) > reason="fail (message has been altered)" > header.d=iecc.com > header.b=1w7rvJSu; dkim=fail (2048-bit key) > reason="fail (message has been altered)" header.d=taugh.com > header.b=Kc7/HE9z > > Old-Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail > (1152-bit key) > reason="fail (message has been altered)" > header.d=tana.it > >These seem to be signing errors. If we had p=validate they'd have bounced >back and we'd have had to resend them, possibly investigating why they failed. > Too much annoyance? Dunno. Since 2016 I only found 11 messages from me to >IETF lists which failed to validate at the first hop. So those bounces would >be bearable, and they would help debugging the signing filter. So, I'd set >p=validate if it were available. Would you? How do you define "First Hop" without enabling spoofers to trivially bypass DMARC checks by forging more than one hop of headers? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Proposing p=validate, another DMARC improvement to better support indirect mail flows
TL;DR: p=validate: reject on fail, but only on first hop. New ticket: https://trac.ietf.org/trac/dmarc/ticket/122 It appears that John Levine via Arc wrote: (Yes, it appears, because I cannot be sure --see below) One time I asked one of the authors of ARC why they don't just whitelist mail from known mailing lists. They said the problem is that lists do lousy spam filtering, and legit lists leak bursts of spam all the time. For example, spammer steals someone's address book and starts sending spam to a mailing list with a From: that happens to be a subscriber. Most lists only check the From: address and let the spam through. ARC lets the final recipient peek back and see whether a message was DMARC aligned when it arrived at the list. Real mail from the sender would be, the spam wouldn't. Without taking anything away from ARC, since IETF's MLM does check DKIM signatures, why does it let fake senders through? The answer is, because John's domain has p=none. Many domains have p=none. Some do so exactly because of mailing lists. Meanwhile, several mailing lists are adopting the practice of rewriting From:. Now, if my server checked ARC signatures, and if it was configured to trust IETF's MLM, and if a...@ietf.org produced ARC headers, and if my mail client recognized ARC authentication, then I'd be sure it was really John who wrote the text quoted above. Quite some if's, eh? Alternatively, although my mail client displays DKIM authentications, I have to look for non-automatically trusted Authentication-Results: in the header in order to check the text was John's. However, if I knew IETF's MLM rejected fake senders, I wouldn't have to recourse to search the header. Knowing that the IETF rejected DMARC failure would be enough. Indeed, most of the times DKIM signatures are valid. On first hops, there's the additional opportunity of SPF. Still, there are a number of failures. I see stuff such as: Old-Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=1w7rvJSu; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=Kc7/HE9z Old-Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1152-bit key) reason="fail (message has been altered)" header.d=tana.it These seem to be signing errors. If we had p=validate they'd have bounced back and we'd have had to resend them, possibly investigating why they failed. Too much annoyance? Dunno. Since 2016 I only found 11 messages from me to IETF lists which failed to validate at the first hop. So those bounces would be bearable, and they would help debugging the signing filter. So, I'd set p=validate if it were available. Would you? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
