Re: [dmarc-ietf] ARC questions

Brandon Long <> Wed, 25 November 2020 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE8A03A0CD0 for <>; Tue, 24 Nov 2020 16:57:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nqgu1unK8zdd for <>; Tue, 24 Nov 2020 16:57:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B75A63A0CD3 for <>; Tue, 24 Nov 2020 16:57:01 -0800 (PST)
Received: by with SMTP id f18so460119ljg.9 for <>; Tue, 24 Nov 2020 16:57:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ml2sI0nZhR/PZEQuWY9Z79m1GQ/kFkbfbEE0wqCr59k=; b=Mhm1m8SVOZVMS+T6Q4bmW9dh+i9GTosv9x/BDPeZsVgicgwXGYRrjIY8XKvT8DrBQM ruJlU/A+iTQS0S66L+H6jQu1eW+GFs7/ngFH49b7fkoFwOCXpAxx30m8fP8FCxvnLLjM ltjX4FdB7uqICSEVlpMNtxNkywc9/caUuF2WZK2UZR1gz8qFLv8UI75P3JLJ/P9HNV1H RYXecUdGM1airvAlkRAZ6tbNEwLN2h0n533O+jbk0mrj+lvYmAGe7aD7RdCT7UC2H9a3 wzuwjV/9D+IU9srTlbbEOi1Z9FEk0UqoYS2mFgvCbUVANZ6bKsRreghhncg+Pk8swR1v uHrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ml2sI0nZhR/PZEQuWY9Z79m1GQ/kFkbfbEE0wqCr59k=; b=HRS875L3U+j0x4FRbW1qjDXtcTJWWtlLgNFj2enJLGdd/QfOgjwFtb2eyKQhJaxaIK zmaEfm8uBMZ0ivj88rC9j268NWkgq8Hi8rWJjZE/Nl1yyC616qHusV4g+umrDFwi8mOp zoVQi7SP7EoHK5tpMjDD+DX0/u+qmkukZuT3ZJA8h9tUcTxznyYiGwGyInTxas2ZSP9p qn0iNo/KU//wwr/hCr98lyvK9AAVuoheKrNURohhXkgH/uISBqM+7VX+5o5Hiy6VkP0M IQWdbn4Y8z//FncjAgqxcKY3x7XZ4xrrh8efLz1fQ3YuxReZrmi8xNl6ZqXH89gahm2t hJKg==
X-Gm-Message-State: AOAM531V1/xWlQUSO12QCgXs6JDs8oTeYqTvKUJCBE74b1iULfcVcWtE bwoeiQsoIK4tPWNhXLHBgZkm7T4FYAX60dfFow06Pt4Vnw==
X-Google-Smtp-Source: ABdhPJxCDPGjDaIgjdXIPyJ85PJz9pO/yskz2JF9UuZ6XXwpZpHYSkWErSroMInCpK3eLK70JA72RErIf06jFfys2+g=
X-Received: by 2002:a2e:bc1e:: with SMTP id b30mr340626ljf.241.1606265819360; Tue, 24 Nov 2020 16:56:59 -0800 (PST)
MIME-Version: 1.0
References: <20201124020453.AFDC027CE5C8@ary.qy> <> <> <>
In-Reply-To: <>
From: Brandon Long <>
Date: Tue, 24 Nov 2020 16:56:46 -0800
Message-ID: <>
To: Michael Thomas <>
Cc: John Levine <>, IETF DMARC WG <>
Content-Type: multipart/alternative; boundary="00000000000094951105b4e3e735"
Archived-At: <>
Subject: Re: [dmarc-ietf] ARC questions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Nov 2020 00:57:04 -0000

On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <> wrote:

> On 11/24/20 3:24 PM, Brandon Long wrote:
> On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas <> wrote:
>> Sorry, changing the auth-res to old-auth-res and dkim signing the
>> message would be completely sufficient, and far easier to understand
>> with a lot less bloat. All of this hand wringing about dozens of message
>> manglers in the path before it get to the destination and not be able to
>> figure out which auth-res was which seems wildly out of proportion for
>> what the normal case is: 1 message mangler in the path before it arrives
>> at the receiver's domain. Just like this message right here. That's why
>> I asked how common that was, which was dismissed, but not answered.
> Note that this was exactly what we started with,
> X-Original-Authentication-Results
> and with Google's implementation signing that with X-Google-DKIM-Signature.
> Our version didn't just sign with DKIM-Signature because of the reasons
> already stated in this
> thread, that our understanding of how DKIM-Signature was being used made
> it a poor choice.
> Sorry, I didn't see that. Pointer?
> Our experience also showed that more than one hop is quite common in
> enterprise deployments,
> and those are also the places where the most complexity arises.  Others
> shared our experience
> as well.
> That's more than one modifying intermediary in *separate* administrative
> domains? Within your own administrative domain there shouldn't be an issue
> of trust since you can trust your own servers auth-res and that they are
> not maliciously trying to forge an auth-res for better treatment. and
> course it's best to stop a bad message as soon as possible in the mail
> pipeline if for no other reason than why waste the resources.
The administrative domain in practice tends to be per-vendor and
multi-tenant.  Ie, gsuite/gmail is on, various third party
anti-spam gateways also different, on-premise being also separate.  Passing
that trust between domains is one of the things that ARC can handle.

O365 does a better job than Gmail at this, since there you can set up third
parties to be called from within a particular customer more specifically
(like an API), you can do this with GSuite or ad-hoc MTAs, but it tends to
be more manual by chaining MTAs and there isn't as much of an auth
mechanism to use.

As for stopping bad messages early, there tends to be strong majority in
favor of that for malware, less so for spam where people want access from
their mailboxes to false positives.  Some products do have separate
administrative quarantine areas that can be checked by admins, but that's
also an extra burden for IT... some of which want that burden, and some
definitely don't.  Some quarantines can be self-administered by users, but
that's obviously a separate thing they have to check, whether that's worse
than a spam folder, *shrug*.

> You say that your message had 1 mangler in the path, but really you don't
> know that.  It is
> likely that some people on this list are on enterprise accounts who are
> behind mangling inbound
> gateways (rewriting urls to go through safety checking hops is common, for
> example).  Or maybe
> they are on with University accounts using exchange but forward their mail
> to a personal or department
> gmail account.
> Well sure, I'm sure it can happen but is it common enough to worry about?
> And I'm still not convinced that figuring out who signed what and which
> auth-res it belonged to is in insurmountable problem. for one, there are
> received headers which better not be getting out of order to help correlate
> with the messages' path through intermediary verifiers too.
So, we do have some Received header walking code, and allow admins to set
up the list of IPs that are considered "internal" (beyond private
addresses)... but O365 uses public IPs internally and
has a huge and unpublished ranges of them, making it nearly impossible for
admins to maintain a list.  Obviously we can all add code to handle
Microsoft specially... and whichever other ones come up.