Re: [dmarc-ietf] ARC questions

[Michael Thomas <[e-mail]>]

On 11/24/20 4:56 PM, Brandon Long wrote:
>
>
> On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <[e-mail] 
> <mailto:[e-mail]>> 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 <http://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