----- 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: Saturday, May 07, 2005 1:51 PM
Subject: Re: [spf-discuss] Re: HELO versus MAILFROM results
For myself, I really do not understand what changes you are proposing.
Yes, SPF is not a silver bullet to fix e-mail. I doubt that anyone who
is actually working with it believes that it is. But if you believe that
it needs to be changed it is up to you to explain your changes and prove
that they are an improvement over what we are already doing.
I will not be offering such proof.
Usually the burden of proof of validity of assertions is the duty of the
proponents and supporters of those assertions.
But the assertions of LMAP have already been made and proven in the industry
as a worthy technology to pursue for the given email framework.
DMP proves CDN and RP checking does work using a simplistic syntax. RMX
proved you can expose a "network" of machines with a small data footprint.
SPF proved that you can merged the two and it was the one that people has
followed to the extent that the largest gorillas use it and even cloned it
and friviously patented it. That does not normally happen unless it did
have some "merit."
You are trying to prove it has no merit (I think), but the only reason, it
can have any problem can be only 100% related to overhead issues which
everyone acknowledges as a potential issue.
But I always felt that overhead can be addressed (like we did) and as SPF
evolved, it might turn out to be client driven first where the CLIENT gets
permission to send mail rather than put the burden on the server to
authenticate and authorize the CLIENT. But that is the future (and in my
book, the ulitmate direction). This won't take place until SMTP changes
itself to enforce the level of transaction support.
I was hoping that Hector would take chance to show to his customers,
some of whom may be reading this thread now or in the future, that he
has thoroughly researched the assumptions he makes in the software he
sells.
FWIW, our system was in R&D and field testing for atleast 7-8 months on over
150 customer sites before it was officially released for our customers to
upgrade. It was ethusiastically received and blessed by the customers who
have little to no spoofing problem. The logic in our system framework is
well documented at our web site. Again, SPF is just 1 small part.
I wouldn't have picked on him had he not strongly suggested that
I would have a foot-in-mouth problem (which is language that is not
appreciated, by the way).
I will take the opportunity now to apologize for that comment. It is not my
style. I am not a conspiracy type also, yet, I can't help to think there is
an agenda with you here that is going to just waste everyone's time.
I'm sorry to say, but the issue of HELO checking is subtle, and complex
at the same time, so if you do not understand why I am proposing to keep
functionality the way it is currently, I can't shrink it down more than
I have. Perhaps someone else who understands the issue will enlighten
you more than I can.
It has already been told to you. If you wish to pick and read what you
choose, that's a different story.
As I said from my very first message to you. There is a philosophical
conflict between Administrator and Developer disciplines. This is not new.
It was what brought down Fidonet. You can clearly see it in the IETF to the
point where it has reduced it effectiveness in recent years. What was
admirable about Meng, is that he took the bull by the horn and went with it
and got it to the point where it was easy enough to explore to get a proof
of concept. That has achieved without a doubt and if you can not see this,
then really, I don't know what else to say that will not offend you.
From my standpoint, HELO checking is a requirement if you going to implement
some LMAP method into your system. You can just ignore it and based it on
MFROM only. It doesn't make sense to have a common transaction where HELO
is spoofed and MFROM is SPF validated.
IP: 1.2.3.4
HELO mail.santronics.com
MAIL FROM valid-spf-email.com
It simply does not MAKE sense to perform a MFROM check only when the FACTS
have shown there could be a SPOOF processing taking place at HELO.
The COMPROMISE that I always said, to avoid the open-ending checking of ALL
addresses, was to a) make it optional and b) at the very least, check for
local domains. In our system, you can define a list of domains you wish to
check at the helo or you can make it an open-ended check.
SPF is about a new way of thinking for administrators and developers. It
has open the door to the other possibilities, working together or
separately, but as a whole to assist in the decision making process with an
optimal goal of zero percent false positives and negatives.
Rest assured, if the false positives/negatives was problematic, it would
never be implemented.
Finally, keep in mind that an SMTP system MUST be backward compatibile. So
you must take into account NON-SPF systems.
----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)