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.
if the server says yes to everything, it doesn't mean it's a zombie or
open relay, nor does it mean that the address is bogus. It just means
that the server isn't doing checking at RCPT TO time. nothing in the
standards requires it to do so.
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.
your reality is apparently different than mine :)
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.
some of us realize that even if a mail domain has misconfigured its MTA
to reject MAIL FROM:<> the message might still contain content that the
recipient needs to see. a misconfigured MTA is not a reliable indicator
of spam.
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.
unfortunately there are a lot of ill-conceived anti-spam measures
deployed out there. well-intentioned people do technically stupid
things like configure their mailers to reject any RCPT command that
follows MAIL FROM:<>. then other well-intentioned people decide that
they're going to reject any mail which has a MAIL FROM address for which
the inbound MX server works this way. I have somewhat more sympathy
with the latter tactic than the former, but neither tactic is
recommended by the standards, and the combination of ill-conceived
tactics makes mail a lot less reliable.
we really need a uniform set of recommendations for things like this.
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.
viruses would exist even if these checks were made. the fact that the
Internet mail system does not require MTAs to check the validity of
addresses immediately (allowing them to bounce messages later) is
independent of the conditions that allow viruses to exist. checking the
validity of such things may reduce the load on your mail system
significantly (and it's generally something that I recommend), but it
won't do much in the long run to reduce virus propagation. (it might
even help viruses propagate faster because your mail system will be
running more efficiently)
Keith