James Couzens wrote:
When a HELO check fails, the session fails. This is great if
"you MUST perform HELO evaluations", and everyone does it but
we both know that so many clients out there don't even do
HELO, or pass it forged/useless information.
So far I fail to see a problem with this optional check. Any
useless "HELO oemcomputer" or similar crap results in "error",
not FAIL. And a forged "HELO xyzzy.claranet.de" deserves to
FAIL, because no MTA in the world is authorized to use it.
SPF clients MUST check the "HELO" identity by calling the
check_host() function (Section 4The check_host() Function)
That's an interesting idea, but not an optional test. Adding
a "MUST check HELO" to v=spf1 implementations is (in theory)
allowed, because for existing v=spf1 policies it's nothing new.
If the HELO test returns a "pass", the overall result for
the SMTP session is "pass", and there is no need to test the
"MAIL FROM" identity.
No, that's not what Meng proposed (= what I have as op=trusted)
Bypassing all further tests after a HELO PASS works only with
local white lists of trusted forwarders. See chapter 6.3.2 in
the op=trusted proposal with further restrictions:
<http://purl.net/xyzzy/home/test/draft-spf-6-3-options-02.txt>
If the HELO test returns a "fail", the client may continue
with checking the "MAIL FROM" in search of a better result,
And that's not Hector's idea for a HELO FAIL (6.3.1 op=helo).
HELO FAIL => reject all, compatible with v=spf1, even without
any op=helo constructs.
The op=helo is relevant for William's "helo scope" in v=spf1,
where we don't have scopes. With op=helo (or op=trusted) it's
possible tor treat HELO UNKNOWN resp. HELO SOFTFAIL like FAIL,
i.e. reject all mails.
The idea behind this was that an MTA really does know who he
is, and a postmaster does have the clue to get a PASS for his
HELO (or be damned until he fixes it ;-)
I'll answer the other issues where you have some differences
separately, otherwise it's too confusing.
Bye, Frank