----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Robert A. Rosenberg" <hal9001(_at_)panix(_dot_)com>
Cc: "IETF-SMTP" <ietf-smtp(_at_)imc(_dot_)org>
Sent: Sunday, June 26, 2005 7:05 PM
Subject: Re: Re Anonymous Final Destination and mail submission
> Obviously if the domain does not exist (ie: There is no
MX or A record) attempting to send a bounce is an exercise in futility.
Checking for the actual existence of that address (ie: That there is a
mailbox that can accept the bounce message) requires the issuing of a
VEFY Command which many/most SMTP Servers will not respond to for
security/privacy reasons.
Well, you can do HELO/MAIL FROM:<>/RCPT TO:<address>/RSET,
Its better to do:
HELO/MAIL FROM:<>/RCPT TO:<address>/RCPT TO: <random>/RSET
which allows you test for zombie/open relay. Maybe the host will say yes to
everything.
though in my experience some servers will reject a RCPT TO (regardless of
the
address) if the MAIL FROM address was empty.
This has not been our product implementation experience in nearly 2 years in
the hands of customers world wide. Thats not to say it has not happen but
to say.....
Yes, this means that the
bounce would never be delivered, but it _doesn't_ mean the email is
invalid.
then the server is non-compliant RFC 2821, and a rejection is justified.
The payoff is high given that over 60-80% of the time, the test is correct.
Any false positives, if any, will be quickly resolved. The good news is
that good systems are RFC 2821 compliant. Bad systems are not.
Keith, lets look at the other side.
A system issues a return path that you do not check. You also do not perform
a recipient validation at the SMTP 2821 level and perform the recipient
check at the
gateway processor. A bounce is determined to be required.
The burden is now on your system to deliver the bound over a specified
period. It fails eventual.
Multiple that with 60-80% of your transactions being in this state and you
now know why the SORBIG-based generation eVirus exist. It is based on the
three exploitable ideas or behaviors in your traditional SMTP setup:
1) No verification required for MAIL FROM
2) No authorization required for final destination
2) A legacy of "old school" systems still behaving as if they are in UUCP
mode where a gateway or router determines local vs. remote user. Many
systems that do offer SMTP level RCPT validation, do not turn on it for
three reasons:
2.a) They don't know about it or they are still use to the gateway concept.
2.b) Scalability - large inbound traffic, too slow rcpt verification.
2.c) Have a MFA (mail filter agent) working in post smtp mode.
Every now or then, we still need to inform sysops about turning on their
SMTP level local user validation to reduce their bounce loads, especially in
the SORBIG era. "Man, I am getting killed with bounces. How can we reduce
it?"
Modern high-end high efficient multi-threaded IOCP based servers with today
fast machines can handle scalability pretty efficiently these days.
Database I/O is pretty fast these days. Even AOL - the so called largest
ISP, switched form post smtp validation to dynamic smtp validation.
Obviously there are many more smaller systems than large ones, so they can
support doing dynamic smtp checks without penalty.
I don't know how many systems activate a MFA at the DATA stage, but that is
how we do it on our system (by default). Mail Content based rejections (an
administrative defined policy) at the DATA state helps reduce bounce
requirements.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com