spf-discuss
[Top] [All Lists]

Re: Re: What to include...

2004-10-06 03:13:32
Greg Connor wrote:

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.

I agree a 100%.

IANAL, but this would be my definition of a "loophole" (with regard to
computers):

"A hidden/unexpected means to evade compliance, especially related to
security, for the purpose of gaining access to functionality you would not
normally have, or are expected/supposed to have."

To stick with the alleged 'loophole' of the OT:

    IP: some non-winserver.com IP
    HELO winserver.com
    MAIL FROM:  user(_at_)some-non-spf-domain(_dot_)com

If the mere utterance of "HELO winserver.com" would cause the
non-winserver.com client to gain sudden, unexpected, access to the
winserver.com system, like relay-access, for instance, then, and ONLY then,
would there be a loophole. It would also make his' the most misconfigured
system on the planet.

There is no way, whatsoever, that "HELO winserver.com" will cause to produce
an SPF "PASS", where "FAIL" was called for. Hence, there is no loophole.

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.

I agree. "LOOPHOLE" is a term meant to trigger a scare-response in
unsuspecting people, new to the game, naturally sensitive to hearing there
are alleged security breaches in the software they just embraced. Whereas in
reality no such breach exists.

Lest I be misunderstood, I will say again: I DO support having HELO
checks in there and available so that receivers may use them.

I do, too. In fact, there are a number of HELO checks I already perform. To
name a few: I check for non-FQDN; I check against reputation services; I use
HELO as host name, in case the client IP does not resolve (and the A lookup
of HELO matches the IP address, of course). And I reserve a special hot spot
for those HELO names claiming to originate from class 'w' ($=w), but are not
really me. All of these checks are fascinating, but the absence of any of
them does not constitute a loophole.

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.

Here we are 80% agreed. :) The reason HELO checks, in the general SMTP
dialogue, are either absent or lax, is because no harm can be done with an
alleged spoof, really. Implementors are already aware of that. Now, as I
said, interesting things can be done with HELO, and, as far as I'm
concerned, we should certainly continue to explore those; but not under the
misnomer "loophole".

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx


<Prev in Thread] Current Thread [Next in Thread>