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 <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. > > > > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
