Hi, Pete - On 20 March 2018 at 22:04, Pete Schaefers via Exim-users < exim-users@exim.org> wrote:
> Mike, thanks for taking the time to detail that! I guess I assumed (maybe > wrongly) that when EXIM forwards a message that the SPF and DKIM of the > domain on the EXIM server would apply and be in the sent forward. In that > case wouldn't all entities align? > I don't think I can help with the SES side of things, but here we've got full DKIM-signing in place along with tight SPF and DMARC policies in place so might be able to help with that side of things a bit. Going off memory the default Exim configuration didn't do any DKIM signing, or rewriting of envelope or sender addresses. So if it has to forward on a message then both the RFC5321.MailFrom envelope and RFC5322.From header addresses are left entirely untouched; the incoming message is relayed onward with the originals. That means at the mail server you're relaying onward to: - if it checks SPF and there's a policy published for the domain of the RFC5321.MailFrom then this will fail in the general case — your servers won't be listed in the SPF policy; - if it checks DKIM and the original sender added a DKIM signature then this will pass — because the body and signed headers haven't been altered the message's DKIM signature will still verify. If there's a DMARC policy for the domain of the RFC5322.From address then this will pass because, although the SPF test has failed, the DKIM test still passes and will (should!) have the domain of the signature align with that in the RFC5322.From. If you decide to rewrite the RFC5322.From without taking further measures you will invalidate the message's original DKIM signature. That means with neither the SPF nor DKIM tests passing the onward server may well be more suspicious of the message and could end up marking it as spam or take other measures. For example, Gmail usually puts a warning "Red Question Mark of Gloom" (my name for it!) next to a message someone arrives that lacks both SPF and DKIM passes. The "further measures" would involve things like you adding your own DKIM signature to the relayed message as you send it out, with its "d= *domainname*" aligning with the domain you use in the rewritten RFC5322.From header. Here you're effectively adding your own signature to the message (which will should pass further down the line) even though you've invalidated the original sender's DKIM signature. You can add further authenticity to the message by using ARC (which I admit freely that I don't fully understand!). I think this is a way of you indicating to an onward mail server that when you received this message you were able to verify its authenticity using SPF/DKIM/DMARC and so are adding a signed header to indicate that, even though those measures might no longer verify further down the line because you've rewritten headers and/or changed body content (eg, by adding a "To leave this mailing list…" type of footer). You can find a nice summary in the "Overview" section of this document: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-12 ARC doesn't have a formal RFC yet but is certainly used by Google for one. As you hadn't mentioned doing DKIM signing yourself I was erring on the side caution and alerting you to possible problems. If you want to talk further drop me a line direct, as this has veered away from Exim itself and the mechanics of doing things. Cheers, Mike B-) -- Systems Administrator & Change Manager IT Services, University of York, Heslington, York YO10 5DD, UK Tel: +44-(0)1904-323811 Web: www.york.ac.uk/it-services Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/