From: "Tony Finch" <dot(_at_)dotat(_dot_)at>
Subject: Re: Bounce/System Notification Address Verification
Ok, at 44 seconds, it became the CBV, as you can see thre wasn't a
response
to the RCPT TO: The timeout appears to be 35 seconds.
That's way too short for a CBV timeout, and in any case the appropriate
response to a timeout is 4xx (or perhaps 2xx), certainly not 5xx.
In my experience using CBV for nearly a year, it is a very troublesome
technique, and I'm still not happy with it. This is mainly because I don't
have the patience to try to teach the world how to send well-formed email
and fix their broken setups.
Finally!
Someone with some real CBV style operational experience with some
justifiable feedback I can have "faith" on. I appreciate the feedback.
Would it be possible to share some logs? [NDA ok by me]
I can certainly change the default for the timeout and I am going to pencil
in a revisit to a temporary response code. This was explored - no doubt.
Would it be fair to say you are in an academic environment? Are you basing
your experience on customer support of their usage of Exim as well?
I am a firm believer of the social network concept. Everyone is a social
network. Everyone has their own special relationships and pattern of users.
And it is for this reason why each of us have different experiences.
Generalization helps, but backgrounds are important as well.
This is important because one of the fundamental generic premise behind the
CBV and I can't stress it enough.
- It is based on the fundamental RFC x821 requirement of a
WORKING return path.
That is the EXPLOIT of the Spamming World. They rely on the broken systems,
the frustrations it presents, the administrators who back down.
We will never be able to solve the spammer problem if we persist with the
attitude that we should the continue to cater the operations of broken
systems.
With that said, if the system is broken, it isn't getting by the return
path validator.
The undisputable fact is our commercial and customer experiences has been
met with extreme success, and this is based on the strong compliancy
requirement. This was the goal and when applied, with complete disregard
for user intentions, it has prove a extreme majority of all transactions
are bad with very little false positive.
Of course, the admin has all the ability to turn it off so I will have to
get new feedbacks to find out more since the last major field testing was
done. Hey, a good bit of the sysops turned it off. :-) I can tell you
that many did early on when they first got the update and saw some emails
not coming in. But for the most part, most realize the need to strengthen
the operations provided a much higher payoff over allowing tons of spam into
their system. Without a doubt, this was most common experience. Also, we
stress to customers to establish their social networks (white list, black
list), use SPF, etc to help in reducing the overhead and any false
positives.
Finally, back to the timeout. I will most definitely revisit it, but I
should point out that any timeout CBV sessions has definitely been
attributed to bad sites. Rolf was only a false positive because he reported
the problem. Bad spammers do no report problems. Rolf also fixed his
system and not allowing a slow RBL break communications. That's not to
blame him. I take full blame for this false positive. No one needs to tell
me that. But the solution to the spam problem is a community effort, not
just one sided. So as such, this is definitely not a situation where you
throw out the baby with the bath water.
If this is the going to be prevailing attitude in the IETF arena, I doubt
2821bis/2822bis will do any justice for anyone. Just imagine when
SenderID/PRA is widely adopted in the internet. Never mind the enforcement
of 2822 and incompatible systems. As I predict, hackers will blast huge
payloads just to frustrate the hell of administrators enough to create new
scalability issues and to disable SenderId/PRA.
Thanks for your feedback Tony.
If you want to go off list and compare logs, that would be great.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com