On 11/24/20 4:56 PM, Brandon Long wrote:
On Tue, Nov 24, 2020 at 3:57 PM Michael Thomas <m...@mtcc.com <mailto:m...@mtcc.com>> 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
