Well, the obvious usage of ARC where DKIM is not a solution is for any modifying hop, such as a mailing list. The mailing list can DKIM sign the modified message, but it then lacks alignment and also takes on "ownership" of the message (see discussion about forwarding in general taking the reputation hit for what is forwarded).
ARC does require knowing when to use the arc information and when not to, so trust. Trust can be learned or hard coded. ARC also means I don't need to trust an intermediary as long as they don't break the chain (or modify the message, which ARC will also tell you) So: Sender -> Trusted forwarder -> Untrusted forwarder -> destination Because it's an untrusted forwarder, I can't trust their received headers. Even with a trusted forwarder, that doesn't mean you know the auth results, the forwarder may forward regardless of auth status, and that auth status is information lost. AuthRes was designed for internal passing of auth information, ARC extends that to external passing. Brandon On Mon, May 22, 2017 at 4:30 PM, Vladimir Dubrovin via mailop < mailop@mailop.org> wrote: > > DKIM is solution. > > ARC is not solution and never will. Actually, I see no any reason for ARC, > really. If you trust sender, you can trust his Received: without any > cryptography. If you do not trust sender, you can not trust ARC regardless > of cryptography. ARC doesn't work without trusts. The only good thing in > ARC comparing to Received: is domain name instead of hostname. Or do I miss > something? > > > 23.05.2017 0:54, Steve Atkins пишет: > > On May 22, 2017, at 2:42 PM, W Kern <wk...@pixelgate.net> > <wk...@pixelgate.net> wrote: > > > We quarantine inbound SPF failures. Customers complain but we point that out. > So those are not the issue. > > I am talking about the scenario where a third party sender WITH an -all SPF > record sends to my customer and then MY customer forwards it elsewhere > (gmail, hotmail). > > From our server's perspective it is a legitimate acceptance and no SPF > failure occurred. Of course we are going to accept it. > > But unless we REWRITE it then when we forward back out its an SPF failure at > the forwarding destination, and where we have tried rewriting we have seen > pushback and technical issues. > > I suppose we could write something unique and refuse to forward such emails, > but the standard software doesn't accommodate that as of yet. > > ARC is the very-near-future solution to much of this. Get your vendors on it. > http://arc-spec.org > > Cheers, > Steve > _______________________________________________ > mailop mailing > listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > -- > Vladimir Dubrovin > [image: @Mail.Ru] > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
