Mike,
Thanks so much for the offer to direct contact you. In thinking this
over I'm getting the feeling that this route is just asking for trouble.
Even if I got it working now it might be a hassle to maintain and I
don't want to go there. But all this has me looking at what I think
would be a much simpler/safer solution.
Currently EXIM ignores mail between local accounts with regard to using
SES. I assume that is accomplished solely by a line in the prerouters
section.
PREROUTERS
send_via_ses:
driver = manualroute
domains = ! +local_domains <-----------------------------------------
this line, I assume
transport = ses_smtp
route_list = * email-smtp.us-west-2.amazonaws.com;
If I could also ignore all forwards, and handle them locally (as it does
those on local domains now) that would solve my problem because the
forwards I have in place now are doing fine without SES.
I haven't looked for the directive for this yet (I'll be googling on
that next...), so any help to get it right the first time would be
appreciated. I assume it would be another line in this section basically
stating: if !forward
It's a live production server, so I have to be careful and do my testing
at off-peak times. *yawn*
-Pete
On 2018-03-21 12:09, Mike Brudenell wrote:
> 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
