Re: Re: HELO versus MAILFROM results

No I do not have a monopoly on intelligence or good practices.

My attitude to software engineering is to not produce vaporware, but if
vaporware is good enough for the market, I have nothing to add here.

I will be taking a few weeks off of this group. This means when I do not
respond to the following posts, it means I did not read it, do not make
the mistake of assuming I agree with it.


Regards to all,
Radu.



Hector Santos wrote:

----- 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 9:44 AM
Subject: Re: [spf-discuss] Re: HELO versus MAILFROM results

If I had log files that contained a meaningful sample size and (IP,
HELO, MAIL FROM, SPAM decision) information, I believe I could prove all
my points, but I do not have such log files.



Beside DNS overhead which is a no-brainer,  what is your point(s)?

That HELO SPF checking shouldn't be a consideration?

These issues were already discussed and I don't believe anyone needs to go
out there way to show you why.  If you havn't figured it out for yourself,
well,  I can't help that.   Nonetheless, I already gave you few example of
transactions to disprove your points.

By the way, I see millions of dollars wasted every day on development
without research, and subsequent redeveloplement and beating a product
until it takes a shape that eventually becomes reasonable. So it is not
only possible, but I have encountered a verified case where spending
"thousands of dollars on R&D" does not mean the people doing the work
know what they're doing. I am talking of a product that you make
extensive use of, and on which you spend hundreds of dollars every year,
but I can't say what it is, because that job pays me a salary.



Thats fine, and you are fortunate to work in a what sounds as a good job,
but that doesn't give you a copyright or patent on intelligence or mature
product engineering.   Putting in the time still counts in my book.

BTW,  our product cost few thousands dollars.  It is not free. It is a
premium product. People pay monthly, quarterly and/or annual maintenance
fees for our product.  They demand quality and support and the engineering
is decades time-tested.   That's what they pay for.  They are not going to
take half-ass thought out product designs or product operations with
perpetual problems.  SPF is just one item implemented among a suite of items
to protect the mail process which is 25-30% of our business.  It works. It
does its part and you can't change that fact with any amount of blabbing you
make.  Proof is in the putting  and we don't need to pull a tooth to
convince you.

Again, this is not rocket science.

The CDN is part of the SMTP process.  It is what it is.  You can't change
that.  The issue of a "how to", "reliability" and "usefulness" may still be
a matter of debate, but to suggest it is not of the picture is just
ludicrous.    The fact is, it can be used for protecting transactions.  It
is not uncommon as you might believe.  Just consider that Dave Crocker is
waging a bet that one day it will be the defacto method for client
authentication and authorization.   It might surprise you that I am on his
side with the idealistic thinking.  But it isn't practical today to just
depend on CDN as well.   You need more.

Again, it seems to me that you think there is "one solution" or maybe "one
universal" method that may work or not.  Don't know what you are saying half
the time.  That is not clear in your posting.   It is like you say, "it is
better if you do it this way," but yet say "it won't work."

My point is very simple. The industry wide empirical data has shown that:

1) 60-80% of the industry transactions are problematic.

2) This includes:

- Non-compliant SMTP clients
- Bad or spoofed Client Domain Names (CDN)
- Bad or spoofed Return Paths (RP)
- Bad Forwarding Paths (FP)

Whether you use SPF or any other LMAP based protocol, they are all part of
the decision making process.

Our specific algorithm is simple:

    if  FP is remote then
        // session must be SMTP authenticated
   else
        // FP is valid local address
        check white/black filter rules
        // Perform DNS based Validation Logics
        check IP
        check CDN and/or RP based on method turned on
        Perform CBV

By our statistics, this delay verification gave us a 65% reduction on the
DNS requirement and usage and it also cut down the session residence time by
300%.

Mind you, the idea of delay verification was not the initial thinking.  As
an Idealist, like you, one might thing you can do all this blindly.  But the
practicality of it was obvious.  The overhead as WAY too high to perform
open ended DNS lookups. Something had to be done.  Luckily,  RFC 2821 does
have written in stone that delay verification is quite possible before
checking MAIL FROM.  See RFC 2821 Section 3.3:

| 3.3 Mail Transactions

    .....

   .............  Despite the apparent
   scope of this requirement, there are circumstances in which the
   acceptability of the reverse-path may not be determined until one or
   more forward-paths (in RCPT commands) can be examined.  In those
   cases, the server MAY reasonably accept the reverse-path (with a 250
   reply) and then report problems after the forward-paths are received
   and examined.  Normally, failures produce 550 or 553 replies.

So our implementation is ON PAR with the insight written in the document.
MAIL FROM (and CDN) checking the "new thing"  so recommendations like this
is very much a major consideration and part of the picture.

----
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)




-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com