On Sat, 12 Aug 2017, at 10:54, Kurt Andersen (b) wrote: > On Fri, Aug 11, 2017 at 5:50 PM, Bron Gondwana > <br...@fastmailteam.com> wrote:>> __ >> >> >> >> Again - why seal on ingress? It's bogus. >> >> * check authentication on ingress >> * add authentication on egress >> >> That's the pattern that means something and works. Otherwise your >> internal mechanisms are going to have to be either ARC aware anyway, >> or you'll have to fix up ARC anyway.>> > As long as your method of communicating the ingress auth check > survives the transit of your internal infrastructure (which A-R does > not necessarily do as a result of some brain-dead gateway > implementations), I agree. Sealing on ingress is one such way to > provide that communication from ingress point to egress point but is a > bit noisy to do so. The obvious thing to do here (something we do in our FastMail infrastructure) is to add X-orgname-*: headers as required, and strip them all on egress. If your infrastructure is that complex, it's definitely worth doing something with your own custom headers internally, and by namespacing them with a common prefix, it's easy to make sure they don't leak out. And yes - in that case I would be making our egress system check the X-FM- AR header to make sure it came in authenticated, and then do an ARC check of its own to see if the message got modified internally, strip X-FM-*, and then either add ARC if the message was modified internally, or just send it with its existing ARC if it was untouched. Bron.
-- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
