John Mears wrote in <lo6p265mb69883c6f3219283ce1be2b76e8...@lo6p265mb6988.gbrp265.prod.OUTLO\ OK.COM>: ... |>It appears that Richard Clayton <[email protected]> said: |>>>> 4 repeat until you get back to the original state of the message or a |>>>> "z" recipe tells you that you need to unconditionally trust |>>>> someone... they presumably have placed an Authentication-Results |>>>> header field into the message and you have to use that for \ |>>>> your DMARC |>>>> and/or reputation calculations. |>>> |>>>I guess in this case A-R has to be signed? What handling is suggested |>>>in such a "z" case if you _don't_ trust the modifier? |>> |>>if you don't trust someone who modifies a message then I think you |>>should refuse to accept the message. | |>The idea of the "z" tag is that it's for filtering front ends like \ |>Proofpoint and Mimecast that rewrite URLs and strip attachments. They \ |>would only be doing that to mail sent to recipients who are paying \ |>them to do it. | |>This does mean that remailing such a message back out won't work with \ |>DKIM2 but I haven't seen a lot of mail like that. The rewrites tend \ |>to appear in replies or forwards that are new messages so they're OK. | |I speak as someone designing/implementing/running such a filtering \ |system. Yes, those kind of modifications (URL rewrites, attachment \ |removal) are generally done on inbound processing shortly before delivery \ |to the recipient's mail system. It certainly does happen in some situati\ |ons that the recipient's mail system can forward the original email, \ |rather than creating a new email including the original content. Question: \
|I guess it is up to the filtering intermediary's discretion whether \ |it uses z= rather than spell out recipes for the modifications made, \ |accepting the trade offs? For example the filtering intermediary might \ |use z= if the original has known malicious content that it wants to \ |remove all trace of - versus an email that it can establish is established \ |not malicious, in which case it would be useful for the forwarded recipi\ |ent to have the recipes for reconstruction? Very interesting question i was wondering why noone else asked them (in general) .. in public and on the ML. For the ACDC draft i speak and say that if you destruct the original message never to be seen again, you create a new message: the original variant cannot be brought back. One could add yet another flag to signal this special condition, say "T"ransplanted. However, one could also throw away all elder DKIM (and DKIX, thus) header fields, because they do not mean a thing, they would cause "z" (non-reversibly modified). Using "T" would shine a more smooth light onto any "z" that happens later on thus, and only. The same is true if "a user" throws away the DKIM-Store: header field of the ACDC approach, ie what carries state from ingress to egress. (If it is done like that software-wise, "surely is" for any non-integrated thing that uses external software for processing.) As there is no way to recover any former state (except "status" through the possible "I"ngress signature, unless that is also removed) without it. Maybe "T" is a good thing, and explicitly stating that in such cases any elder -DC header field should be removed as it became useless would then also make sense. And the "sequence" would not need to be reset to "0", in that case, even though any elder DKIM signature is "hanging in the air". It is solely a matter of trust to the hop which "T"s whether anything elder is not pure halluzination. That is a lot of trust. I remember having perceived PGP signing parties with passport request, announced by computer magazines weeks and months in advance. Paying money for a service seems to go in the same direction. So "T" for "Tranplantation" as well as for "(total) Trust". Having said all that i have never consciously seen things removed except for policy reasons (images, HTML MIME parts, (shell) scripts and executables) -- and those, except for their sheer size (and possible danger), could very well be part of a reversibility plan. I wonder what needs to be hard cut like that, and [.] Btw your message made me very interested, so, for whatever interesting reason, i actually did reread the current drafts as mentioned on the DKIM WG internet side, .. and it turns out there is no z=? (It seems to have existed in the past, there.) [.] it seems to me plain rejection was not only my thought. |New to this thread so apologies if I am reopening old wounds. Well the ACDC isn't it for the WG, but i thank you nonetheless, and it seems i should not only talk less but also iterate the draft once more, i have seen in the WG draft they have and i miss IANA registry requests for the new header fields, too. No hurry. Legal and such issues i would have expected to play a much bigger role. (It is different if you are only a glancing reader, or actively involved in something. Ie, maybe it has always been like that.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
