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
