spf-discuss
[Top] [All Lists]

Re: the role of the HELO domain

2004-02-24 08:06:04
On Tue, Feb 24, 2004 at 09:28:47AM -0500, Hector Santos wrote:
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.

OK, "partially validate". SPF can be configured to have different policies
per username, though. It still wouldn't differentiate between
userone(_at_)domain(_dot_)com sending mail pretending to be 
usertwo(_at_)domain(_dot_)com, if both
had the same SPF policies.

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.

Sorry if I wasn't clear, what I meant was "I still have not seen a good
argument for why you *should* validate the HELO name for bounces, i.e. what
possible benefit it can give"

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?

I agree it has no value. If I were designing SMTP today, I would drop it
completely. Since in these Internet days we don't trust people, we don't
trust the information they put in the HELO record, and we don't use it for
any delivery purposes[*], so it might as well not be there.

Since we have no foolproof way to validate it, you might as well not
validate it. Just ignore it, and use the reverse IP DNS lookup instead.

Brian.

[*] We may record it to aid debugging, e.g. in the Received: header or mail
logs. As long as people realise this is a cookie provided by the sender, and
the sender can put whatever they like there, then it has some marginal value
when debugging problems to senders we trust. e.g. a host
"mailhost.vanity.com" which dials up to an ISP may legitimately say
      HELO mailhost.vanity.com
even though its reverse IP lookup is ip-pool-1-2-3-4.dynamic.myisp.net

If mailhost.vanity.com is behind a NAT firewall it may well not have any way
to *know* that its IP address visible to the outside world is not what it
thinks it is.