On Fri, Jul 27, 2018 at 7:39 PM, Bron Gondwana <br...@fastmailteam.com> wrote:
> The only thing your ARC Seal will validate is your own > ARC-Authentication-Results header - which isn't nothing (it could contain > the IP address that you received this message from) - but if SPF / DKIM and > ARC are all fails in your Authentication-Results, any earlier ARC and DKIM > headers have no provable causal relationship with the rest of the message > you received. > A structurally valid ARC Chain (all ARC Sets have one each of the ARC header fields, the ARC Sets instance numbers are 1..N inclusive, and each AS covers all ARC Set header fields on the message 1..its own instance number) where all AS's validate says a very specific thing about that ARC Chain: that no one has modified *THE ARC HEADER FIELDS* that are part of the Chain. This also means that from the first ARC Set at i=1 through the last passing ARC Set, you have a guaranteed list of all domains who have modified the message (yes, some may have Sealed without modifying) and the corresponding ARC-Authentication-Results each saw, which you know have not been modified by someone other than the ADMD which added them. This does not stop someone from taking an intact and passing ARC Chain and adding their own garbage on top. Fundamentally, this is how mail work; mail is spooled and replayed all the time by design. This is an issue with DKIM, and covered in 6376 sections 5.4.1 and 8.6. Since ARC inherits heavily from DKIM, it also inherits these specific replay issues. It was determined that fixing the replay issue was out of scope, except for providing guidance on how to contain impact. Sections 9.4 and 9.5 talk directly to these issues: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.4 https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-9.5 Frankly, your concern speaks directly to the issue I raised initially. If cv=fail only signs itself, then there is absolutely no way to localize the issue and determine which Sealer decided to run amok with the Chain. If you see a cv=fail, you have to throw out all the data. At least when Sealing cv=fail, if you Seal greedily, there is in intact chain of Seals which can be used to make important determinations as to the veracity of the header field data and may be able to use that to determine where things may have fallen apart or been replayed.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
