Hector Santos wrote:
You need HELO checking. You defeats the purpose. Now, this
can be done independently of SPF1, but it is needed because
it is a LOOPHOLE otherwise.
As you say, it's independent of v=spf1, and your elaborated
procedures were not part of v=spf1. The "optional" clauses
in v=spf1 don't cover all of your ideas.
If I got this right you're not talking about a dedicated MX
implementig v=spf1, but about a mailer acting as MSA on one
side (to its local users), and as MX on the other side.
So if one of your local users says HELO OEMcomputer you're
prepared to ignore this as nonsense, but if a Spamcast box
says HELO OEMcomputer you can reject it without further ado.
And you certainly won't try to get the SPF sender policy of
a "host" OEMcomputer. The host tv is funny, fortunately it
has no sender policy, yet ;-)
That's all very interesting, but it's not exactly a part of
v=spf1. Your ideas could be documented separately in a new
spf2.0/helo or a similar text, simply copying the "optional"
v=spf1 part isn't good enough.
Most of us agreed on Mark's proposal "no new features" for
draft-mengwong-spf-02, with the exception of the new DNS RR
justifying an experimental status.
Please put everything else into spf2.0. Please don't delay
the v=spf1 update now by new features. As you said it's
independent of v=spf1, let's discuss it now for spf2.0. My
first question: Where do you see a "loophole" in v=spf1 ?
Do you have an example where a MAIL FROM test results in PASS,
but shouldn't, or is it about a FAIL, or where is this v=spf1
"loophole" ?
Bye, Frank