--On 1 July 2010 08:17:54 -0700 Dan_Mitton@??? wrote:
> Isn't it just easier to always do the SRS rewrite, rather then having to
> do a DNS query, wait for the response, check the result...?
It might be easier, but it's not necessarily advisable. SRS exists in order
to avoid downgrading the SPF status of a message. If the message has an SPF
PASS, SRS lets you pass it on without downgrading the status to SOFTFAIL,
NEUTRAL or FAIL. Using SRS without publishing an SPF record of your own
risks downgrading messages from pass to no unknown.
However, if you use SRS for mail that fails SPF tests, or on mail from
domains without SPF records, then you risk upgrading the message to a PASS.
That might be OK, for example if the message had a good DKIM signature in
the same domain, and if you actually trust the original domain. It might
improve the deliverability of a message that you have reason to trust.
But, if the message has a good DKIM signature, then the signature should
survive your forwarding. The recipient host should check both the SPF
status and the DKIM signature. Most mail paths won't break both a DKIM
signature AND SPF. Arguably DKIM is better than SRS in preserving
authentication across hops, so you may consider that SRS isn't necessary if
a message carries a good DKIM signature that you aren't going to break.
>
> Please respond to exim-users@???
> Sent by: exim-users-bounces@???
> To: John Horne <john.horne@???>, exim-users@???
> cc: (bcc: Dan Mitton/YD/RWDOE)
> Subject: Re: [exim] SRS forward
> LSN: Not Relevant - Not Privileged
> User Filed as: Excl/AdminMgmt-14-4/QA:N/A
>
> On 2010-06-30 at 15:31 -0700, Phil Pennock wrote:
>> On 2010-06-30 at 23:03 +0100, John Horne wrote:
>> > On Wed, 2010-06-30 at 14:18 -0700, Phil Pennock wrote:
>> > > On 2010-06-30 at 20:15 +0000, Christian Gregoire wrote:
>> > > > I've written an SRS forward router, which works fine but it always
> rewrites the sender address when I'd expect the rewrite to occur only if
> the incoming domain has an SPF record. Is that possible ?
>> > >
>> > > condition = ${if match{${lookup
> dnsdb{defer_never,txt=$sender_address_domain}}}{\N^v=spf1\s\N}}
>> > >
>> > We have found that occasionally multiple TXT records are present (for
>> > other things than SPF), and so tend to use a multiline regex. In the
>> > above example it would become:
>> >
>> > ...{\N^(?m)v=spf1\s\N}}
>>
>> Good catch, thanks. In addition ...
>
> Actually, you need to have the (?m) come *before* the ^ because it
> changes the meaning of the caret.
>
>> Prior to Exim 4.70, the TXT behaviour of dnsdb was problematic. 4.70
>> and 4.71 have behaviour geared towards DKIM.
>>
>> As of Exim 4.72, this is now tunable. To get the interpretation defined
>> by RFC 4408, where individual text strings within an RR are concat'd
>> together, but keep newline termination between strings, you want:
>>
>> ${lookup dnsdb{>\n; txt=$sender_address_domain}}
>
> At the { exim -be } prompt:
>> ${if match{${lookup dnsdb{>\n;
> defer_never,txt=spftest1.test.globnix.net}}}{\N(?m)^v=spf1\s\N}
> {Yup}{Nope}}
> Yup
>> ${if match{${lookup dnsdb{>\n;
> defer_never,txt=spftest2.test.globnix.net}}}{\N(?m)^v=spf1\s\N}
> {Yup}{Nope}}
> Yup
>> ${if match{${lookup dnsdb{>\n;
> defer_never,txt=spftest3.test.globnix.net}}}{\N(?m)^v=spf1\s\N}
> {Yup}{Nope}}
> Yup
>
> Note that "spftest1" includes non-SPF TXT records and the 2,3 variants
> instead just break the RR up into multiple strings. All publish both
> TXT and SPF record types, but Exim only supports TXT at this time.
>
> -Phil
>
> --
>## List details at http://lists.exim.org/mailman/listinfo/exim-users
>## Exim details at http://www.exim.org/
>## Please use the Wiki with this list - http://wiki.exim.org/
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see
http://www.sussex.ac.uk/its/help/
