--On 1 July 2010 08:17:54 -0700 [email protected] 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 [email protected] > Sent by: [email protected] > To: John Horne <[email protected]>, [email protected] > 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/ -- ## 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/
