scott at kitterman
Jan 9, 2009, 9:39 AM
Post #28 of 53
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 <vesely [at] tana>
> >> >>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
> >> well...
> >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);
> return (fail);
> 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