subject:"\[dmarc\-ietf\] ARC questions"

if you're trying to make a point about the bloat, you might actually get 
your facts straight. ARC adds an additional DKIM signature and a Seal. i 
have no idea what a X-Google-DKIM-Signature is and is not relevant.


Mike

On 12/2/20 6:55 PM, John R. Levine wrote:
PS: you're adding X-Google-DKIM-Signature which nobody knows what its 
utility is to your bloat total for dramatic effect.


Um, it was there when your message arrived here.  Complain to your 
mail provider.



On 12/2/20 6:33 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
But why bother?  The IANA header field registry currently has 419 
entries. Why is it a crisis if it increases to 422 rather than 420?


It does a lot more than that:


We've been through this all before and none of these are 
persuasive.  For

example:


3) It adds a lot more bloat to the headers


The message you just sent arrived with 4600 bytes of header (see 
below) and under 2K of text.  Copies that went through the dmarc 
mailing list probably had at least another 1K of header.


If header bloat were ever an issue, it hasn't been for decades.

R's,
John
 snip ---
Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com
X-Spam-Level: X-Spam-Status: No, score=-1.5 required=4.4 
tests=BAYES_00,DCC_REPUT_00_12,

DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE
autolearn=no autolearn_force=no version=3.4.4
Delivered-To: jo...@iecc.com
Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -
Delivered-To: virtual-taugh-jo...@taugh.com
Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -
Authentication-Results: iecc.com; spf=pass 
spf.mailfrom=m...@fresheez.com spf.helo=mail-pl1-x62a.google.com 
smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass 
header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 
header.a=rsa-sha256 header.b="vvoZ+Loe"

Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a])
  by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
  with ESMTPS via TCP6 (port 38853/25) id 665297367
  tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 
2020 23:30:06 -

Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5
    for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mtcc-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding:content-language;
    bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar
KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji
+Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3
l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S
VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS
 Y3Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
    bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu
TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap
82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa
GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS
T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz
 2CWA==
X-Gm-Message-State: 
AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD

chdQCnyR1XB3fAEw5oIqGysS4Q==
X-Google-Smtp-Source: 
ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw==
X-Received: by 2002:a17:90a:c4f:: with SMTP id 
u15mr287214pje.177.1606951804840;

    Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Return-Path: 
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. 
[107.182.42.33])
    by smtp.gmail.com with ESMTPSA id 
x7sm158495pfn.85.2020.12.02.15.30.03

    (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
    Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Subject: Re: [dmarc-ietf] ARC questions
To: John R Levine , Brandon Long 
Cc: IETF DMARC WG 
References: <20201124020453.afdc027ce...@ary.qy>
 
 
 
 
 <1eed8278-4efa-4abc-15e0-2efcf014e...@mtcc.com>
 
 <446d491b-100a-9813-6463-2294f67bb...@mtcc.com>
 
 <4190de2d-9f17-06d5-6354-30c989eec...@mtcc.com>
 <17d886fd-49fd-28d8-f8e4-7caf2e859...@taugh.com>
 
 
From: Michael Thomas 
Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b1613...@mtcc.com>
Date: Wed, 2 Dec 2020 15:30:01 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Tran

Re: [dmarc-ietf] ARC questions



On 12/2/20 6:33 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
But why bother?  The IANA header field registry currently has 419 
entries. Why is it a crisis if it increases to 422 rather than 420?


It does a lot more than that:


We've been through this all before and none of these are persuasive.  For
example:

So you just dismissed every other thing i wrote as insignificant and 
picked off one that is just calling into question why this is worth it. 
Sorry you are not persuasive. And you most certainly have not answered 
the central question of what having the previous auth-res is useful for 
in practice to add all of this heavy and untested machinery.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On Wed, 2 Dec 2020, Michael Thomas wrote:
But why bother?  The IANA header field registry currently has 419 entries. 
Why is it a crisis if it increases to 422 rather than 420?


It does a lot more than that:


We've been through this all before and none of these are persuasive.  For
example:


3) It adds a lot more bloat to the headers


The message you just sent arrived with 4600 bytes of header (see below) 
and under 2K of text.  Copies that went through the dmarc mailing list 
probably had at least another 1K of header.


If header bloat were ever an issue, it hasn't been for decades.

R's,
John
 snip ---
Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on gal.iecc.com
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 required=4.4 tests=BAYES_00,DCC_REPUT_00_12,

DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE
autolearn=no autolearn_force=no version=3.4.4
Delivered-To: jo...@iecc.com
Received: (qmail 70731 invoked by uid 1014); 2 Dec 2020 23:30:07 -
Delivered-To: virtual-taugh-jo...@taugh.com
Received: (qmail 70729 invoked from network); 2 Dec 2020 23:30:07 -
Authentication-Results: iecc.com; spf=pass spf.mailfrom=m...@fresheez.com 
spf.helo=mail-pl1-x62a.google.com smtp.remote-ip="2607:f8b0:4864:20::62a"; dkim=pass 
header.d=mtcc-com.20150623.gappssmtp.com header.s=20150623 header.a=rsa-sha256 
header.b="vvoZ+Loe"
Received: from mail-pl1-x62a.google.com ([IPV6:2607:f8b0:4864:20::62a])
  by mail1.iecc.com ([IPV6:2001:470:1f07:1126:33:5370:616d:6d31])
  with ESMTPS via TCP6 (port 38853/25) id 665297367
  tls TLS1.3_ECDHE_RSA_AES_128_GCM_AEAD sni mx1.taugh.com; 02 Dec 2020 23:30:06 
-
Received: by mail-pl1-x62a.google.com with SMTP id 4so91499plk.5
for ; Wed, 02 Dec 2020 15:30:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=mtcc-com.20150623.gappssmtp.com; s=20150623;
h=subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-transfer-encoding:content-language;
bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=vvoZ+Loew2ueICysZfzHi5UwJ3jXLN5dX+kyHN3HI91ZMJWMq7cym6dw1XQ9zaHvar
 KWobHhYgPlIURrzw5+sM1lArZM0+S8zElTI9oJicfts5VpsuYtc3kGzpFO58DlGQMzji
 +Bshah0JzXltImvCLjzUhHXHOLYvfA/Hk9lwY5XD904cTcBo4UfTKvenfFv3yLyBc4k3
 l61UDIWK7HRcdixAnDYx7zJLZaO3qcbPOwkG48uqCoMDIJVhcBndL82W/JflTPy4EB9S
 VydV+ABOODKddInyT2i5+/cTXS1B66NWYHF/Auh1UqRkxB/+H5T//oXYkKWqXolceqkS
 Y3Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
 :user-agent:mime-version:in-reply-to:content-transfer-encoding
 :content-language;
bh=frJndGBg4PljdPRXFB1KqYuhqqDFqbuyeJjhznmBtNo=;
b=EiCvgdUtIHSRQXtcFgoSdo/YgcWiu1mxFOdlQ/tDw8nd2ipjfcUBNlRSW9ygClV9vu
 TBZpT6xrU/F0xLA6fq9Tt51Z4S1VSgDSOCt1Ut8+oLzyBXkDCjQ3j8rByKqPkRvivOap
 82rO+tMd5J/4SMAAPGmJ28WAq+E7J4EJknvVu1LUOEiTERnAbmT9ZK/eTEKPjQGx0msa
 GMCKzawKzSfLMvOIqaKoPUmxPyrtEnEUizEPer7/aXZ0pXrUTHQ82984GTYqSdKDoYIS
 T+59dBxbPY9KwT33oih+1slVUSLBEbzUigK3wj4yA/71KTvr76KCUEaU8cYI6/TYcszz
 2CWA==
X-Gm-Message-State: AOAM530XUwEgBdQ2e02rPshm7iyXROuyhTJeAndRJAFtQO8oX1JUEgsD
chdQCnyR1XB3fAEw5oIqGysS4Q==
X-Google-Smtp-Source: 
ABdhPJzQUtiWyUp4dVxdii6hT+h4YBukyVaoJ5846n5Di6IUaEwxKrufF/3Atxm7lejww+dr4k5xIw==
X-Received: by 2002:a17:90a:c4f:: with SMTP id u15mr287214pje.177.1606951804840;
Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Return-Path: 
Received: from mike-mac.lan (107-182-42-33.volcanocom.com. [107.182.42.33])
by smtp.gmail.com with ESMTPSA id x7sm158495pfn.85.2020.12.02.15.30.03
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Wed, 02 Dec 2020 15:30:04 -0800 (PST)
Subject: Re: [dmarc-ietf] ARC questions
To: John R Levine , Brandon Long 
Cc: IETF DMARC WG 
References: <20201124020453.afdc027ce...@ary.qy>
 
 
 
 
 <1eed8278-4efa-4abc-15e0-2efcf014e...@mtcc.com>
 
 <446d491b-100a-9813-6463-2294f67bb...@mtcc.com>
 
 <4190de2d-9f17-06d5-6354-30c989eec...@mtcc.com>
 <17d886fd-49fd-28d8-f8e4-7caf2e859...@taugh.com>
 
 
From: Michael Thomas 
Message-ID: <8bc3c7ad-2a42-3eed-524c-8c50b1613...@mtcc.com>
Date: Wed, 2 Dec 2020 15:30:01 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

Which could trivially be added as an extension to DKIM and Auth-Res negating 
the need for the Seal altogether since DKIM can directly sign the old 
(renamed) auth-res. I can understand for an experiment not wanting to touch 
dkim or auth-res, but for something standards track less is more.


I still don't get it.  I suppose the ARC group could have done something 
to register extra tags for DKIM-Signature and A-R and tried to do 
something about the fact that if a message passes through the same network 
twice, the first A-R will be deleted, and try and find and turn off all of 
the places where mailing lists helpfully delete DKIM signatures that no 
longer are valid, and what they came up with wouldn't work a whole lot 
worse than ARC does.


But why bother?  The IANA header field registry currently has 419 entries. 
Why is it a crisis if it increases to 422 rather than 420?


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 12/2/20 12:35 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
different in that respect. In fact as far as I can tell they are 
identical modulo the i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level 
N tells you whether the ARC and DKIM signatures were good at level N-1.



That's why I said "modulo the i= difference"


Well, yeah.  That i= is why we have ARC seals rather than just using a 
DKIM signature.


Remember that ARC is only useful if the last system sending the 
message to you is reasonably trustworthy, not in the sense that it 
never sends spam, but in the sense that its ARC tells the truth about 
what it saw.  That's a low bar that any mailing list should be able to 
meet.


Which could trivially be added as an extension to DKIM and Auth-Res 
negating the need for the Seal altogether since DKIM can directly sign 
the old (renamed) auth-res. I can understand for an experiment not 
wanting to touch dkim or auth-res, but for something standards track 
less is more.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On Wed, 2 Dec 2020, Michael Thomas wrote:
different in that respect. In fact as far as I can tell they are identical 
modulo the i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.



That's why I said "modulo the i= difference"


Well, yeah.  That i= is why we have ARC seals rather than just using a 
DKIM signature.


Remember that ARC is only useful if the last system sending the message to 
you is reasonably trustworthy, not in the sense that it never sends spam, 
but in the sense that its ARC tells the truth about what it saw.  That's 
a low bar that any mailing list should be able to meet.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 12/2/20 12:31 PM, John R Levine wrote:

On Wed, 2 Dec 2020, Michael Thomas wrote:
Ignoring the existing usage of DKIM, DKIM+A-R would only work for a 
single hop, and lead to some complication compared to the other DKIM 
signatures already on the message.


Wait, what? a DKIM signatures survives until it encounters an 
intermediary that alters the message in a breaking manner. 
Arc-Signatures are no different in that respect. In fact as far as I 
can tell they are identical modulo the i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.




That's why I said "modulo the i= difference"

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On Wed, 2 Dec 2020, Michael Thomas wrote:
Ignoring the existing usage of DKIM, DKIM+A-R would only work for a single 
hop, and lead to some complication compared to the other DKIM signatures 
already on the message.


Wait, what? a DKIM signatures survives until it encounters an intermediary 
that alters the message in a breaking manner. Arc-Signatures are no different 
in that respect. In fact as far as I can tell they are identical modulo the 
i= difference.


Please reread the ARC spec.  The ARC-Authentication-Results at level N 
tells you whether the ARC and DKIM signatures were good at level N-1.


R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-26 Thread John Levine

In article  you write:
>questions the wg deems needed since then. Leaving ARC in an experimental 
>state ad infinitum doesn't seem optimal. Basically: 1) was it needed at 
>all 2) did it help. 3) if it helped, how much did it help.

I agree that at some point we need to declare the experiment over and
see if it's worked, but it's way too early for that. At this point the
only widely used list software that can apply ARC seals is Sympa.
(Mailman 3 may, but most mailman users including the IETF are still
using mailman 2.)

> (1) in 
>particular is what interests me because adding two new signatures seems 
>*really* heavy handed. That would go a long way toward answering the 
>questions of whether it's should go standards track.

I don't get why a few extra signatures are a problem. Nearly all of my
mail goes out with two added DKIM signatures, one that matches the
>From domain or the list domain if it's a list, and one for my system.
It's just not a big deal.

>Our motivation at the time was one in particular: spear phishing. From 
>an enterprise situation spear phishing is scary af, and not one that 
>providers have much care about. That's what John gets wrong when he says 
>that 90% pass rate is useless: for enterprise not wanting to get spear 
>phished, a 10% false positive rate ...

Sorry, I meant 90% the other way, catching 90% of the bad stuff and
letting the other 10% through is not good enough. I agree that for
spear phishing the tolerance for false positives is likely to be
fairly high.

R's,
JOhn

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-26 Thread Michael Thomas



On 11/26/20 1:56 AM, Murray S. Kucherawy wrote:


ARC was developed over months, even before this WG started, and I 
remember all of these conversations happening involving the questions 
you're now asking.  We landed at what became ARC.  I suppose an 
appendix might've been nice enumerating everything that was considered 
and discarded, but that record doesn't really exist.


Yeah, like I said that's sort of a common failing of IETF documents in 
general. I mean, I understand at a very low level what's going on here, 
but given the document I am completely clueless of the *why* of things 
are going on. It's very frustrating, doubly so when it's a self-labeled 
experiment.





Where do you suggest we go from here?


I would think that an informational RFC might come in really handy both 
to answer the questions in ARC itself, and any other subsequent 
questions the wg deems needed since then. Leaving ARC in an experimental 
state ad infinitum doesn't seem optimal. Basically: 1) was it needed at 
all 2) did it help. 3) if it helped, how much did it help. (1) in 
particular is what interests me because adding two new signatures seems 
*really* heavy handed. That would go a long way toward answering the 
questions of whether it's should go standards track.



I haven't put hand to coding keyboard on this problem yet, but I'm 
trying to imagine how it would be easy to determine (a) that Subject 
had been modified (for example), (b) what the specific modification 
was, and (c) which hop did it.  You could say a message failing to 
validate an author signature with "[...]" at the front of Subject was 
likely tagged by an MLM, or that everything after "--" should be 
ignored, or that those probably happened at non-submission hop #1, but 
those are heuristics, and I think we're hoping for something more 
deterministic.  The 80/20 rule isn't sufficient.


But it's late and maybe I'm missing something.  What did you have in mind?


Our motivation at the time was one in particular: spear phishing. From 
an enterprise situation spear phishing is scary af, and not one that 
providers have much care about. That's what John gets wrong when he says 
that 90% pass rate is useless: for enterprise not wanting to get spear 
phished, a 10% false positive rate issuing warnings might be acceptable, 
and since we were grappling the intractable mailing list reputation (at 
least from our standpoint), maybe a better option.


But it was a combination of the l= value in the original signature to 
clip off what the mailing list added, and some heuristics on the subject 
line to remove added text. I had quite a few of them, and they were 
certainly pretty dodgy, but by and large they worked. The object was not 
to get to 100%, but just an acceptable false positive rate. At the time 
I mentioned that maybe it would be good to create a DKIM-friendly 
mailing list BCP, but that was scoffed at by the usual suspects because 
there was supposedly a massive long tail of transformations that can 
happen that nobody would quantify as to how common or important they 
were. Hence my desire of this being driven at least in part by numbers.



Sure, but the easier answer: to use my mailing list, you must have
either DKIM, SPF or both. Sounds like a good way t

o not be essentially an open relay. Don't mailing lists have those
sorts of policies these days? I would say that ones that don't
probably shouldn't have good reputations since they are, in
effect... open relays.


That requires MLMs to change their behavior, which I believe is 
something all of these protocols are hoping to avoid (or, at least, 
MLMs should decide that on their own, not because the IETF forced them 
to by wielding DMARC and ARC at them).


I don't see making mailing lists coerced into better behavior as a 
non-starter. Everybody has had to change over the years to get mail 
delivered, and mailing lists, etc, shouldn't be viewed as sacred cows. 
If they want to forward their mail, they need to play by the evolving 
rules so as to make for a less spammy and phishy world. Back when DKIM 
was the new kid on the block, that might have been a valid argument. 
Today, not so much.




PS: it's been, what, 15 years since our interop, partner? :)

2007.  Still got the t-shirt.

But we interoped the combined DK and IIM spec a couple of years earlier, 
right? What a great day that was... we dunn'em proud, Murray :)



Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-26 Thread Alessandro Vesely


On 26/11/2020 10:56, Murray S. Kucherawy wrote:

On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas  wrote:



Yeah, quantifying the problems kinda seems like the first order of
business if you ask me.



Quantifications will differ depending on what you count.  Total number of 
messages versus total number of mail operators who find ARC useful.


Small operators had better not forward spam, whether ARC sealed or not.



Software. Only software can pry apart that ball of header spaghetti. But I
think with the simple a mailing list it is pretty easy to determine, which
now that I think about it I actually did back in the day when I was
experimenting with recovering mailing list modifications. It didn't occur
to me that that was supposed to be hard.


I haven't put hand to coding keyboard on this problem yet, but I'm trying
to imagine how it would be easy to determine (a) that Subject had been
modified (for example), (b) what the specific modification was, and (c)
which hop did it.  You could say a message failing to validate an author
signature with "[...]" at the front of Subject was likely tagged by an MLM,
or that everything after "--" should be ignored, or that those probably
happened at non-submission hop #1, but those are heuristics, and I think
we're hoping for something more deterministic.  The 80/20 rule isn't
sufficient.



Again, you cannot get 100% lists.  For example, anonymizing lists will never 
let you recover an author domain's signature.  MLM has to comply.


On a compliant list like this one, you cannot get 100% users.  For example, 
those who sign a Content-Type: multipart/alternative without giving the 
original value, or a quoted-printable body that the MLM will encode differently 
will never verify.  Author domains have to comply.


On a compliant list, you can verify 99.99% compliant author domains' 
signatures.  (~0.01% due to cosmic rays and similar accidents.)



Best
Ale
--















___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-26 Thread Murray S. Kucherawy

On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas  wrote:

> But what about DKIM? And why do they need to be processed differently?
> When I first saw this, I looked at the ARC-Signature which looks identical
> to a DKIM signature (i didn't notice the i= at the time), and am like what
> is this? The i= counter could be trivially be grafted onto DKIM if it were
> needed, which I'm still sort of dubious (though it is a nice to have
> feature, I admit). That way you only need a single DKIM signature with the
> OAR's signed. As far as I can tell, that would fall back gracefully for
> non-implementing DKIM verifiers. Do you disagree?
>

ARC was developed over months, even before this WG started, and I remember
all of these conversations happening involving the questions you're now
asking.  We landed at what became ARC.  I suppose an appendix might've been
nice enumerating everything that was considered and discarded, but that
record doesn't really exist.

What that means is that I couldn't tell you now why we rejected a pure
DKIM/OAR solution to this specific problem, but I know it was considered.
Maybe others who helped with RFC 8617 remember.

>
> Yeah, quantifying the problems kinda seems like the first order of
> business if you ask me. I mean, how many of these scenarios are in reality
> goofy self-inflicted wounds? I can't say but there seems to be a lot more
> "this can happen" than "this is how often this happens" from what I've see
> thus far on this thread.
>

Where do you suggest we go from here?

>
> When you say "easy to see", do you mean for software or for humans?
>
> Software. Only software can pry apart that ball of header spaghetti. But I
> think with the simple a mailing list it is pretty easy to determine, which
> now that I think about it I actually did back in the day when I was
> experimenting with recovering mailing list modifications. It didn't occur
> to me that that was supposed to be hard.
>
I haven't put hand to coding keyboard on this problem yet, but I'm trying
to imagine how it would be easy to determine (a) that Subject had been
modified (for example), (b) what the specific modification was, and (c)
which hop did it.  You could say a message failing to validate an author
signature with "[...]" at the front of Subject was likely tagged by an MLM,
or that everything after "--" should be ignored, or that those probably
happened at non-submission hop #1, but those are heuristics, and I think
we're hoping for something more deterministic.  The 80/20 rule isn't
sufficient.

But it's late and maybe I'm missing something.  What did you have in mind?

> Sure, but the easier answer: to use my mailing list, you must have either
> DKIM, SPF or both. Sounds like a good way to not be essentially an open
> relay. Don't mailing lists have those sorts of policies these days? I would
> say that ones that don't probably shouldn't have good reputations since
> they are, in effect... open relays.
>

That requires MLMs to change their behavior, which I believe is something
all of these protocols are hoping to avoid (or, at least, MLMs should
decide that on their own, not because the IETF forced them to by wielding
DMARC and ARC at them).

> Mike
>
> PS: it's been, what, 15 years since our interop, partner? :)
>
2007.  Still got the t-shirt.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-25 Thread Michael Thomas



On 11/25/20 4:14 PM, Murray S. Kucherawy wrote:
On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas > wrote:



That's been known for over 15 years. I'm still trying to
understand the assertion that DKIM signatures are a "bad fit". I
just looked at a random message off of this thread and they look
identical except for the i= field. another field could trivially
be added to DKIM and auth-res -- since unknown fields are supposed
to be ignored -- if this binding property is absolutely needed,
which I remain unconvinced by as well.

I'm not sure about "bad fit".  The original plan was to have an 
Authentication-Results (AR) clone called 
Original-Authentication-Results (OAR) which was specifically the AR 
content generated at the first non-submission MTA. There was some 
friction (mostly from me, as I recall) about having two header fields 
with identical syntax and nearly identical semantics.  There was 
further complication in the fact that one ADMD could apply multiple 
ARs on a single message (for multiple methods, or multiple instances 
of the same method, or a combination of those), or they could be 
reordered, etc.  To make it more resilient, things like instance 
numbers were added.  The work was eventually generalized to be a 
"chain of custody" sort of model, and in doing that I think the 
decision was made to make a new name to ensure ARC and DKIM would be 
processed differently.



But what about DKIM? And why do they need to be processed differently? 
When I first saw this, I looked at the ARC-Signature which looks 
identical to a DKIM signature (i didn't notice the i= at the time), and 
am like what is this? The i= counter could be trivially be grafted onto 
DKIM if it were needed, which I'm still sort of dubious (though it is a 
nice to have feature, I admit). That way you only need a single DKIM 
signature with the OAR's signed. As far as I can tell, that would fall 
back gracefully for non-implementing DKIM verifiers. Do you disagree?





If you ask me, part of the experiment should be able to show use
cases that DKIM + auth-res (or maybe old-auth-res if needed)
CANNOT address that ARC can, and most especially what percentage
of email traffic we're actually talking here. As far as I can see
ARC doesn't bring anything especially new for the mailing list
kind of use cases since it really easy to see who the
intermediary was that broke the signature. I have been told there
are some vague other kinds of use cases but is unclear whether
those use cases actually happen before or after the message
arrives at the front door of the final receiving domain. Yes, i
read section 7, but it doesn't tell me why this can't be handled
with current technology.


Obviously it's too late to include this in RFC 8617, but those would 
indeed be interesting data to have.



Yeah, quantifying the problems kinda seems like the first order of 
business if you ask me. I mean, how many of these scenarios are in 
reality goofy self-inflicted wounds? I can't say but there seems to be a 
lot more "this can happen" than "this is how often this happens" from 
what I've see thus far on this thread.




When you say "easy to see", do you mean for software or for humans?



Software. Only software can pry apart that ball of header spaghetti. But 
I think with the simple a mailing list it is pretty easy to determine, 
which now that I think about it I actually did back in the day when I 
was experimenting with recovering mailing list modifications. It didn't 
occur to me that that was supposed to be hard.




It seems to me that the lynchpin is whether I trust the domain
that broke the signature and resigned. That's either a previously
solved or unsolved problem depending on your perspective. If I
trust the intermediary domain to not send me spam via reputation,
I forward it along to be delivered and ignore the DMARC record.
Why do I care whether it originally validated from the sending
domain or not? If you ask me, that's the intermediary domain's
problem since they have an incentive to keep their reputation and
not send spam through.

Suppose you're sending to a list that I'm on, I enforce DMARC, I trust 
that MLM not to send spam via reputation, you have a good reputation, 
and you publish a DMARC "reject" policy.  That means if a bad actor 
sends a message to the list as you but doesn't sign it at all, I'll 
still accept it because I trust that MLM even though according to your 
policy request, I should bounce it.  ARC provides the missing data I 
need to enforce your request.


Sure, but the easier answer: to use my mailing list, you must have 
either DKIM, SPF or both. Sounds like a good way to not be essentially 
an open relay. Don't mailing lists have those sorts of policies these 
days? I would say that ones that don't probably shouldn't have good 
reputations since they are, in effect...

Re: [dmarc-ietf] ARC questions

2020-11-25 Thread Murray S. Kucherawy

On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas  wrote:

> On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
>
> On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Michael, I think the purpose is stated well enough:   Mailing lists want
>> to keep adding their content to messages, without being blocked by
>> recipients.   This means that they have to provide recipients with enough
>> information for them to accept the forwarded content.   Google and
>> Microsoft seem to be on-board with this project, so it seems pretty
>> successful already.   This train is not easily stopped.
>>
>
> That sounds about right.  Put another way: DMARC's success is at least in
> part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to
> carry forward from the MLM, in a credible way, an indication of what the
> MLM saw in terms of DKIM results when the message got to the MLM.  So then,
> although an author signature will fail post-MLM, the MLM signature will
> pass, and the ARC data will tell you that the author signature was good
> when the MLM got it.  If you trust the chain, then that can be an
> alternative to the DKIM input when the final recipient performs a DMARC
> evaluation.
>
> That's been known for over 15 years. I'm still trying to understand the
> assertion that DKIM signatures are a "bad fit". I just looked at a random
> message off of this thread and they look identical except for the i= field.
> another field could trivially be added to DKIM and auth-res -- since
> unknown fields are supposed to be ignored -- if this binding property is
> absolutely needed, which I remain unconvinced by as well.
>
I'm not sure about "bad fit".  The original plan was to have an
Authentication-Results (AR) clone called Original-Authentication-Results
(OAR) which was specifically the AR content generated at the first
non-submission MTA.  There was some friction (mostly from me, as I recall)
about having two header fields with identical syntax and nearly identical
semantics.  There was further complication in the fact that one ADMD could
apply multiple ARs on a single message (for multiple methods, or multiple
instances of the same method, or a combination of those), or they could be
reordered, etc.  To make it more resilient, things like instance numbers
were added.  The work was eventually generalized to be a "chain of custody"
sort of model, and in doing that I think the decision was made to make a
new name to ensure ARC and DKIM would be processed differently.

I imagine it could've been done as an Applicability Statement over DKIM and
AR, but I'm not sure now whether that would've been simpler.

> If you ask me, part of the experiment should be able to show use cases
> that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address that
> ARC can, and most especially what percentage of email traffic we're
> actually talking here. As far as I can see ARC doesn't bring anything
> especially new for the mailing list kind of use cases since it really easy
> to see who the intermediary was that broke the signature. I have been told
> there are some vague other kinds of use cases but is unclear whether those
> use cases actually happen before or after the message arrives at the front
> door of the final receiving domain. Yes, i read section 7, but it doesn't
> tell me why this can't be handled with current technology.
>
> Obviously it's too late to include this in RFC 8617, but those would
indeed be interesting data to have.

When you say "easy to see", do you mean for software or for humans?

> It seems to me that the lynchpin is whether I trust the domain that broke
> the signature and resigned. That's either a previously solved or unsolved
> problem depending on your perspective. If I trust the intermediary domain
> to not send me spam via reputation, I forward it along to be delivered and
> ignore the DMARC record. Why do I care whether it originally validated from
> the sending domain or not? If you ask me, that's the intermediary domain's
> problem since they have an incentive to keep their reputation and not send
> spam through.
>
Suppose you're sending to a list that I'm on, I enforce DMARC, I trust that
MLM not to send spam via reputation, you have a good reputation, and you
publish a DMARC "reject" policy.  That means if a bad actor sends a message
to the list as you but doesn't sign it at all, I'll still accept it because
I trust that MLM even though according to your policy request, I should
bounce it.  ARC provides the missing data I need to enforce your request.

If the MLM enforces DMARC, that's slightly better, but I think ARC was
meant to be an incremental drop-in for MLM operators that don't (or won't)
do DMARC.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-25 Thread Michael Thomas



On 11/24/20 7:27 PM, Douglas Foster wrote:



In my opinion, ARC does leave a lot of unanswered questions about how 
you use the data that ARC provides.   Again, the big organizations 
have the brain power at their disposal to figure that out for 
themselves, later.




They've had that data for over a decade from what I can tell. The exact 
same data that ARC provides, but perhaps a little hard to tease apart in 
some edge cases.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-25 Thread Michael Thomas



On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster 
> wrote:


Michael, I think the purpose is stated well enough:   Mailing
lists want to keep adding their content to messages, without being
blocked by recipients.   This means that they have to provide
recipients with enough information for them to accept the
forwarded content.  Google and Microsoft seem to be on-board with
this project, so it seems pretty successful already.   This train
is not easily stopped.


That sounds about right.  Put another way: DMARC's success is at least 
in part stymied by what MLMs do that invalidates DKIM; ARC is an 
attempt to carry forward from the MLM, in a credible way, an 
indication of what the MLM saw in terms of DKIM results when the 
message got to the MLM.  So then, although an author signature will 
fail post-MLM, the MLM signature will pass, and the ARC data will tell 
you that the author signature was good when the MLM got it.  If you 
trust the chain, then that can be an alternative to the DKIM input 
when the final recipient performs a DMARC evaluation.


That's been known for over 15 years. I'm still trying to understand the 
assertion that DKIM signatures are a "bad fit". I just looked at a 
random message off of this thread and they look identical except for the 
i= field. another field could trivially be added to DKIM and auth-res -- 
since unknown fields are supposed to be ignored -- if this binding 
property is absolutely needed, which I remain unconvinced by as well.





Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps 
not as concretely as one might like.


In my opinion, ARC does leave a lot of unanswered questions about
how you use the data that ARC provides.   Again, the big
organizations have the brain power at their disposal to figure
that out for themselves, later.


This is why it was published as Experimental.  Its efficacy is not 
(yet) known, nor are any side effects. Although, now that you have me 
thinking about it: It's been a year; have we any meaningful data about 
this yet?


If you ask me, part of the experiment should be able to show use cases 
that DKIM + auth-res (or maybe old-auth-res if needed) CANNOT address 
that ARC can, and most especially what percentage of email traffic we're 
actually talking here. As far as I can see ARC doesn't bring anything 
especially new for the mailing list kind of use cases since it really 
easy to see who the intermediary was that broke the signature. I have 
been told there are some vague other kinds of use cases but is unclear 
whether those use cases actually happen before or after the message 
arrives at the front door of the final receiving domain. Yes, i read 
section 7, but it doesn't tell me why this can't be handled with current 
technology.


It seems to me that the lynchpin is whether I trust the domain that 
broke the signature and resigned. That's either a previously solved or 
unsolved problem depending on your perspective. If I trust the 
intermediary domain to not send me spam via reputation, I forward it 
along to be delivered and ignore the DMARC record. Why do I care whether 
it originally validated from the sending domain or not? If you ask me, 
that's the intermediary domain's problem since they have an incentive to 
keep their reputation and not send spam through.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-24 Thread Murray S. Kucherawy

On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Michael, I think the purpose is stated well enough:   Mailing lists want
> to keep adding their content to messages, without being blocked by
> recipients.   This means that they have to provide recipients with enough
> information for them to accept the forwarded content.   Google and
> Microsoft seem to be on-board with this project, so it seems pretty
> successful already.   This train is not easily stopped.
>

That sounds about right.  Put another way: DMARC's success is at least in
part stymied by what MLMs do that invalidates DKIM; ARC is an attempt to
carry forward from the MLM, in a credible way, an indication of what the
MLM saw in terms of DKIM results when the message got to the MLM.  So then,
although an author signature will fail post-MLM, the MLM signature will
pass, and the ARC data will tell you that the author signature was good
when the MLM got it.  If you trust the chain, then that can be an
alternative to the DKIM input when the final recipient performs a DMARC
evaluation.

Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps not as
concretely as one might like.

In my opinion, ARC does leave a lot of unanswered questions about how you
> use the data that ARC provides.   Again, the big organizations have the
> brain power at their disposal to figure that out for themselves, later.
>

This is why it was published as Experimental.  Its efficacy is not (yet)
known, nor are any side effects.  Although, now that you have me thinking
about it: It's been a year; have we any meaningful data about this yet?

It seems like a lot of software logic to create an ARC set, even more code
> to parse it, and even more code to use it intelligently.   This is a big
> problem if you are trying to write the code yourself, but a small problem
> if you have a big programming organization.
>

When I implemented it, there was a great deal of processing logic that was
recycled from DKIM.  That was advantageous.  But I agree, someone
implementing ARC with no context at all could easily find it a challenge to
get it to interoperate.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-24 Thread Douglas Foster

Michael, I think the purpose is stated well enough:   Mailing lists want to
keep adding their content to messages, without being blocked by
recipients.   This means that they have to provide recipients with enough
information for them to accept the forwarded content.   Google and
Microsoft seem to be on-board with this project, so it seems pretty
successful already.   This train is not easily stopped.

As to the technical pieces:
- Unvalidated data, which includes the entire Received header chain, is
only useful for blacklisting.   A spammer will fabricate any header content
that he thinks will get his garbage through your spam filter.

- The recipient filter needs to be convinced that the submitting MTA is not
lying and that the submitting MTA has not been duped.   Digital signatures
are the only tool we have for validating forwarded content.   Since the
goal is favorable treatment, digital signatures are necessary.

- Interlocking signatures are needed to get around the problem of DKIM
signatures being damaged by mid-stream content changes.

As John said early on, this all works in conjunction with private knowledge
that decides who you believe is not lying.   Google and Microsoft have that
kind of data.

In my opinion, ARC does leave a lot of unanswered questions about how you
use the data that ARC provides.   Again, the big organizations have the
brain power at their disposal to figure that out for themselves, later.

It seems like a lot of software logic to create an ARC set, even more code
to parse it, and even more code to use it intelligently.   This is a big
problem if you are trying to write the code yourself, but a small problem
if you have a big programming organization.

The email market is moving to a few large organizations that provide
hosting for most everyone, a few other large cloud services that provide
filtering for much of the remainder, and then everybody else.   Smaller
organizations are stuck with lousy vendor options or custom development,
neither of which is entirely satisfactory.   ARC may not be the right
solution for smaller organizations with fewer development resources, but
80% of the world needs the big organizations to be successful, and the
mailing lists need the big organizations to be accepting of their product.
 ARC seems to meet those important goals.

Doug Foster

On Tue, Nov 24, 2020 at 6: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.
>
>
>
> 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.
>
> Mike
>
>

Re: [dmarc-ietf] ARC questions

2020-11-24 Thread John R Levine


On Tue, 24 Nov 2020, Michael Thomas wrote:
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?


Microsoft currently appears to add an ARC seal for everything that
transits their hosted mail system, no mailing lists or whatever
involved. I think I may have seen stuff from them with two seals.

Here's the headers of something from MS that I picked out of the
spamtrap. It's a fake Sharepoint message, and all of the SPF and DMARC
checks failed, which of course makes one wonder why they sent it to me
at all, but there's plenty of ARC-age there in case I want to do the
filtering they didn't.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


Return-Path: 
Received: (qmail 53861 invoked from network); 24 Nov 2020 23:04:40 -
Authentication-Results: iecc.com; spf=pass spf.mailfrom=no-re...@sharepointonline.com 
spf.helo=APC01-SG2-obe.outbound.protection.outlook.com smtp.remote-ip="40.107.131.117"; dkim=pass 
header.d=spoapaceop.onmicrosoft.com header.s=selector1-spoapaceop-onmicrosoft-com header.a=rsa-sha256 
header.b="wrH3TGY5"; dkim=pass header.d=sharepointonline.com header.s=selector1 header.a=rsa-sha256 
header.b="nk5sNj5U"; dmarc=pass header.from=sharepointonline.com (p=reject, pct=100)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 
b=O1UbAqs382laXh6I4AhWTigOPfRFerozKTibyzMawpdnyHHn4iHRW4u6+HZ1KlqNZHfhco5U9KgrgsCzP1VvHaD686U2omsloPRlsuR8+8UQPucSS/qtgYrv+5vDfF8cNqvnyfRvS/kOy3bAzr4vVPfhtgPbQ2sn+L5wMjo+w8kV+AZ6O6KedBqZSrX6Mt6OpsqFT1l3sTybAuOHlrmjo++cp2Dn0atKYnqDAAu1OIOSW6/dnc0u6fwbVoURavwPtWVhnK2/1MjHnlJO6XZTQeQtvvU82RSaaEikGgrQhsAO41Uz2HJPMt3S6e4RAWYS1n995BOeosRNjLcKxFNx2A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=;
 
b=WpRrZ43L7klrMFI7e2Xg+LjrKHEocOU52J2YWHSirU4EX4J1yqrqMWT1MqGQze8tEbPEtTSa8r2ZM6ff235Mch1QlpbmQt2HtmGClJGe+ZYkRTf5zTmGyLxSokIrNfFaAHtztaqnct0XlLgMCm3Uu5zxqzaIfh9Wi2vMlLpX/mHRx+W6XOw1+Frb1msMbyf4LbjtjFWCv1+KBpACSaxC9vWIc70+P7stlVkuGyxM9rE+oO7jodaUCAHvkBQtASZ+PVeGe/gxxP3Pv26WnM31HDxVKGkn6mVsCkhkqW6L/4O2/SBCjtyM0gUoatMprsAOTian7sDbnQYtzTzTP2f0wA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender ip is
 13.75.93.237) smtp.rcpttodomain=repmark.com
 smtp.mailfrom=sharepointonline.com; dmarc=fail (p=reject sp=reject pct=100)
 action=oreject header.from=sharepointonline.com; dkim=none (message not
 signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=spoapaceop.onmicrosoft.com; s=selector1-spoapaceop-onmicrosoft-com;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=;
 
b=wrH3TGY50Qitk5Kc82kUaGKKbBcgore8XTTR+QrqeSmGIEyalPhCQ+HoQXN6Euuhzc0EM9GOEYvMk2I5wYiZZ9eihJ4UuBARo1EHK7zYDlda2EAql0V+/5oWR0jHFvYBmH+QUCQ5SJ+R2IxO5x9yK0fXUJtpTPmZgYpvwH+AIA4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharepointonline.com;
 s=selector1;
 
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=OYiUO2h5rcN3yi5Rpfr3/080+M/p/ca47NawA9FGJAw=;
 
b=nk5sNj5UH1ZrUT387iGCYgiYCAZspugCdueY19ZRfrz+hs1F/ltpSFIUvvB/PZ8QRP1H4qGujpRuLnD3PlNLPn1Qak0pFp13mwip2g5eV8ObJxBw1d11zLM7PM090Z6Ri2NrKK241iAgmOl5gZrcrLgur7F2ckhtMYJsSkCKiUEDOfHSns3JN/AHVXm7C46BOMrQbJbhWqwTojkasOgVEGnAZbEcUbVT13mAmKvB1t7BL3wCk56q37jYm09vuSzvhja3+oegQ/iaLsurvCDzJkW2WvmRt2+Y+LYaG4HYboUQ7W/P6pDJCPpMDZzHp9aRwrHGamKgpdi/0lrXwz9G4w==
X-MS-Exchange-Authentication-Results: spf=fail (sender IP is 13.75.93.237)
 smtp.mailfrom=sharepointonline.com; repmark.com; dkim=none (message not
 signed) header.d=none;repmark.com; dmarc=fail action=oreject
 header.from=sharepointonline.com;
Date: Tue, 24 Nov 2020 23:04:25 +
Subject: Ashley Barker shared "I'M 28 Years Horny & Sexy" with you.
Message-Id: 

Sender: Ashley Barker 
To: jamaicadiscountvacationpacka...@repmark.com,
 wevmas...@marshfieldtravel.com, tcw...@hiwaay.net, rrbr...@ptdprolog.net,
 memb...@onlinecityguide.com, david_burnst...@lecg.com, aimee_sm...@dell.com,
 mtu...@tivoli.com, bassm...@earthlink.net, alfac...@nectar.com, ti...@gcm.com,
 tm...@ais.net, tam...@tamarasmith.com, uu-req...@iecc.com, n...@net.com,
 tra...@worldaccess.com, randiha...@yahoo.com, jc_sm...@dell.com,
 ksteph...@supnet.com, tamerasm...@sprintmail.com, sa...@sovam.com,
 temp...@storm.net, smit...@hotmail.com, smit...@hotmail.com,
 ssmith...@docsolinc.com, mistersm...@free-online.co.uk,
 brettatay...@comcast.net, wbatter...@steptoe.com, jlup-lupini...@gmx.com,

Re: [dmarc-ietf] ARC questions



On 11/24/20 4:56 PM, Brandon Long wrote:



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




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 google.com , 
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.


One of the failings of many, many ietf documents is to not tell the 
story of what exactly the problem is and why the protocol is needed. 
It's really frustrating to the reader to not have the context of endless 
wg list discussions distilled so that an outsider can understand the 
design tradeoffs. I still don't understand why a DKIM signature was a 
"poor choice". That's especially true when something is an experiment 
that assumedly has yes/no endpoint.


So mtcc.com is now hosted by gsuite (::sigh::), so you're saying that it 
would run into problems? I haven't put up a DMARC policy, but if I did I 
might run into issues with false positives? Like I said, I'm trying to 
get my head around what the actual problems are, and this is coming from 
a person who stressed mightily from the very beginning about the mailing 
list problem.





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.




But can't you trust the received headers once you have possession of the 
message within your domain? I'm sorry if I'm being dense here but 
received headers are definitely ordered and if you loan out a message to 
be processed by a different domain and they aren't trustworthy, that's 
the least of your problems. That's part of the overall problem though: 
it's really hard to understand what the problem here actually is. 
Explain it like I'm five :)


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-24 Thread Brandon Long

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 google.com, 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.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



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.





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.


Mike


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-24 Thread Seth Blank

As Chair-

This thread is quickly becoming unproductive and veering to personal
attacks, which will not be tolerated.

Please engage productively and on the merits, take the conversation
elsewhere, or disengage.

Seth

On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas  wrote:

> You'd be wrong. The only ad hominem was yours from yesterday and it was
> I think where *you* dismissed the very question I raised:
>
> "Two or more levels of forward are quite common, particularly in large
> mail systems.  Look at mail coming out of Google and Microsoft's hosted
> mail and you'll see a lot of ARC headers.
>
> Considering that the ARC RFC was published over a year ago, and it is
> implemented all over the place, could you explain what the point of this
> discussion is?  The people who designed ARC are not idiots.  If we could
> have fixed the mailing list problem with existing DKIM signatures, we
> would have."
>
> And as I've said repeatedly, do not contact me in private.
>
> Mike
>
> On 11/24/20 2:53 PM, John R Levine wrote:
> > This appears to me to be an ad-hominem attack on the people who
> > designed ARC, so I think we're done.
> >
> > On Tue, 24 Nov 2020, Michael Thomas wrote:
> >
> >>
> >> On 11/23/20 6:04 PM, John Levine wrote:
> >>> In article  you write:
>  What I'm struggling to understand is what having authenticated
>  auth-res
> >>> >from a previous hop helps. this is what i found:
> >>>
> >>> See some of the previous messages. My usual example is a mailing list
> >>> message that fails DMARC at the final recipient but passed DMARC (as
> >>> recorded in AAR) when it arrived at the list. This lets the final
> >>> recipient distinguish between real messages from subscribers and mail
> >>> from spambots that happened to scrape both the list address and some
> >>> subscribers' address and sends mail to one pretending to be from the
> >>> other. (That definitely happens, I've seen it on lists I'm on.)
> >>>
> >>> I agree that the ARC document does not do a great job of explaining
> >>> that.
> >>>
>  It would be kind of nice to understand what gap ARC actually plugs and
>  why it's important if you ask me. Also: there seem to be a lot of ways
>  to achieve this, but this one is probably the most complicated one
>  that
>  I can envision.
> >>> If you want to pass the A-R results through multiple rounds of
> >>> forwarding, you can't do much less.
> >>
> >>
> >> 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.
> >>
> >> Mike
> >>
> >>
> >
> > Regards,
> > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail.
> https://jl.ly
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*p:* 415.273.8818


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

You'd be wrong. The only ad hominem was yours from yesterday and it was 
I think where *you* dismissed the very question I raised:


"Two or more levels of forward are quite common, particularly in large 
mail systems.  Look at mail coming out of Google and Microsoft's hosted 
mail and you'll see a lot of ARC headers.


Considering that the ARC RFC was published over a year ago, and it is 
implemented all over the place, could you explain what the point of this 
discussion is?  The people who designed ARC are not idiots.  If we could 
have fixed the mailing list problem with existing DKIM signatures, we 
would have."


And as I've said repeatedly, do not contact me in private.

Mike

On 11/24/20 2:53 PM, John R Levine wrote:
This appears to me to be an ad-hominem attack on the people who 
designed ARC, so I think we're done.


On Tue, 24 Nov 2020, Michael Thomas wrote:



On 11/23/20 6:04 PM, John Levine wrote:

In article  you write:
What I'm struggling to understand is what having authenticated 
auth-res

>from a previous hop helps. this is what i found:

See some of the previous messages. My usual example is a mailing list
message that fails DMARC at the final recipient but passed DMARC (as
recorded in AAR) when it arrived at the list. This lets the final
recipient distinguish between real messages from subscribers and mail
from spambots that happened to scrape both the list address and some
subscribers' address and sends mail to one pretending to be from the
other. (That definitely happens, I've seen it on lists I'm on.)

I agree that the ARC document does not do a great job of explaining 
that.



It would be kind of nice to understand what gap ARC actually plugs and
why it's important if you ask me. Also: there seem to be a lot of ways
to achieve this, but this one is probably the most complicated one 
that

I can envision.

If you want to pass the A-R results through multiple rounds of
forwarding, you can't do much less.



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.


Mike




Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions




On 11/23/20 6:04 PM, John Levine wrote:

In article  you write:

What I'm struggling to understand is what having authenticated auth-res

>from a previous hop helps. this is what i found:

See some of the previous messages. My usual example is a mailing list
message that fails DMARC at the final recipient but passed DMARC (as
recorded in AAR) when it arrived at the list. This lets the final
recipient distinguish between real messages from subscribers and mail
from spambots that happened to scrape both the list address and some
subscribers' address and sends mail to one pretending to be from the
other. (That definitely happens, I've seen it on lists I'm on.)

I agree that the ARC document does not do a great job of explaining that.


It would be kind of nice to understand what gap ARC actually plugs and
why it's important if you ask me. Also: there seem to be a lot of ways
to achieve this, but this one is probably the most complicated one that
I can envision.

If you want to pass the A-R results through multiple rounds of
forwarding, you can't do much less.



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.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 4:13 PM, Brandon Long wrote:



On Mon, Nov 23, 2020 at 12:48 PM Dave Crocker > wrote:


On 11/23/2020 12:15 PM, Brandon Long wrote:

On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker mailto:dcroc...@gmail.com>> wrote:
DKIM often ties a domain to reputation and other anti-spam
features.  If you
forward spam to another host and sign it while forwarding, then
the other host
will think you send spam.


Well, ummm... e... yes.  That's because, in such
circumstances, you do.

More significantly, the signature makes sure that such as an
assessment will only be made accurately, rather than penalizing
you for problematic mail that is attributed to you but that you
did not handle.

If the result is marking all of the mail from that mailing list as 
spam, then you've likely done your users a disservice.


Why would you put forward a hypothetical that might reasonably be 
characterized as unreasonable, especially given that you also make clear 
why it is unreasonable? (*)



Being able to differentiate is useful.  Also, forwarders often don't 
have all of
the signals that the user's mailbox does.. not the least of which is 
that different recipients have different judgements on what is spam, 
and the "this is spam" signal rarely makes it back to the forwarder.


Except that mailing lists are also recipients, notably including likely 
history from authors, and possibly more history than a final recipient?


There are, of course, possible signals a final recipient might have 
about an author, that the mailing list won't have. Equally there might 
be others the list has that the final recipient doesn't, such as knowing 
about other mail from the author, to other lists the mailing list system 
operates...




DMARC ties DKIM to the From header and at least is interpreted as
being an
anti-phishing feature.  DKIM signing mail that you forward could
mean upgrading
a phishing message to passing DMARC.


I don't understand.  The first sentence makes sense to me, but the
second doesn't.

"Upgrading...to passing DMARC only applies if a) the signature
matches the From: field domain, and b) that domain has an
associated DMARC record.  But if you don't watch DMARC to apply in
that case, what is the DMARC record there fore?

I send a phishing message to a mailing list or alias at a domain with 
a From header of that domain, and the list blindly
re-signs all mail sent to the list, I've now "authenticated" the 
spoofed message, and it will now "pass" DMARC.


There are so many different ways this represents really poor mailing 
list setup, operation and possibly design, I again wonder at your 
offering it as an example of any point relevant to this exchange.


It's not that what you suggest hasn't happened, it's that the fact that 
it represents multiple problems also suggests it can -- and probably 
should -- have multiple solutions.




Perhaps it
upgraded from a quarantine to none, since the mailing list doesn't 
have the concept of a spam folder, or perhaps the sales@ team
has decided they want all of the forwarded messages, even if probably 
spam, so that they can go through them to make sure...
but it lost the quarantine disposition on the forward when it gained 
authentication.


More problematic hypotheticals, all of which arguably represent poor 
services, just as originators can be poorly run services.




Perhaps this all means that DKIM has been used for more than it
was intended for.


"More than" suggests that the use has legitimacy.  It doesn't.

We don't always have control over how our work is used.


No, but we do have control over a) how we write about it, b) how we talk 
about it, and c) what we do about misuses of the work.


You appear to be taking the view that however others choose to interpret 
a specification is what the specification is for and how it operates.  
Except that that is only one -- and I'd argue highly problematic -- 
approach to misuses of a specification.




If I proposed extending a standard in a new direction that would
be perfectly fine with the original intent of the standard, and that 
clashed with how the standard had come to be used in

practice, my extension is DOA.


Possibly.  But not automatically.

For reference, note that 90+% of email is spam.  Does that mean that a 
proposal to counter that (inappropriate) use of email is DOA?  That 
seems to be the logic you've applied.




Forgive me but I think that:


Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication assessment to a
message's ordered set of handling results.


specifies a nature and responsibility pretty much identical to
what DKIM claims.  The enhancements are a) chaining, and b)
carriage of earlier assessments.  But in terms of
'responsibility', this reads the

Re: [dmarc-ietf] ARC questions



On 11/23/20 3:00 PM, Dave Crocker wrote:

On 11/23/2020 2:58 PM, John R Levine wrote:
And, again, when ARC work was pursued, I don't recall anyone 
claiming that mailing lists were (significant) sources of misbehavior.
Well, OK.  Please feel free to provide footnoted documentation of 
what the actual motivation for ARC was if you believe it was 
something else.



Typically, the burden of substantiating a claim falls on the person 
making the affirmative claim.


What I'm struggling to understand is what having authenticated auth-res 
from a previous hop helps. this is what i found:


"With this information, Internet Mail Handlers MAY inform local policy 
decisions regarding disposition of messages that experience 
authentication failure due to intermediate processing."


that and:

"When an Authenticated Received Chain is used to determine message 
disposition, the DMARC processor can communicate this local policy 
decision to Domain Owners as described in Section 7.2.2."


seems to be the only motivation I can find. without ARC, a receiver 
could always check the new DKIM signature from, say, the mailing list 
and look up its reputation to decide whether to pass it along or not 
overriding the originating domain's policy. my recollection was that 
this was the "you break it, you own it" policy which i recall being the 
consensus. and indeed, there is nothing to stop a filter to look at the 
mailing list's auth-res and take it into account even if it's not part 
of the headers in the signature. maybe there is some attack there i'm 
not seeing off the top of my head, but it seems like this really hinges 
on reputation as was pointed out to me earlier.


It would be kind of nice to understand what gap ARC actually plugs and 
why it's important if you ask me. Also: there seem to be a lot of ways 
to achieve this, but this one is probably the most complicated one that 
I can envision.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 2:58 PM, John R Levine wrote:
And, again, when ARC work was pursued, I don't recall anyone claiming 
that mailing lists were (significant) sources of misbehavior.
Well, OK.  Please feel free to provide footnoted documentation of what 
the actual motivation for ARC was if you believe it was something else.



Typically, the burden of substantiating a claim falls on the person 
making the affirmative claim.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

I believe that Brandon has specifically said that Gmail sees this problem 
and that is why whitelisting mail from mailing lists isn't adequate. 


And that constitute "meaningfully document[ing]"?


Works for me.  I doubt I was the only person wondering why it needed all 
that mechanism when whitelisting mailing lists got you most of the way 
there, particularly since you need that whitelist anyway to know when to 
start ARC analysis.


And, again, when ARC work was pursued, I don't recall anyone claiming that 
mailing lists were (significant) sources of misbehavior.


Well, OK.  Please feel free to provide footnoted documentation of what 
the actual motivation for ARC was if you believe it was something else.


R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 2:42 PM, John R Levine wrote:
Forgive me but I believe misbehavior by mailing lists has never been 
meaningfully documented for this work.  Quite the contrary.


I believe that Brandon has specifically said that Gmail sees this 
problem and that is why whitelisting mail from mailing lists isn't 
adequate. 


And that constitute "meaningfully document[ing]"?

My point wasn't that it isn't a valid concern, but that it was not 
explicitly stated as the motivation. Again:



ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering. 

offers a characterization of mailing lists that hasn't been documented.

And, again, when ARC work was pursued, I don't recall anyone claiming 
that mailing lists were (significant) sources of misbehavior.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


You know that a message came from a mailing list because you have your
list of IPs or DKIM signatures of lists you trust.


Except that was not stated or, really, even implied in the text of the 
message I was replying to.  Rather, something like that seemed to be taken as 
an assumption, but without any clear foundation.


Well, OK, but it's still true.


ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering.


Forgive me but I believe misbehavior by mailing lists has never been 
meaningfully documented for this work.  Quite the contrary.


I believe that Brandon has specifically said that Gmail sees this problem 
and that is why whitelisting mail from mailing lists isn't adequate.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 1:27 PM, John Levine wrote:

In article ,
Dave Crocker   wrote:

I believe, though, that the intent of ARC is that it be scalable in
ways that manual enumeration of known legit mailing lists and
forwarders is not.

"if you know which hosts are legit" buries an assumption that is
problematic, namely that you know who handled the message.  The fact
that a message purports to be handled by a mailing list you trust does
not mean it actually was.

Pretty close, but not quite.

You know that a message came from a mailing list because you have your
list of IPs or DKIM signatures of lists you trust.


Except that was not stated or, really, even implied in the text of the 
message I was replying to.  Rather, something like that seemed to be 
taken as an assumption, but without any clear foundation.


For these kinds of discussions, which are mostly about understanding 
these capabilities clearly, accurately, and precisely, the core 
requirement is to separate the essential bits of information and the 
basis for knowing each bit.




ARC deals with the problem that most list software forwards everything
with a subscriber's address on the From: line and does a lousy job of
spam filtering.


Forgive me but I believe misbehavior by mailing lists has never been 
meaningfully documented for this work.  Quite the contrary.


List mail has been collateral damage, not because lists have misbehaved 
but because they got caught by a spontaneous change in the email service 
by some providers.



d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 12:48 PM, Dave Crocker wrote:

This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ 



The level of condescension, ignorance, and error throughout that 
article is impressive.  Given that it was written by someone whose 
profession requires extreme care about complex matters, the level of 
carelessness in the article is especially unfortunate.


Conveniently, he put his biggest error in bold font:

 "*DKIM provides a life-long guarantee of email authenticity that 
anyone can use to cryptographically verify the authenticity of stolen 
emails, even years after they were sent."*


DKIM does no such thing.



Yeah, that was pretty bad. "DKIM can be used to verify a piece of mail 
due to operator practices, but there are absolutely no guarantee that a 
signature will verify in the future due to those same practices."




ps. making sure that DKIM signature become invalid  relatively soon -- 
I think that removing the keys is simpler and just as effective as 
publishing the private keys -- seems like a reasonable suggestion.



Stephen Farrell is threatening to write an ID on the subject of 
publishing private keys. Frankly the stakeholders -- providers and users 
-- are not very well aligned on when where and why a provider would do 
such a thing. And writing an ID to say how to invalidate key when just 
unpublishing old selectors when you rotate keys is an easy second best 
shows that inertia is the actual issue, not the technical shortcoming.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread John Levine

In article  
you write:
>I suppose that an approach to building up an ARC reputation might be one
>where over time a receiving site can compare indirect mail flow that is
>purported to have X as an authenticated identifier with mail that comes
>direct to the receiving site with X as an authenticated identifier. ...

I think it's more likely to be ad-hoc, does this source send mail that
looks like mailing lists and the recipients don't flag or complain
about it.

R's,
John

PS:

>This email and all data transmitted with it contains confidential and/or
>proprietary information intended solely for the use of individual(s)
>authorized to receive it. If you are not an intended and authorized
>recipient you are hereby notified of any use, disclosure, copying or
>distribution of the information included in this transmission is prohibited
>and may be unlawful. Please immediately notify the sender by replying to
>this email and then delete it from your system.

Too late.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 12:15 PM, Brandon Long wrote:



This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ 



Perhaps this all means that DKIM has been used for more than it was 
intended for.


It is a quirk that we didn't consider at the time. You can't count on 
that property because providers can change their selectors at any time. 
That said, there is an awful lot of hand wringing for not much gain. 
It's not like you need cryptographic non-repudiation to be pretty sure 
something wasn't forged. That and non-repudiation has its benefits as well.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

On 11/23/2020 12:15 PM, Brandon Long wrote:
On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker > wrote:

> Yes, of course, a handling agent can do it, but there are plenty
of reasons
> why they shouldn't.

Please enumerate and explain. If it's that dangerous, we should
document it, especially I don't recall that constraint being in
any of
the design or standardization discussions.

DKIM often ties a domain to reputation and other anti-spam features.
If you
forward spam to another host and sign it while forwarding, then the
other host

will think you send spam.

Well, ummm... e... yes. That's because, in such circumstances, you do.

More significantly, the signature makes sure that such as an assessment
will only be made accurately, rather than penalizing you for problematic
mail that is attributed to you but that you did not handle.

DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature. DKIM signing mail that you forward could mean
upgrading

a phishing message to passing DMARC.

I don't understand. The first sentence makes sense to me, but the
second doesn't.

"Upgrading...to passing DMARC only applies if a) the signature matches
the From: field domain, and b) that domain has an associated DMARC
record. But if you don't watch DMARC to apply in that case, what is the
DMARC record there fore?

This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

The level of condescension, ignorance, and error throughout that article
is impressive. Given that it was written by someone whose profession
requires extreme care about complex matters, the level of carelessness
in the article is especially unfortunate.

Conveniently, he put his biggest error in bold font:

"*DKIM provides a life-long guarantee of email authenticity that
anyone can use to cryptographically verify the authenticity of stolen
emails, even years after they were sent."*

DKIM does no such thing.

and this was quickly followed by the normal-font:

"The key design goal of DKIM was to prevent spammers from forging
emails /while in transit/. "

This, too, is not what DKIM does. DKIM provides a noise-free channel
for assessing signers, not for detecting spammers. The difference is
important; and I claim fundamental.

ps. making sure that DKIM signature become invalid relatively soon -- I
think that removing the keys is simpler and just as effective as
publishing the private keys -- seems like a reasonable suggestion.

Perhaps this all means that DKIM has been used for more than it was
intended for.

"More than" suggests that the use has legitimacy. It doesn't.

> > Intermediaries don't want to take ownership of the
message in that
> > sense, though there
> > are some mailing lists that do.
>
> Signing with DKIM does not take 'ownership'.
>
>
> Yes, responsibility is the proper word. My point survives the
word change.

I disagree.

> DKIM says the domain takes responsibility for the message, while
ARC says
> the domain takes responsibility for evaluating the status of the
message
> when
> they received and forwarded it.

This implies that the word 'some' is irrelevant. It isn't. And it
was
included intentionally.

Automated systems can't really tell how much responsibility an
intermediary was

intending to take for the message.

People who write them can.

OTOH, they typically are using it only for a certain
purpose, so they assume that the intermediary took responsibility in
the sense that they
want... or rather, the people who wrote the code do. Or the
journalist writing the story.

ARC was specified to have a more specific responsibility,

Forgive me but I think that:

Authenticated Received Chain (ARC) creates a mechanism for individual
Internet Mail Handlers to add their authentication assessment to a
message's ordered set of handling results.

specifies a nature and responsibility pretty much identical to what DKIM
claims. The enhancements are a) chaining, and b) carriage of earlier
assessments. But in terms of 'responsibility', this reads the same as DKIM.

and as different from DKIM so
that it wasn't mistaken for the uses that people were already using
DKIM for.

Oh?

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 12:29 PM, John R Levine wrote:

1) A mailing list creates an auth-res on the incoming mail to the list

2) It modified the message

3) It resigns the message with DKIM

4) It is then delivered to the subscriber's mail server

5) The destination mail server can look at the incoming message 
including the mailing list's auth-res and decide whether to trust it 
or not just like ARC.


It seems to me this covers the vast majority of cases. What are the 
other cases where this is not sufficient and how significant are they 
in reality?


Two or more levels of forward are quite common, particularly in large 
mail systems.  Look at mail coming out of Google and Microsoft's 
hosted mail and you'll see a lot of ARC headers.


Considering that the ARC RFC was published over a year ago, and it is 
implemented all over the place, could you explain what the point of 
this discussion is?  The people who designed ARC are not idiots.  If 
we could have fixed the mailing list problem with existing DKIM 
signatures, we would have.


Then why is it not standards track? And am I to understand that I'm not 
allowed to comment on an experiment? Perhaps the working group chairs or 
AD can clarify that.


In any case, if this all boils down to whether I trust the intermediary 
who resigned the message, then that is a previously solved problem: you 
can base the reputation check based on the resigned signature. I'm not 
entirely sure what the value of  the previous auth-res is. If I recall 
correctly, the document was sort of short on what the specific utility 
is, but I may have missed it.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions




On 11/23/20 12:09 PM, John R Levine wrote:


Since this is an experiment, do we have an idea of what the rest of 
the problem is after the typical mailing list-like signature breakers 
are excluded?


Sorry, this question makes no sense. The point of ARC is to deal with
the kind of breakage that mailing lists cause.



1) A mailing list creates an auth-res on the incoming mail to the list

2) It modified the message

3) It resigns the message with DKIM

4) It is then delivered to the subscriber's mail server

5) The destination mail server can look at the incoming message 
including the mailing list's auth-res and decide whether to trust it or 
not just like ARC.


It seems to me this covers the vast majority of cases. What are the 
other cases where this is not sufficient and how significant are they in 
reality?


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread Brandon Long

On Mon, Nov 23, 2020 at 11:53 AM Dave Crocker  wrote:

> On 11/23/2020 11:42 AM, Brandon Long wrote:
> >
> >
> > On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker  > > wrote:
> >
> > On 11/23/2020 11:29 AM, Brandon Long wrote:
> >  > The DKIM-Signature is an "ownership" thing, it's a message
> > originator
> >  > that is saying
> >  > "associate this message to me".
> >
> > That is not DKIM's semantics:
> >
> >  "DomainKeys Identified Mail (DKIM) permits a person, role, or
> >  organization to claim some responsibility for a message by
> >  associating a domain name"
> >
> > This says nothing about whether the organization has anything to do
> > with
> > origination.
> >
> > There is nothing to prohibit or preclude handling agents other than
> the
> > originator from signing.
> >
> >
> > Yes, of course, a handling agent can do it, but there are plenty of
> reasons
> > why they shouldn't.
>
> Please enumerate and explain.  If it's that dangerous, we should
> document it, especially I don't recall that constraint being in any of
> the design or standardization discussions.
>

DKIM often ties a domain to reputation and other anti-spam features.  If you
forward spam to another host and sign it while forwarding, then the other
host
will think you send spam.

DMARC ties DKIM to the From header and at least is interpreted as being an
anti-phishing feature.  DKIM signing mail that you forward could mean
upgrading
a phishing message to passing DMARC.

This recent article also goes into things that DKIM signatures imply:
https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

Perhaps this all means that DKIM has been used for more than it was
intended for.

> >  > Intermediaries don't want to take ownership of the message in that
> >  > sense, though there
> >  > are some mailing lists that do.
> >
> > Signing with DKIM does not take 'ownership'.
> >
> >
> > Yes, responsibility is the proper word.  My point survives the word
> change.
>
> I disagree.
>
>
> > DKIM says the domain takes responsibility for the message, while ARC says
> > the domain takes responsibility for evaluating the status of the message
> > when
> > they received and forwarded it.
>
> This implies that the word 'some' is irrelevant.  It isn't.  And it was
> included intentionally.
>

Automated systems can't really tell how much responsibility an intermediary
was
intending to take for the message.  OTOH, they typically are using it only
for a certain
purpose, so they assume that the intermediary took responsibility in the
sense that they
want... or rather, the people who wrote the code do.  Or the journalist
writing the story.

ARC was specified to have a more specific responsibility, and as different
from DKIM so
that it wasn't mistaken for the uses that people were already using DKIM
for.

Brandon
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

If auth-res is sometimes deleted, why wouldn't we expect the arc auth-res to 
not be deleted too?


Please see RFC 7001, section 5.

Since this is an experiment, do we have an idea 
of what the rest of the problem is after the typical mailing list-like 
signature breakers are excluded?


Sorry, this question makes no sense. The point of ARC is to deal with
the kind of breakage that mailing lists cause.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:34 AM, Brandon Long wrote:


From the other direction, one could say that ARC is a superset of A-R 
and DKIM with
different purpose, and you might be able to subsume them into ARC, but 
you couldn't

build ARC out of the originals.



It's seems to me that the superset involves explicitly binding an 
auth-res to a dkim-like signature. Is there more beyond that?


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:49 AM, Brandon Long wrote:


I imagine that the vast majority of intermediaries that break
signatures
number exactly one extra domain, so it's not very hard to reconstruct
the chain of custody from origin to destination. Assuming the
intermediary resigns with the incoming auth-res, the destination can
choose to believe that auth-res or not, right? Since this is an
experiment, do we have an idea of what the rest of the problem is
after
the typical mailing list-like signature breakers are excluded?


No, as in the RFC says to remove them, so it's a standard part of 
implementation.


RFC 7601 4.1:

instances of the header field that appear to originate within the
ADMD but

are actually added by foreign MTAs will be removed before delivery.


That's very different than "just maybe it might be removed"

The receiving MTA in the next domain doesn't have to discard the 
information before removing it. The act of removing it is so there isn't 
confusion about the ultimate auth-res, especially with MUA's. The 
incoming MTA is free to consider the previous auth-res just like it's 
free to consider the previous arc auth-res.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

On 11/23/2020 11:42 AM, Brandon Long wrote:

On Mon, Nov 23, 2020 at 11:34 AM Dave Crocker > wrote:

On 11/23/2020 11:29 AM, Brandon Long wrote:
 > The DKIM-Signature is an "ownership" thing, it's a message
originator
 > that is saying
 > "associate this message to me".

That is not DKIM's semantics:

     "DomainKeys Identified Mail (DKIM) permits a person, role, or
     organization to claim some responsibility for a message by
     associating a domain name"

This says nothing about whether the organization has anything to do
with
origination.

There is nothing to prohibit or preclude handling agents other than the
originator from signing.

Yes, of course, a handling agent can do it, but there are plenty of reasons
why they shouldn't.

Please enumerate and explain.  If it's that dangerous, we should 
document it, especially I don't recall that constraint being in any of 
the design or standardization discussions.

 > Intermediaries don't want to take ownership of the message in that
 > sense, though there
 > are some mailing lists that do.

Signing with DKIM does not take 'ownership'.

Yes, responsibility is the proper word.  My point survives the word change.

I disagree.

DKIM says the domain takes responsibility for the message, while ARC says
the domain takes responsibility for evaluating the status of the message 
when

they received and forwarded it.

This implies that the word 'some' is irrelevant.  It isn't.  And it was 
included intentionally.

d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:42 AM, Brandon Long wrote:


Yes, responsibility is the proper word.  My point survives the word 
change.


DKIM says the domain takes responsibility for the message, while ARC says
the domain takes responsibility for evaluating the status of the 
message when

they received and forwarded it.


But it can already do that be re-signing its auth-res.

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/23/20 11:28 AM, John R Levine wrote:
From what I can tell, the main thing that ARC is doing is binding an 
auth-res to a dkim signature-like thing. But as I recall -- it's been 
a long time -- there were ordering requirements ala received headers 
for where new dkim-signatures and auth-res go in the header. Assuming 
my memory is correct, that means you can reconstruct "what this 
looked like before i messed with it" already by signing the incoming 
auth-res as part of the new DKIM signature.


Is there something more going on here?


Not really.  There are ordering rules but mail systems do not follow 
them reliably, DKIM signatures in practice are not ordered.  Also, A-R 
can be deleted in some situations, so ARC makes copies of them to be 
more robust in transit.


If auth-res is sometimes deleted, why wouldn't we expect the arc 
auth-res to not be deleted too?


I imagine that the vast majority of intermediaries that break signatures 
number exactly one extra domain, so it's not very hard to reconstruct 
the chain of custody from origin to destination. Assuming the 
intermediary resigns with the incoming auth-res, the destination can 
choose to believe that auth-res or not, right? Since this is an 
experiment, do we have an idea of what the rest of the problem is after 
the typical mailing list-like signature breakers are excluded?


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

From what I can tell, the main thing that ARC is doing is binding an auth-res 
to a dkim signature-like thing. But as I recall -- it's been a long time -- 
there were ordering requirements ala received headers for where new 
dkim-signatures and auth-res go in the header. Assuming my memory is correct, 
that means you can reconstruct "what this looked like before i messed with 
it" already by signing the incoming auth-res as part of the new DKIM 
signature.


Is there something more going on here?


Not really.  There are ordering rules but mail systems do not follow them 
reliably, DKIM signatures in practice are not ordered.  Also, A-R can be 
deleted in some situations, so ARC makes copies of them to be more robust 
in transit.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions



On 11/22/20 11:56 AM, John R Levine wrote:

On Sun, 22 Nov 2020, Michael Thomas wrote:
The ARC signature has a sequence number so you can track the chain 
of custody.  You are right that it is similar to the DKIM signature 
but the extra ovehead doesn't seem excessive.


Did the wg consider just grafting that onto the DKIM signature itself 
instead of having essentially a duplicate signature? Receivers are 
already supposed to ignore any tags they don't understand so it 
shouldn't hurt backward compatibility.


ARC is an experiment that came from the people who designed DMARC.  
It's not a WG product.


Having adapted the perl DKIM module to handle ARC signing and 
verification, I can say that the extra signature is not a big deal.  
If you look at mail coming from large mail systems, they're full of 
other junk headers and the extra overhead of AMS along with DKIM is 
not important.


From what I can tell, the main thing that ARC is doing is binding an 
auth-res to a dkim signature-like thing. But as I recall -- it's been a 
long time -- there were ordering requirements ala received headers for 
where new dkim-signatures and auth-res go in the header. Assuming my 
memory is correct, that means you can reconstruct "what this looked like 
before i messed with it" already by signing the incoming auth-res as 
part of the new DKIM signature.


Is there something more going on here?

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 10:34 AM, Todd Herr wrote:
Yes, but knowing it really was handled by who is saying it was handled 
by isn't the entirety of the problem.



Of course.  But it helps (quite a lot) to be clear about what this 
specific mechanism does do.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread Todd Herr

On Mon, Nov 23, 2020 at 12:02 PM Dave Crocker  wrote:

> On 11/23/2020 7:38 AM, Todd Herr wrote:
>
> On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan 
> wrote:
> On Sat, Nov 21, 2020 at 7:14 PM John Levine  wrote:
>
>>
>>
>>> This also means that ARC isn't useful if you don't have a reputation
 system to tell you where the lists and other forwarders that might add
 legit ARC signatures are.

>>>
>> And if you know which hosts are legit mailing lists or forwarders, you
>> already know what ARC would tell you.
>>
>
> I believe, though, that the intent of ARC is that it be scalable in ways
> that manual enumeration of known legit mailing lists and forwarders is not.
>
>
> "if you know which hosts are legit" buries an assumption that is
> problematic, namely that you know who handled the message.  The fack that a
> message purports to be handled by a mailing list you trust does not mean it
> actually was.
>
> That's the issue that ARC resolves.
>
> ARC (and DKIM) produce noise-free uses of identifiers.  If the
> authentication validates, the receiver knows is really was handled by who
> is saying it was handled by.  Without these, you don't.
>
>
> Yes, but knowing it really was handled by who is saying it was handled by
isn't the entirety of the problem.

I can know from ARC headers that X handled the message and what email
authentication checks X purports to have done when handling the message and
what results X claims to have obtained. What I have to decide in that case
is "do I trust X to record correct and valid results?" because the answer
to that question will impact my disposition of the message when it reaches
me.

It's obviously not the place of the ARC protocol spec to proscribe how
trust in ARC results can be determined, but without some system in place
for assigning trust levels to ARC Sealers, ARC has limited utility for
sites that serve as the terminal destination for a message.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions


On 11/23/2020 9:15 AM, Doug Foster wrote:
ARC tells me that somebody changed some data, but it does not tell me 
which MTA performed the forwarding operation, added content, or 
performed address rewriting.  If we could get HELO names into the ARC 
data, then those names could be correlated with the Received header 
chain to make better filtering decisions.



That's not ARC.  Feel free to recruit others to support a new 
initiative, for a different protocol.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions

2020-11-23 Thread Doug Foster

My wishlist for ARC:

 

ARC tells me that somebody changed some data, but it does not tell me which MTA 
performed the forwarding operation, added content, or performed address 
rewriting.  If we could get HELO names into the ARC data, then those names 
could be correlated with the Received header chain to make better filtering 
decisions.

 

DF   

 

From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Monday, November 23, 2020 12:02 PM
To: Todd Herr; Joseph Brennan
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] ARC questions

 

On 11/23/2020 7:38 AM, Todd Herr wrote:

On Mon, Nov 23, 2020 at 9:50 AM Joseph Brennan  wrote:

On Sat, Nov 21, 2020 at 7:14 PM John Levine  wrote:

 

This also means that ARC isn't useful if you don't have a reputation
system to tell you where the lists and other forwarders that might add
legit ARC signatures are. 

 

And if you know which hosts are legit mailing lists or forwarders, you already 
know what ARC would tell you.

 

I believe, though, that the intent of ARC is that it be scalable in ways that 
manual enumeration of known legit mailing lists and forwarders is not. 

 

"if you know which hosts are legit" buries an assumption that is problematic, 
namely that you know who handled the message.  The fack that a message purports 
to be handled by a mailing list you trust does not mean it actually was.

That's the issue that ARC resolves.

ARC (and DKIM) produce noise-free uses of identifiers.  If the authentication 
validates, the receiver knows is really was handled by who is saying it was 
handled by.  Without these, you don't.

d/

-- 

Dave Crocker
dcroc...@gmail.com
408.329.0791
 
Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] ARC questions