Hector Santos wrote:
If the system says OP=HELO? what does that mean for the
system that does NOT?
Nothig. The idea of OP=something OPtions is to OPt-in to
something, it has by definition no effect for anybody else.
Why should I (receiver) be restricted to applying the rule
to those who have this in their SPF record versus those who
do not?
You're still free to interpret HELO SOFTFAIL or HELO UNKNOWN
in any way you like. If your decision is to reject all mails
in these cases, then you can't claim that the sender told you
so. But if you see an OP=helo then you know that the sender
agrees with your interpretation of HELO SOFTFAIL / UNKNOWN.
That's the idea of OP=helo (formerly known as OP=hector ;-)
how a system performs a validation is defined at the server
side (the receiver), not the sender.
Yes, and v=spf1 does not directly support to have different
interpretations of SPF results depending on the "scope".
It allows to have a separate sender policy for the FQDN used
in HELO, but for some users with a single host name that might
be not good enough. And apparently it's also not good enough
for hotmail.com, and then and only then OP=helo could help.
The sender simply to provide logical information that can
help the server do its job.
And how do you interpret SOFTFAIL or UNKNOWN for HELO ? I'd
interpret it as "bad" and reject, but what I say is _theory_
- I'm no postmaster or MUA implementor at the moment. Often
my theory is good, but not always, as I found out in a very
interesting discussion about "reject instead of over quota
bounces", where I barely escaped the killfile of the pros ;-)
no key person in the IETF-SMTP camp (not event the author
of RFC 2821) has participated in trying to help solve this
issue.
Hm, I simply asked him about his 1*("." subdomain) in RfC 2821,
and he told me that it's no typo: At least one dot, otherwise
it's a syntax error, and to hell with "host" TV or all similar
cases, where a TLD is also a host. Actually it was a polite
answer, and he suggested to allow a dot at the end for this
issue in a future 2821bis.
Bye, Frank