Hi,
The sample SPF informational message from doc/experimental-spec.txt is not
completely correct. Usually $sender_address_domain applies, but when
$sender_address is null, SPF ressorts to $sender_helo_name for verification.
If the latter is used and test fails, we get to reply something like:
"1.2.3.4 is not allowed to send mail from "
Attached patch adds the necessary checks so that message ends with
$sender_helo_name when this happens.
While I was at it, I also improved the message a bit with a link to the
dynamical
http://www.openspf.org/Why page with appropiate parameters.
--
Robert Millan
My spam trap is honeypot@???. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
diff -ur exim-4.67.old/doc/experimental-spec.txt exim-4.67/doc/experimental-spec.txt
--- exim-4.67.old/doc/experimental-spec.txt 2007-06-24 23:46:03.000000000 +0200
+++ exim-4.67/doc/experimental-spec.txt 2007-06-24 23:51:35.000000000 +0200
@@ -610,11 +610,12 @@
strings matches the outcome of the SPF check, the condition
fails.
-Here is a simple example to fail forgery attempts from domains
-that publish SPF records:
+Here is an example to fail forgery attempts from domains that
+publish SPF records:
/* -----------------
-deny message = $sender_host_address is not allowed to send mail from $sender_address_domain
+deny message = $sender_host_address is not allowed to send mail from ${if def:sender_address_domain {$sender_address_domain}{$sender_helo_name}}. \
+ Please see http://www.openspf.org/Why?scope=${if def:sender_address_domain {mfrom}{helo}};identity=${if def:sender_address_domain {$sender_address}{$sender_helo_name}};ip=$sender_host_address
spf = fail
--------------------- */
