----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Cc: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Sent: Tuesday, March 08, 2005 2:51 PM
Subject: Re: Site policy vs. HELO
On Tue March 8 2005 11:36, Hector Santos, a.k.a.
<winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:
Over the pass year and a half, we have proved that by increasing the
level
of SMTP compliancy required by senders, you can address an extremely
high
rejection rate with a very low to non-existence false positives. 100%
based on SMTP compliancy.
Perhaps you're not paying attention to the false positives:
Now why would we do that?
This is a premium cost commerical product installed in thousands of sites
world wide. Support and quality operations is a requirement, not an option.
Everyone always checking for operational problems in rejections especially
since there is such a high rejection rate, some can't believe their eyes.
So the early scrunity was expected. By far, whether you wish to believe it
or not, both false positive and negatives are statisticaly nil.
If and when there is a problem, there will always be a report to you and it
is alway explainable.
Guess who is not reporting problems? The spoofers, the spammers, the
malicious transactions which represents 60-80% of all transactions.
You found one false positive against our system. I appreciate the report,
the issue was corrected and.I sincerely hope that you don't use this weight
your views on email authentication effots.
==============================================================
This message was created automatically by mail delivery software (Exim).
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
winserver(_dot_)support(_at_)winserver(_dot_)com
SMTP error from remote mailer after RCPT
TO:<winserver(_dot_)support(_at_)winserver(_dot_)com>:
host mail.winserver.com [208.247.131.9]: 550 Return Path not
verifiable.
------ This is a copy of the message, including all the headers. ------
Return-path: <blilly(_at_)erols(_dot_)com>
===============================================================
Now consider for a moment how silly that transaction was:
o Everything from the client side was 100% SMTP compliant
So you say. For the transaction we did not have any proof of the sender
authorization take place. You and I know you are compliant because you sent
mail to us before and you pass the SMTP compliancy test. In this case, I
was a fault in our sub-process here. It was a legitmate bug that needs to be
corrected. It didn't even get a chance to run. First time that happen. So
again I appreciate the input.
o The return code claiming "Return Path not verifiable" had the
predictable result of sending a notice (excerpts above) to
precisely that path which is (incorrectly) claimed to be
"not verifiable"
And you reported the issue. Exactly what we would expected if and when we
do get false positives which is a very low occurance. Trust me, our
customers will report problems. Got me today saying his user was getting
rejected. After seeing his logs, he was running into the SPF forwarding
problem and the problem was solved using a white list. Simple, Done,
Customer happy!
You have shown nothing thus far.
Most modern SMTP systems are compliant and legitimate senders are indeed
compliant.
As the case above...
Exactly. You are legit, thus you will report it as most will in practice,
exactly what I said will happen.
Somebody needs to pay more attention to unwarranted rejection
of legitimate mail.
Someone did - YOU!!
I predict that the courtesy copy of this message will also
bounce for no good reason.
Bruce, what is your problem? If you have some true input here, just
provide it and quit the nonsense?
We are not just doing this to be a nuisance. Using SMTP compliancy works,
plain and simple, and most will see this immediately when they put it into
practice. We have the proof. It is not just talk.
Will they exist false positives? I wouldn't expect there not be. But what
makes this incredibly successful is that it indeed works with a very low
false positive rate and nearly always when there is a problem, it is always
reported. There is always a reason for a false positive and a BUG doesn't
count. And just in case you have more nonsense, this pre-release is only in
the hands of a few field testers. Whatever happen, I don't know. I have not
checked yet. But it was not an expected situation and it is completely
unrelated to the protocol. What I will be checking is why there wasn't a
temporary 45x response code instead.
Finally, the SMTP compliancy is simple:
HELO/EHLO
1) Check for syntax compliance
2) Check for Domain Literal IP match
3) Check for local domain spoofs
All optional. No DNS overhead. Provides high rejection rates. By far,
little to no false positives. The false positives that did occur in the
early stages were:
- Indicative of a poor client setup
- Broken legacy software, which were updated or replaced.
MAIL FROM:
1) Check for syntax compliance
2) Per 2821, delay validation until Forwarding path is known.
Currently, only anonymous local final destination transactions are checked.
Remote transactions require a standard SMTP level authentication process,
either with SMTP AUTH, POPB4SMTP or Allow IP tables. No need for Mail From
Validations if the sender is authenticated.
Our main validation is based on a CBV. Very few false positives. I'm sure
there are zombies sites but its rare and are quickly picked up when you
analyze why you got a spam!
The point in all this is that are many systems that do nothing at SMTP and
this is the heart of the spoofing/spam problem. Using some simple SMTP
compliancy checking will go a long way. I am sure you don't believe that,
but its true based on real production experience.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office