On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <m...@mtcc.com> wrote:
> > On 11/24/20 3:24 PM, Brandon Long wrote: > > > On Tue, Nov 24, 2020 at 2:49 PM Michael Thomas <m...@mtcc.com> 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
