----- Original Message -----
From: "Tony Finch" <dot(_at_)dotat(_dot_)at>
To: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: <blilly(_at_)erols(_dot_)com>; <ietf-822(_at_)imc(_dot_)org>
Sent: Monday, February 28, 2005 1:50 PM
Subject: Re: MTS transparency and anonymity
We've found that SMTP call-back return path verification is quite
effective, though it has very nasty behaviour for the victims of joe
jobs.
I have somewhat different experience - I've found that SMTP call-back
verification often produces unnecessary failures, as it's not unusual
for
the sender's SMTP server to fail to respond promptly even though the
message is legitimate.
Oh yes, I didn't say it was easy to use and without interop problems :-)
But they can be mitigated with judicious use of exemption lists etc.
In practice, it is very effective simply because the fact is 60-80% of the
transactions are forged or problematic. It will undoubted catch a very
signficant portion these exact real "failure" points.
The implementation should use a non-permanent 45x response code to allow a
remote system to retry.
However, as it been proven in practice, as also illustrated with the growth
of Grey-Listing usage, it will work 100% for 100% failure points (the other
system will not retry), and if its a unexpected downage, the legitimate
sender will try again.
Now, the issue is what here?
SMTP compliant. If you use a MAIL FROM Return Path, it is deemed to be
reliable and researchable. If you feel difference, then we can stop here.
On the other hand, since it is deemed to be a researchable address, if it is
not, then the sender is NOT SMTP compliant - period.
This is why it works for thousands of our installations with many HAPPY
faces and little to know false positives. And as noted above, when there is
a false positive, the legitimate transaction will be flagged one we or
another and the issue resolved as asap. Normally, it all points to a poor
setup of SMTP compliant systems. Not in one instance has a customer has
reported - "This is a serious problem we can not resolve or unrelated to
SMTP compliancy."
It is a matter of HOW you view the SMTP compliancy issue of the Return Path.
Note: This has nothing to with zombie sites. These are picked up other ways.
The point of the Return Path Verification Call Back it so make sure the
transaction is SMTP compliant - nothing more, nothing less and again, since
the majority of all transactions are spoofed or NXDOMAINS, it is proven to
be a very reliable method against malicious transactions.
Two words - "SMTP COMPLIANCY" is the first step to securing a system.
This is my only comment about this and I will steer clear of this thread. I
just wanted to point out that the real experts are in the field actually
putting this stuff to work in practice - it is not theory, a raised back
hair or a devil on your shoulder whispering into your ear.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office