[Top] [All Lists]

Re: Re Anonymous Final Destination and mail submission

2005-06-27 06:26:53

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

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)


<Prev in Thread] Current Thread [Next in Thread>