Murray S. Kucherawy writes: > And whatever deficiencies people see in ARC, it is a protocol-based > response. > > We have made no statement that ARC even works, much less that it solves the > stated problem. Our story is incomplete.
I think ARC works, but what is missing from the RFC is the description how... Wanted indirect mail flows do not happen without the user concent. If I get alumni address from university, I usually know about it, or at least recognize that forwarding domain when someone sends me email to that address. If I join to the mailing list, I know that I have done that, so I will recognize that forwarding domain. If I am part of the role address (like board members of the non profit organization), I know about that and will recognize that forwarding domain. This means I do have some trust on all those forwarding domains. I trust them to forward emails sent to my address on those systems to my other address, and I am already willing to allow them to process my emails, as they already go through those machines. I most likely trust them enough to expect that if they say they did DKIM/SPF/ARC checks and record that information in the ARC header they did that correctly, and did not fake authentication results in the ARC header. This means that if I get email which does not pass DKIM (it will almost never pass SPF, as it is indirect email flow), but do pass ARC, and the ARC domain is in my "trusted forwarders list", the filtering process can trust the ARC authentication results found from the ARC header for me for that domain. This is my personal trusted forwarders list, it is not global, and other people will have different sets of forwarders they trust. If I get email that do have ARC header, but which is not in my trusted forwarders list then I should be able easily click on that email and say add this ARC signing domain to my trusted forwarders list. I.e., when I receive first email from new mailing list I just joined, that email might end up in spam box, but I can dig it out there and mark that ARC signer to be "trusted", i.e., added to my trusted forwarders list. Of course mail agents might do more intelligent things, they might even see that I have received confirmation message when I joined mailing list, and ask whether I want to add that ARC signer to trusted list then. Or they might assign score to each entry in trusted forwarders list, i.e., mailing list forwarders might not be "as trusted" as my role based forwarders, and that score might affect the content filtering score. Of course the fact that message has ARC signature, does not provide any information whether the content of the email is valid, but it allows filtering process to use the DKIM/SPF/ARC authentication results from the previous step. So email to this list actually will go through two indirect mail flows, the mailing list will do the first step, and then this email goes to the iki.fi (permanent email forwarding service I am using), and will get forwarded from there to my real mail box. I do trust iki.fi, so my local filters can go and use iki.fi authentication results from the ARC headers from iki.fi if the DKIM signature is not valid. I also trust ietf.org, so if ietf.org would add ARC headers to mails going to mailing lists, my filtering process could also check those in case the ones in iki.fi ARC header for some reason would not be acceptable (the iki.fi will return DKIM pass as ietf.org do add DKIM signature, but that does not tell me whether the DKIM signature passed when email was received by ietf.org). Of course my mail client should flag emails which fail authentication with visibile information that this email failed authentication, and make sure it would not show me the wrong authentication information, i.e., it should show me that all these mails comes from @ietf.org, not that it come from gmail.com (as ietf.org did not add ARC headers, so I have no idea whether the original email really came from gmail.com even when the From: header says so). So in my view, we should be able to say that ARC do work, and we should move that from experimental to standard track... -- [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
