Greg Connor [gconnor(_at_)nekodojo(_dot_)org] wrote:
On Wed, 5 Jan 2005, Julian Mehnle wrote:
Ok, so why exactly don't you want to require HELO checking?
Hmmm, let me think about that. What I really want is for as many
people to do HELO checking as possible, and to make it as easy as
possible. I guess the reason I don't want to make it 'required' or a
'dependency' is that I'm anticipating there might be a backlash from
the greybeards at ietf or other fundamentalists.
I suspected this was your only reason. Maybe we can ask those
conservative greybeards the same question if they start arguing: "so why
exactly don't you want to require HELO checking?" :-)
Perhaps we can state it as "SHOULD check HELO using SPF" - it makes the
recommendation pretty clear but leaves the door open to those who can't
check HELO or won't. Something that causes software vendors to do the
right thing (such as shipping with the HELO check defaulted to ON) but
doesn't cause objections from the peanut gallery would be ideal.
I could live well with the semantics of "SHOULD check HELO using SPF".
We can also make some statements about nonexistent names, such as
"Receivers may decide to implement a local policy, such as requiring
helo names to be fully qualified and resolve to an A or MX record, but
such receiver policies are beyond the scope of this document"
Like, "receivers may do [something], but neither can we tell nor do we
care, because receivers can always just do what they want anyway"? No,
that's too nihilistic and doesn't help with the problem that the current
SPF spec has no clear position on the HELO checking issue.
Here's another idea, what about using a HELO PASS result to override a
"require reverse DNS" policy?
I understand the point of that, but overriding a "require reverse DNS"
policy _really_ is beyond the scope of the SPF spec. :-) The point of
HELO checking would be, like MAIL FROM checking, to prevent forgery of the
used identity. I would like to include that in the SPF spec as a clear
recommendation (SHOULD), or better, equal to MAIL FROM checking, a clear
obligation (MUST).
Had I been asked about my position a few years ago, I would have answered
that requiring a valid HELO (for whatever definition of "valid") were
impractical because RFC 821 did not strictly require HELO to be valid.
But now we don't have to be concerned of breaking old software because RFC
2821 already did that for us when it became an Internet Standard.