IIRC, there are packages to do this. The trick is, to do it right, it should to be done during the SMTP transaction. It should reject the mail during the MAIL FROM or RCPT TO; not accept it, check it later, and then bounce it. Also, there (at least at one time) was a heated debate over whether you should return a 4XX or 5XX. If Dieman is on this list, I believe there's an ISP in MN that's doing this, and he may be able to provide some insight on how it works for them. Other issues include: Depending on how you're rejecting the mail, the sending side may fall back to your backup MXes. Which will irritate the hell out of your ISP (smirk) or whoever is providing backup MX for you. Those will sit in their queue for the full 5 days, and then probably double-bounce to your postmaster address. Exchange less than 2003 does not do mailbox lookup and alias expansion during RCPT TO - Exchange just accepts anything at it's local domains, and will bounce user unknown later. So there's no way to get a user unknown out of an exchange server during the transaction. Basically, if a spammer does forge a domain hosted by exchange, you won't get the user unknown back, even if it's not a valid address. False negatives. Same can be said for large mailhosts that queue first and forward later. What is a "valid email addy"? Are you bouncing on just user unknown, or would you bounce things like "mailbox full" (could be legit or could be a spammers box full of complaints) What about mail servers that you can't connect to right now (DNS, transient net problems, silly MX tricks, etc) If you do large mail volume, your SMTP transactions will build up quickly. Each message you get now adds a connection back to a server and the corresponding SMTP dialog. If you get a lot of spam simultaneously, all sourced from the same domain, if the domain's SMTP server is slow to respond, your MTA's "brakes" will kick in and start limiting connections (or just run away and let the box crash...) All those SMTP sessions will build waiting for responses from the remote site. Many spams come from legitimate addresses, or addresses that can't be verified (ala Exchange, or large mail hosts that queue and forward). But this is all academic. When I investigated it, it looked to me like there were too many "what if's", grey areas, and special cases to be accounted for, versus the amount of mail that would've been blocked. But this may be a workable solution in your situation, depending on your mail volume, business or personal, what kinds of legit e-mail you get, who you are providing mail service to, etc. On Tue, 14 Sep 2004, Ben Bargabus wrote: > Hi, > Is there a way (or program/script I can run) to verify that incoming > messages come from valid email addys and bounce those that don't? I > know that the from header can easily be forged but I at least want to > verify that the forged header is a legit user name on that server. Just > looking for another way to cut down on sp at m here. By the way, I run > sendmail and procmail if that matters. > Ben. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > Help beta test TCLUG's potential new home: http://plone.mn-linux.org > Got pictures for TCLUG? Beta test http://plone.mn-linux.org/gallery > tclug-list at mn-linux.org > https://mailman.real-time.com/mailman/listinfo/tclug-list > _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota Help beta test TCLUG's potential new home: http://plone.mn-linux.org Got pictures for TCLUG? Beta test http://plone.mn-linux.org/gallery tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list