----- Original Message -----
From: "Rolf E. Sonneveld" <r(_dot_)e(_dot_)sonneveld(_at_)sonnection(_dot_)nl>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, March 13, 2004 4:05 PM
Subject: Re: [spf-discuss] Latest proposal re HELO checking: make HELO tests
optional
Dear mr. Santos,
[...]
In my technical view, an anti-probing logic should be for multiple RCPT,
not
on the first RCPT and fortunately, the majority of responsible mail
systems
don't operate that way. It would kill the system. Look at this way, RFC
2821 says you must accept the local message anyway (for null return
paths),
so what's the point of delaying it? All you are doing is hurting
innocent
victims.
Who is talking of deliberately delaying the response? My mailhost
receives up to 500 messages a day without any problem and all these
sending systems seem to be able to reach my system and deliver the mail.
Furthermore, I send literally thousands of messages per year to remote
SMTP systems and they are received properly. I can show you the logs.
Oh I believe you, but speaking of reality checks:
1) Who was trying to send mail to whom? Me to you? or You to me?
If I was trying to send mail to you, then our normal SMTP process takes over
with the 5 minute delays etc. However, all delays are recorded for
analysis.
2) In the new Anti-Spam era
Where is your SPF record? If you have not added one at this point, then
that speak volumes about your attitude and I am probably making a major
mistake even discussing anything with you.
The reality is, the CBV, believe in them or not, are real. They exist and
they will continue to exist and grow.
So who is going to have more problems out there in the new era? You or me?
What make you think that MY system is delaying your CBV? You know
perfectly well that ANY IP system between your system and my system may
be responsible for this delay. It may be your firewall, it may be your
ISP, it may be my ISP, it may be my firewall etc. Given the facts about
traffic mentioned above, I'm confident that my system is not the problem.
I checked it manually. Whatever you are doing, it is only the RCPT
response is about 1 minute. Not other TCP traffic is delayed. Hence, it is
your application. Sounds like you have a DNS problem on your end or
whatever your software is doing with RCPT.
Finally, of course, the whole point of adding LMAP to CBV systems is to
avoid the CBV as much as possible. So he could of simply added an SPF
record and it would of been a none issue. The point is, the CBV is the
ultimate test to satisfy that return path is valid, and in our design,
SMTP
COMPLIANCY is a must, those that fail to comply, will not get in. Its as
simple as that.
My system is compliant with SMTP from day 1 (PMDF has been around for as
long as 1985 or so) and a number of great names has written it (Ned
Freed, co-author of MIME is one of them). Look at the number of RFC's
Innosoft International Inc., vendor of PMDF, has contributed to and
don't tell me that my system is not SMTP compliant.
Reread what I said. The design of the new anti-spam systems require SMTP
compliancy. The new anti-spam proposals adds some level of enforcment to
HELO and MAIL FROM. Those items will now be checked. That is what you need
to come to reality with. So where is your SPF record?
The timeouts, mentioned in RFC2821, are there not without a good reason.
Expecting each and every SMTP server answering within your 35 seconds
indicates you need a reality check.
Again, you can't use the same timeouts for a CBV.
Now you are very lucky. I am a designer and I don't believe in passing the
buck and I do adjust the software regardless of who it is. I will add an
option to extend the timeout to the RCPT response. You need about 1
minute. I will do this because it will not effect the overall behavior of
the system and its only for a 0.000001% of the systems.
And at the end of the day the CBV tells you nothing. See RFC2505:
Not quite. That was written in 1999. This is 2004!
The reality is that all emperical and real production data shows that a CBV
does work with 100% trust in rejections analysis. Positive results can not
be trusted with a no decision so you let the transaction move on to the next
step.
The reality is that over 80% of all spammers are spoofers, and CBV traps
atleast 90-94% of them by our figures. With CBV, you will get a
significant reduction of the spoofers. However, it does have overhead
implications, thus why in our design, we look at other test before the final
CBV is required.
This particular message to you is still in my mail queues: last attempt
Sat, 13 Mar 2004 12:01:15 +0000 (GMT)
winserver(_dot_)support(_at_)winserver(_dot_)com: smtp;552 Return Path not
verifiable.
I'll remove it right now, as you seem to be convinced your anti-spam
logic is more important than to receive legitimate messages.
Hey, as an SMTP software developer, I am not in the business of anti-spam
mail content analysis, nor should any SMTP software be.
However, protocol level enforcement requirements is now the new name of the
game. You were trying to send unsolicited mail to us - aka, it falls in the
category of anonymous access and that is where all the abuse is at. Hence,
in the new era, you need to be validated.
Add a SPF record, Rolf, it will solve all your unsolicited outgoing mail
issues in the "New Era" - not the 1999 era.
See ya
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com