Premises (fictional names)
foo
is an external domain, of which the MTA is out of my control;foo
has SPF setup such thatmine
servers cannot send email as@foo
;bar
is another external domain, of which the MTA is also out of my control;bar
does SPF checking on incoming mails to reject explicit fails (RFC recommendation and common practice);mine
is a local domain, of which MTA is the exim I'm configuring, it's been working for several years, but only now we noticed a misbehaviour;List
is a mailing list of whichBob
is a member (note: effectively this could also be a "forwarding address", but it's simpler to think of it with lists);list@mine
members are stored on a mysql database that is managed elsewhere (which means it's not a static list);Alice
wants to send an email toList
.
What I need
Short version
How to configure (without recompiling) exim so Alice
can send an email to List
which would be redirected to Bob
.
Long version
This configuration has been working for several years for the cases where either the sender was @mine
or all the receivers were @mine
. With a configuration like this:
open_lists:
driver = redirect
data = ${lookup mysql{...}}}
forbid_pipe
forbid_file
no_more
What doesn't work: the case where both sender and receiver are externals.
Why: for some reason (this is the misbehaviour I was talking about) exim preserves the original envelope sender (aka MAIL FROM per the RFC), which bar
rejects due to an SPF fail.
I'm aware of SRS and its experimental implementation on exim.
However besides being experimental it requires recompilation to be enabled. It wouldn't be terrible if there was an updated ubuntu ppa with compiled packages ready, though I haven't found one.
I'm also aware of exim's rewriting which has a flag F
to change the envelope sender (From), but that flag can't be used with headers_rewrite
. It's only available on the rewrite section.
Basically I'm looking for a way to fix the envelope sender which is expected to be list@mine
in this case, be it through rewriting or SRS, it must only be maintainable.
No comments:
Post a Comment