Re: Re: What to include...

I personally don't use the word "loophole" to describe "lack of a feature". 
Quite simply, it is NOT a loophole, because a PASS in a HELO check does not 
trump a normal SPF check, and in fact a PASS in the HELO category doesn't 
buy you anything.  We should only do the HELO check to check for FAIL.
As I have said before, I strongly agree with Hector that the check is 
needed.  However, I AGAIN DISAGREE STRONGLY with Hector's choice of a 
derogatory, emotionally loaded word like "loophole" to describe the lack of 
a feature he wants that didn't happen to be in the spec.  PLEASE STOP 
DESCRIBING THIS FEATURE REQUEST IN DEROGATORY TERMS.  This is the SPF 
community's main list, so many people on this list are going to get angry 
and defensive if you INSIST that lack of what you want is a FAILURE.
The initial "loophole" in SPF was MAIL FROM: <> - and this loophole was 
closed by HELO check on null return address.  Asking SPF to stretch further 
and provide 2 checks in 1 for non-null cases is quite a reasonable request, 
but please remember that it is a feature request and not a defect report. 
The old version of the spec is not defective for failing to predict needs 
outside the initial scope.  You will catch more flies with honey than 
vinegar.  I suggest stating simply what you want and why you want it, and 
not trying to convince people that the old spec was flawed and stupid.

Lest I be misunderstood, I will say again: I DO support having HELO checks 
in there and available so that receivers may use them.  This affords some 
slight protection for people who don't want their name used in any part of 
the transaction or appearing anywhere in a Received line.
SPF is well-suited for this type of check, and I want HELO checking to 
start getting more prominence and usefulness.  But, I should also point out 
that SPF is not actually the best tool for the job if all you want is local 
HELO checking.  As Hector pointed out many times before, this HELO checking 
is most crucial when checking to make sure other senders don't use your own 
domain in HELO to send mail to you.  So for example if I send mail to 
hector(_at_)winserver(_dot_)com I had better not say "HELO winserver.com".  For this 
to work effectively the receiver must also be a publisher and his domain 
must include a -all.


--Hector Santos <winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:

> But it can't be ignored.  Meng can't go on the promotion tour to talk
> about SPF implementation and when people begin to added it and still see
> 12% of the above like messages getting in, what do you think is going to
> happen?

Several sites already provide recipes for postfix and other servers to 
screen out people trying to spoof the local (destination) domain.  Let's 
agree that checking is a good thing and try to politely disagree as to 
whether it is a defect.  If you still consider it a "defect" that's fine, 
just let's move on.
If we were to rephrase this as a positive feature we would have something 
like,
"This would be an extra win for any kind of promotion tour.  Relatively few 
sites check HELO names because it is not a default part of their 
mailserver.  We have documented evidence that an additional 12% of your 
unwanted email can be screened out, totally safely, if you manage to 
complete all three implementation steps:
 1. Publish your SPF record. Make sure it ends in -all, at least for 
localuser "postmaster"
 2. Also check SPF.
 3. Turn on the optional Helo-Check-All-Messages feature.

See, that wasn't so hard... you can promote a positive agenda without 
having to prove that the old spec was defective and wrong.  We have support 
for "MAY check helo" so let's move ahead with that.  When people see how 
well it works they will naturally want to turn it on.  The SPF community 
benefits by more people publishing AND checking, more people deciding to 
use -all, and more success stories about how forged/crap messages were 
reduced by xx%.

> So whether is it added or not inherently into the SPF1 spec, it is 100%
> prudent to make it a provision in the documentation so that implementors
> are aware of this.

Here we are 100% agreed.


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>