On Thursday 08 January 2009 13:17, Don Lee wrote:
On Thursday 08 January 2009 09:42, Alessandro Vesely wrote:
Scott Kitterman wrote:
On Thu, 08 Jan 2009 13:46:54 +0100 Alessandro Vesely
Perhaps SPF on HELO would have been more effective if servers checked
the name resulting from rDNS.
SPF only does what it does and isn't a panacea.
Yup, it blocks senders, not hosts. Possibly, someone on this list
recalls how come RFC 4408 recommends checking the HELO identity as
It started out as a fallback for what to do for null sender (Mail From <>)
messages, but proved to have general utility.
OK. Maybe this is not quite baked yet.
What is the precise algorithm for checking SPF on HELO?
It seems to me that the HELO name is required to determine what domain
is taking responsibility for the mail being sent.
(Pardon the pseudo-code)
sender_IP /* actual IP of connecting MTA */
sender_HELO /* HELO offered by conneting MTA */
sender_HELO_IP /* IP of sender according to lookup of HELO name (unused?)
*/ sender_SPF_IP_list /* Listed IP addresses for HELO name, per SPF recs */
if (sender_HELO_IP != valid_A_rec) return(fail);
Note: This is outside the scope of SPF, but yes. I'd check this first, but
I'm not sure I understand your notation. What I was trying to say is lookup
any A records associated with sender_HELO. If there are none or none of them
(which I think is sender_HELO_IP ) are sender_IP then return(fail).
if (SPF(sender_HELO) == none) return(none);
If you're going to do rDNS checks, then that'd come before return(none).
if (sender_IP is_contained_in_list( sender_SPF_IP_list)) return (pass);
Note that the sender_HELO_IP is not used. One could also check to see that
sender_IP and sender_HELO_IP are the same. (they should be, but...)
I think that is what one checks if I'm understanding you.
Note also that the FUD surrounding -all ?all ~all is not relevant
here. If the IP being used to send mail from the SPF listed domain is
not explicitly listed, the check fails.
Would this algorithm be sufficient?
The idea is that an MTA that gets a <fail> would have all its mail
rejected. I currently do this, with no problems, but I do it "by hand".
I have a question from someone this morning about doing this. He says
The problem is there are *almost zero* SPF records published for HELO
names. To be effective, there should be one record for every outgoing
Border MTA, and the record should end in -all. How do we motivate
senders to do this?
This brings up another point that needs to be resolved: is there any
difference between SPF records "for HELO checking" and "for MAIL FROM"
checking? I think not. (I will invite this gentleman to join this mail list
We don't 'make' senders do anything, of course. It's been a while since I
looked for it, but IIRC it has at times (and may be now - I'm too lazy to
look) common for spammers to forge the same domain in Mail From and HELO.
So if you take a domain that has an SPF record that ends in ?all or ~all, like
(for example) hotmail.com (I pick this because I recall this one being common
when I looked a while ago) a forged use of hotmail.com in Mail From and HELO
gets a Softfail result. For Mail From, you really can't (shouldn't) take a
definitive action during the SMTP transaction. The best you can do is tag it
as Softfail and let that go into the mix of factors used in your post-SMTP
filtering. HELO is a different story. You can, quite safely, take that same
Softfail and reject based on HELO not being Pass/None. So even if no one
explicitly published a record for HELO there are cases where it's a win.
I also run the SPF project's email test reflector (See 'E-mail based record
testers' in http://www.openspf.org/Tools ). I have a simple script I
sometimes run against my mail logs to see how people are doing. It's a very
simple script, so it doesn't check to see if there are multiple identical
results (and there always are - I don't know why people do the same check
over and over, but they do) so with an appropriate grain of salt here's the
most recent one day results:
Total tests sent - 89
Mail From Pass - 34
Mail From None - 39
Mail From Fail - 6
Mail From Softfail - 4
Mail From Neutral - 3
Mail From Temperror - 0
Mail From Permerror - 3
HELO Pass - 12
HELO Fail - 4
HELO None - 71
HELO Softfail - 1
HELO Neutral - 0
HELO Temperror - 0
HELO Permerror - 1
This is consistent with my general experience, fewer people publish records
for HELO than Mail From, but it's not "almost zero".
My bottom line is that I agree HELO checking and SPF could use more attention
and evangelism, but it's a lot cost, low risk easy win. Even if it doesn't
help a lot, it doesn't hurt a bit, so just do it.
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com