Blue Reef Technical Support Blue Reef Virtual Server Reseller ProgramInstallation instructions, manuals, how-tos, and more!About Blue Reef Consulting, Inc.

About Blue Reef Virtual ServersEcommerce Solutions for your Virtual ServerSearch the Blue Reef Virtual Server web site
Return to Blue Reef Virtual Servers Home Page
Order virtual servers, software, computers, and more!
Return to Blue Reef Main Home Page
Site Map
Support Solutions to help you do business with your Virtual Server.

Blue Reef Virtual Servers
Support Menu
Featured Solutions
Featured Solutions Overview
Support Archive
Request Help
Order a Blue Reef Virtual Server now!

"POP(IMAP)-before-SMTP" Anti-spam Measure

Featured: February 1998

NOTE: This document has expired. There is a an updated version of this document here.

How to restrict relaying through your mail server to only local users, specifically those that have authenticated using POP (Post Office Protocol) or IMAP (Internet Message Access Protocol).

Blue Reef has recently upgraded the email services on each Virtual Server to include a "POP(IMAP)-before-SMTP" anti-spam measure. With the demise of the big spamhaus operations like CyberPromo, the spamming community has resorted to "hit-and-run" spamming through open SMTP relays, the advantage being that a spammer can send a single copy of his or her spam from a throwaway dial-up account and have the fast and well-connected SMTP server "explode" the message out to 50 or more addresses per original send. Also, since there are many, many open SMTP relays around the world, spammers can easily circumvent spam blocking measures by bouncing their spams off an unsuspecting relay.

When implemented correctly, a POP(IMAP)-before-SMTP policy should all but eliminate this form of unauthorized SMTP relaying. POP(IMAP)-before-SMTP relaying works like this: every time someone successfully enters a correct username and password to the POP server or IMAP server, the server records the IP address of remote client for later use by the SMTP server. This IP address is stored in a .db file (etc/relayers.db) with a timestamp of the login. This database will serve as a list of IP addresses that are allowed to perform an SMTP relay and is used by sendmail during an SMTP transaction. Placing a simple set of rules in the "check_rcpt" section of the file will cause sendmail to refuse to relay except for IP addresses recorded by either the POP daemon or the IMAP daemon. With the addition of the "vsmtprelay" utility command that is used to expire addresses from the database as their validity runs out, the solution is complete. Database cleanup and address expiration can be automated via a cron entry, making the solution self-maintaining and requiring no manual intervention or maintenance.

    NOTE: Some of our Virtual Server customers have been contacted by ORBS (Open Relay Behaviour-modification System) advising them that their Virtual Server is an open e-mail relay. Usually, this is because the customer has disabled the POP-before-SMTP anti-spam feature on their Virtual Server.

    If you have been contacted by ORBS and wish to be removed from the ORBS database you must re-enable POP-before-SMTP and then submit your Virtual Server IP address to ORBS for testing and approval.

    Report a Closed Relay

    Of course, it is not mandatory to do this, but doing so will get ORBS off of your back.


Blocking Email from Specific Addresses

Using Wpoison to prevent bulk junk email spam


Solutions to the Spam Problem

Frequently Asked Questions

Support Archive


Administrator Handbook

Recommended Books

Request help from Technical Support


Programmer's Guide to Internet Mail : Smtp, Pop, Imap, and Ldap
Programmer's Guide to Internet Mail: Smtp, Pop, Imap, and Ldap


Stopping Spam
Stopping Spam


Removing the Spam: Email Processing and Filtering
Removing the Spam: Email Processing and Filtering


Internet Messaging
Internet Messaging

$35.96 logo
Search for :
Enter keywords...