Hi guys,
Ignoring the political arguments of the usage of SPF and SRS (please),
and just talking about the implementation of it, I have the following
setup:
My mail system supports mail forwarding to remote addresses. When
forwarding mail, the receiving server might incorrectly apply SPF
filtering on the email and reject it. Discounting the times when I can
contact the receiving server and get them to fix their config, I decided
to use SRS. As far as I can see however, there is no point rewriting the
sender address, if the sender address domain doesn't even have an SPF
record in the first place.
Inside the transport that is used for forwarding mail to remote servers, I have:
1.) return_path = \
2.) ${if and{{match{$return_path}{\N^(.+)@(.+)$\N}}\
3.) {match{${lookup dnsdb{defer_never,txt=$sender_address_domain}}}{spf}}\
4.) }\
5.) {${lookup mysql{SQL_SRS_ENCODE}{$value}{$return_path}}}\
6.) {$return_path}\
7.) }
Description:
1.) This rewrites the envelope sender
2.) Don't rewrite mail with a null sender
3.) Don't rewrite unless a dns txt record lookup on the sender address
domain has 'spf' in it
5.) Calls a mysql stored function that generates an srs encoded sender
address to rewrite to. Defaults to $return_path on failure
6.) Default to $return_path if the condition failed
Ideally, I'd change line 3 to do an actual spf lookup using the IP I'm
intending to send the mail from, then rewrite on fail/softfail/unknown.
I've not done this yet as doing an spf lookup is expensive (calling an
external script: spfquery) as I'm not using the inbuilt SPF/SRS
functionality until it's out of experimental.
My questions are:
1.) Is the above logic and the configuration sane? No politics please :)
2.) When can I expect the SPF/SRS support in exim to come out of
experimental?
Thanks for your time.
Mike
