----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, October 04, 2004 8:00 AM
Subject: Re: [spf-discuss] What to include...
1) HELO domain checking clause
------------------------------
I don't know how recently this language was added. Do any
implementation of SPF do this? Do people consider this part of SPF
Classic, or is this an add-in from the Unified SPF work?
I think this belongs better into Unified SPF work and should not be in SPF
Classic draft. For me and others SPF Classic is associated with protecting
Return-Path and while doing EHLO check on postmaster(_at_)EHLO-name is ok when
Return-Path is empty, anything beyond that seems not appropriate to
include
into SPF Classic specification. And I actually have not seen any SPF
Classic
implementation that does EHLO check, but maybe I'm seriously wrong.
Yes, you are. Wildcat! SMTP does client domain checking, including her's
wcSAP "Wildcat! Sender Anthentication Protocol" does internal (called DIP)
and LMAP based HELO checking.
This is another example of the what I call a delusion to believe that you
can be provided a"Unified" Product that will statisfy the needs of design
engineers or implementations putting valuable resources into this effort.
When it comes to today's SMTP Technical Compliancy and Operational
Requirements , HELO checking is not an option. It is a requirement.
SPF classic, unified or whatever, HELO checking is a requirement. This was
all hashed out and established over 1 year ago.
Look, LMAP concepts now yields a negliable ~0.0% of the total rejection
rate.
The #1 defense a system can do in the SMTP world is to add "Compliancy" as
the #1 requirement. Using SMTP compliancy, you canl knock out over 70-95%
of the spoofers which are basically non-compliant transactions, all
indepedent of SPF.
Point?
By not doing what is necessary now (HELO checking), all you doing is
wasting a lot of time and a lot of other people time too.
You simply can't have a SPF1 provision for supports a NULL based return path
HELO check but is contradicted with no provision for a non-NULL return path
HELO check. I hope this doesn't offend anyone, but contradiction is called
a specification loop-hole.
I proposed this as a compromise before. I'll summarize it again:
For SPF1, HELO checking should be allowed when:
a) the MAIL FROM is NULL,
b) the HELO domain is LOCAL (your domains)
c) the MAIL FROM is NOT LOCAL
d) the SPF(MFROM) = NONE, SOFT, NEUTRAL
e) the MAIL FROM is NOT LOCAL and SPF(MFROM) = PASS
Note there is no order defined here. Delayed processing is a major
consideration.
If the MAIL FROM is LOCAL, then they is no need to check for HELO because
local domains are under the control of the local system. It is the best
LMAP protection one can get - local domain spoof protection.
Similar, if the HELO DOMAIN is local, then it is also an easy check to do.
More importantly, what you are dealing with here is Mix Policy Analysis.
HELO checking and MAIL FROM checking can not violate the fundamental LMAP
principles.
A good example is:
SPF(MFROM) = NONE, SOFT, NEUTRAL, PASS
SPF(HELO) = FAIL
This is an IMPOSSIBLE to have. It is an instant reject simply because it
violates LMAP and the Chain of Trust concept.
So if you want to delay HELO checking for SPF2, well, that's your call,
but that won't stop others doing what is required. What it will do is
create a new group or SPF Variations in the market place if you guys don't
begin to get your act together soon.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office