Re: [exim] How to rewrite From: header of offsite forwards o…

Pàgina inicial
Delete this message
Reply to this message
Autor: Pete Schaefers
Data:  
A: Exim-users
Assumpte: Re: [exim] How to rewrite From: header of offsite forwards only to prevent Amazon SES 554 error
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