RE: HELO Testing

I wrote:
> > > Only the complete name alaia01.alaia.net.  There is no inherent/easy
> > > guarantee in DNS that the domains are owned by the same people as the
> > > parent domain.  (Your MX server should have an SPF record anyway...)

> Seth Goodman wrote:
> > Did you really mean that last statement?  The point of SPF is to list
> > the outgoing MTA's for a given domain, not the reverse.  At a large ISP
> > or hosting service, an MX farm covers tens of thousands or hundreds of
> > thousands of domains.  In general, DNS records for the MX are not under
> > the control of the individual domain owners, so it's not even possible.

I'm not exactly sure what you are asking, so let me try a couple different 
answers.
1. Marc's original question was about HELO checking.  If I get a request 
like "HELO mail1.nekodojo.org ... MAIL FROM: <>" then SPF must check the 
TXT record for "mail1.nekodojo.org" NOT the shorter domain "nekodojo.org". 
(Recent proposals would optionally expand this checking to all HELO, not 
just to MAIL FROM: <> but the concept is the same).
Yes, your mail server needs to have SPF records, for the above case.  If 
you choose not to publish SPF records for the mail server itself, the 
bounces will still get through but the SPF result will be "unknown".  This 
works, as it always has, but there is nothing to prevent others from 
forging messages from 123456(_at_)mail(_dot_)nekodojo(_dot_)org in that case.
2. HELO checking uses the SPF record for the HELO name given, if any exist. 
MAIL FROM checking uses the SPF record for the MAIL FROM name given.  These 
can be different.  I can send mail from gconnor(_at_)nekodojo(_dot_)org and use 
mail1.megapath.net as my outgoing mailer.  nekodojo.org controls the SPF 
info for the domain "nekodojo.org" and my ISP controls the SPF info for 
mail1.megapath.net.  They do not have to be controlled by the same person 
for this to work.  If I don't own any mail servers, I can still publish SPF 
info stating that I trust certain other servers, this works fine.
In other words, the point of HELO checking is to catch "obvious fakes" in 
the HELO name... The server should only identify itself as its right name, 
and if it tries to identify itself as some other name it doesn't own (such 
as spam coming from HELO microsoft.com when it's clearly  not a Microsoft 
server) would be caught by this.  This is independent from the MAIL FROM 
address.  If there is no SPF record for the HELO name, processing continues 
as normal.

--Marc Alaia <marc(_at_)alaia(_dot_)net> wrote:

> I agree.  There needs to be some means of reigning this in.  Maybe this
> is a reason that HELO checking against SPF should not be done.  Yes, HELO
> checking is a valid check (same as receiving domain, same IP, etc.) but
> how about SPF check against HELO may be performed only if the SPF check
> against MAIL FROM is a non-PASS.

Machines with an invalid HELO will already have trouble sending us 
bounces... this will just expand the same protection to all messages coming 
from that server.
The suggestion on the table currently is to only return FAIL in response to 
a HELO check if the name is *definitely forged*.  If the HELO name doesn't 
exist, has no TXT record, or otherwise can't be checked, processing 
continues on to the MAIL FROM.  MAIL FROM is really the heart of SPF... but 
as Hector mentioned, HELO checking might be able to catch some "obvious" 
forgeries with very little loss.
The main point behind HELO checking is that the domain owner should control 
how his domain names are used, just like with normal MAIL FROM checking. 
If my mail server identifies itself as "localhost.localdomain" then 
probably nobody cares... but if my server identifies itself as 
"microsoft.com" then the REAL owner of microsoft.com should be able to 
disallow that usage.  Using a non-spf, or even non-existent name in HELO is 
usually fine (for now) but using a name that clearly belongs to someone 
else means I deserve to get my mail rejected.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>