----- Original Message -----
From: "Brian Candler" <B(_dot_)Candler(_at_)pobox(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, February 24, 2004 4:49 AM
Subject: Re: [spf-discuss] the role of the HELO domain
On Mon, Feb 23, 2004 at 11:53:19PM -0500, Hector Santos wrote:
Meng, I think this will have a negative impact on SPF. You should
address
it. Sort of defeats the purpose. The whole point of SPF is to
validate
sender machines.
No, the whole point of SPF is to validate envelope-sender addresses.
Period.
Well, we will then have to agree on this disagreement. There is nothing in
SPF to validate the "address." It validates the domain part of the return
path, not the complete return path. i.e,
gooduser(_at_)domain(_dot_)com
baduser(_at_)domain(_dot_)com
SPF validate "domain.com" regardless of whether the "address" is good or
bad.
On bounces, there is nothing to validate with SPF. I still have not seen a
good argument for why the HELO name should be validated in this case.
Sure there is. A NULL return address is the only provision where the client
HELO/EHLO domain name is validated by SPF. This is confirmed by Meng.
The enforcement of client machine domain and client IP is
one of them, in fact I consider it more important than the MAIL FROM.
And what about things like doing a reverse lookup on the client IP
address,
then a forward lookup on the name, to see they match? That's another way
of
validating the client connection. But it's not part of SPF.
Sure. We all know that answer.
That's not the problem - but like you said, its not part of the SPF
specification, hence a loophole.
If HELO/EHLO is not important, then why have it in there as a NULL address
fallback check? What's the point then if you believe it has no value?
If there is one fundamental requirement in LMAP based proposals - its that
the HELO/EHLO domain name must match the client IP address.
LMAP guideline
2.1 What is meant by "forgery"?
In the context of LMAP, "forgery" is defined as:
Forgery: Use of a domain name in the argument field of SMTP
EHLO/HELO, and/or SMTP MAIL FROM, by an SMTP client, without the
knowledge or consent of that domain.
If SPF does not include this, it can not be called a LMAP based proposal.
I'm not sure if that labeling is required or even desired. But the
argument that "Most MTA" will do the HELO/EHLO check and therefore there is
no need for SPF to do it, well, in my opinion makes the functional
specification weak and falls in the same category of falls that was present
with the SMTP specifications.
You also need to keep in mind that MTA validation MAY to be delayed until
the RCPT TO state point per RFC 2821 to determine if the transaction an
error or system notification message to postmaster or abuse.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com