On September 17, 2021 12:09:51 PM UTC, Alessandro Vesely <ves...@tana.it> 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
