Hi, Pete -
On 20 March 2018 at 22:04, Pete Schaefers via Exim-users <
exim-users@???> 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
