Jesse, Before you go down a path aimed at "virtually no lost legitimate mail." Please consider the following cautionary tale.
I administer a qmail server using TMDA to reduce spam. The system works great with very few spam messages getting through. However, like you, I wanted to reduce the load on the server replying to bogus e-mail addresses. So I used the "tcpserver -p" method to perform reverse DNS lookups on incoming connections. Then I refused connections to servers that failed the lookup ($TCPREMOTEHOST not set) with a "451 bad reverse DNS" message. The results seemed stellar. My users weren't receiving spam, and my server wasn't working nearly as hard tying up bandwidth with messages to bogus e-mail addresses and the associated bounce messages. Unfortunately, I began getting complaints from users saying "How come Joe Blow can't send me e-mail?" It turns out that the tcpserver approach was not sufficiently reliable to prevent false positives, and the occasional legitimate e-mail was being bounced. Furthermore, Joe Blow was getting a bounce message saying it was a "permanent fatal error" leading him to think my user's e-mail address was no longer good. The result of the false positives was far worse than the problem I was trying to solve. Therefore, if you do SMTP probes on incoming mail, you want to be sure the approach is sufficiently reliable that you don't get false positives. If your internet connection is down or slow, or the remote host is down or slow, you probably want to result in a deferral rather than a hard failure. That way legitimate e-mails will have a second chance. I have reached the opinion that any method of spam prevention has to be very concerned with blocking legitimate e-mails. Unless you can definitively differentiate between a spammer and a server that is improperly configured, slow, or not terribly reliable, you risk creating heartache for you and your users in an effort to reduce the load on your server. If you go this route, do so with caution. Dan Meigs Timberline Engineering, Inc. "Jesse Guardiani" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Howdy list, > > I've been contemplating this spam fighting technique, and I was > wondering if I could get this list's opinion on it. (I don't THINK > that qpsmtpd does this already...) > > Anyway, the background behind the idea is this: I and my company use > TMDA to help us virtually eliminate spam in our (and our customer's) > inboxes. We've noticed that about 70% of the confimation requests sent > out for messages that end up in our pending queues BOUNCE because the > sender address or from address was bogus. > > It would be great if we could stop these messages from getting to the > pending queue in the first place by doing a reverse SMTP lookup on the > envelope sender (and possibly the FROM header) at message transmission > time. > > I'd like to implement this as an SMTP probe to the remote server in > the form of a "RCPT TO:" check. Obviously SMTP servers like qmail > don't ever deny incoming message when sent a "RCPT TO:", but that's > ok. I only plan to block the incoming email if the SMTP probe > definitively fails at "RCPT TO:". > > What does this list think about such an idea? > > I know that many people are vehemently opposed to even doing a reverse > DNS lookup on incoming mail, much less a full SMTP probe. However, I'm > not too worried about it. I think it's a good idea that would reduce > possibly up to 50% of our customer's spam RELIABLY with virtually no > lost legitimate mail. > > Thanks for the bandwidth. I'm looking forward to hearing any opinions > about this idea. > > -- > Jesse Guardiani, Systems Administrator > WingNET Internet Services, > P.O. Box 2605 // Cleveland, TN 37320-2605 > 423-559-LINK (v) 423-559-5145 (f) > http://www.wingnet.net > > We are actively looking for companies that do a lot of long > distance faxing and want to cut their long distance bill by > up to 50%. Contact [EMAIL PROTECTED] for more info.
