----- Original Message -----
From: "Radu Hociung" <radu(_dot_)spf(_at_)ohmi(_dot_)org>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, May 06, 2005 10:53 PM
Subject: [spf-discuss] Re: HELO versus MAILFROM results
There are really several reasons why I oppose HELO checking with
SPF. Here they are, in order of importance, as I perceive it:
1. Checking HELO is unreliable, and may cause more mail bounced.
Nonsense. What this suggest that ALL mail is deliverable. It is complete
nonsense. It there is a problem with a system, most, if not all, prudent
operations will quickly resolve the problem by correcting their system.
Most legitimate systems are NOT going to run a non-compliant server.
Please stop with the rtherotic.
It is the SPAMMER that will not correct. Hence, ample information to track
them.
2. There is a another good abuse opportunity by spammers. Say
that in order to bypass the HELO SPF check, they hardcode the
hostname of an innocent small domain that needs wildcards into
their spam engines. Then they use that domain's wildcard for a
supply of HELOs. Since each such software probably sends
billions of emails during its lifetime, the cost to the
innocent domain would be a lot. This can constitute DOS.
And a DOS can be detect. Again more nonsense. You can't simple use Bad
Random domains and assume, a simple will not be able to track it.
3. The mechanism of MUA submission via port 25 has not been
studied enough.
Oh brother. Now you are getting ridiculous. Do you honestly believe SMTP
developers were born yesterday?
4. Checking HELO only gives you the warm fuzzy feeling that your
a little safer from forgeries. As I have shown, the HELO domain
word has almost nothing to do with the rest of the message, and
it is inconsequential. I believe I showed this quite clearly,
but I can try other ways if necessary.
You have not shown anything worth believing.
5. Checking HELO has the potentially to double the overall DNS
load that SPF adds to the Internet.
Not if you do delay verification. Again, more hogwash.
Perhaps this is why I seem to be jumping around, because there
are several issues that worry me at the same time.
I wonder why you are the only one that sees a "problem."
This is not rocket science. You have 5 state points:
IP IP address
CDN Client Doman
RP Return Path
FP Forwarding Path
PL Payload
If you wish to implement a system that ignore the FP, then you have violated
the basic and most fundamental aspect of SMTP which deals with Anonymous
Destination Mail.
If the FP is REMOTE, then the transaction must be authenticated - PERIOD
using transaction means. It means no sense what so ever to endure overhead
on a system by blinding checking the CDN or RP when you don't even know of
the mail is deliverable in the first place. Its ludicrous.
If the CDN is syntaxically out the door - you kill it.
if the CDN is checked against SPF and it fails - you kill it.
If the CDN is checked against SPF and its NXDOMAIN or NONE, you need to do
more checking.
What so hard to understand?
A Spammer attack?? So what? That can happen WITH or WITHOUT SPF!
Yes, the additional DNS overhead is an ISSUE. So I don't understand why you
say "it doesn't concern you." We reduce it using delay verification. The
FP fails, No need to check anything else. If the FP is remote, then we
don't need SPF. We already have other authenticaton/authorizing schems for
routing.
But for anonymous destination, CDN checking is required to complete the
spectrum. You simply can't ignore it.
Now, others might suggest that SPF checking is requires for routing as well.
Well, we are now looking at this too, to address compromised authorized
users. But I don't see this as a problem. An affected user can cause a
problem, but it is detectable and he can be quickly eliminated.
It seems to me, you are trying to put your ideas into SPF but you have yet
to prove why SPF is broken, besides the obvious issues. What irks me is
that you make all this sound like there has been absolutely no leg work,
never mind the thousands of dollars in R&D and product development into any
of this and we are all just half-twisted brains around here that don't know
what we are talking about. You seem like a smart fellow, but geez, size
the foot and mouth!
SPF is not the only solution and MOST systems are not going to just use SPF.
Get it?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com