On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely <ves...@tana.it> wrote:
> On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote: > > > > Lists are a specific instance of the more general case of indirect mail > flows. > > > How many kinds of indirect mail flows do rewrite From:? > > Specific methods might prove more effective than general ones. > > Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From address, and is sometimes used in mail that is forwarded by rule, say from @ alum.institution.edu to @consumerMailboxProvider.com The larger point, though, is that mail that automatically passes through one or more intermediary hosts on its way to its final destination can fail authentication checks at the final destination due to the impact of changes on the message, either in path, or content, or both, as it traverses that journey. It seems to me that we can either work to find a way to ensure that such failures don't happen, or we can work to find a reliable and trustworthy way to record authentication results along the way so that the failures can be mitigated and not result in failed delivery of wanted mail. > > [...] > > > > Since the receiver typically can't perform the same checks under the > same > > conditions that existed when the intermediary performed them (if it > could, we > > wouldn't need something like ARC) then the receiver has to decide if the > > message is consistent with messages it's previously seen through direct > mail > > flows using that same authenticated identity that was captured by the > > intermediary in the ARC header set. > > > Doesn't that assume some kind of omniscience at the receiver's? > Consistency > with previous messages by the same source is not straightforward. Using > the > same selector? Signing more or less the same set of header fields? > Choice of > vocabulary? HTML vs. plain text style (e.g. line length)? A.I.? > > Not omniscience, no, but certainly a method of tracking an authenticated identity's reputation, and consistency of reputation is what I'm speaking of. Allow me to try again to get across the idea that I'm so far failing to make clear. I'm not currently working for a mailbox provider, but I have in the past, and so I will role play as one here. As a mailbox provider, I have a system for authenticating the identity or identities associated with messages that come directly to me. These authenticated identities can include some or all of: - The DKIM signing domain(s) - The DKIM signing domain(s) and selector(s) - The RFC5322.From domain (authenticated using DMARC) - The RFC5321.From domain (SPF) - The IP address of the client that passed the message to me - The domain associated with the PTR record of that IP address - Others as I deem useful For each of these authenticated identities, I can and will track how my users/customers/mailbox holders engage with the mail they receive, thus over time establishing in my system a reputation to associate with each authenticated identity. If, for example, mail that is DKIM signed using selector S and domain D is mail that my users demonstrate through their actions (opening it, clicking on links in it, etc.) is wanted mail, then that authenticated identity (S._domainkey.D) will be associated with a good reputation (however I define "good") in my system. Lather, rinse, and repeat for other authenticated identities associated with the message, and allow that both good and bad reputations can be earned. Now here comes a message that is DKIM-signed by D with selector S, and it fails DKIM validation when I do my checks. However, in scanning the message, I see that there is an ARC header set, one that was signed and sealed by A, and in that ARC header set is an ARC-Authentication-Results header that says that the message passed DKIM validation with signing domain D and selector S when A did its check. My conundrum here is "Do I trust A's claim that the message was correctly DKIM signed by domain D with selector S?" The answer to that question will depend on how my users treat the message and others like it, assuming that I accept it and deliver it. If my users treat such messages in a manner that's consistent with how they treat direct mail flow that is DKIM-signed by D with selector S, then A's reputation as an ARC-sealer/signer will be positive, because A will establish with me a history of being a source of ARC-sealed/signed mail with ARC header sets that can be believed. On the other hand, if my users consistently treat such messages differently than they do direct mail flow that is DKIM-signed by D with selector s, then A's reputation as an ARC-sealer/signer will be negatively impacted with me, because I will not have evidence in hand that this is a path for mail with an authenticated identity of S._domainkey.D to take. The point here is that ARC (or any system designed to capture intermediate authentication results) can only succeed if the downstream recipients of the message trust the information that the intermediary host(s) record in the message. What I'm describing above is one way to determine if that information can be trusted, one that I'm trying to design to scale beyond "Let me just whitelist these X hosts as reliable ARC sealer/signers." -- *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