P O P 3 - A U T H E N T I C A T E D   R E L A Y I N G

Why poprelay?

I still use Sendmail, and need to allow relaying for my ISP's customers even when not logging in through my lines. Allowing relaying for fifteen minutes after POP3 authentication seemed the best way to do this.

There are some tools and code to let you do this at spam.abuse.net, but these are rather kludgy and have a few problems. In particular, they

My system, which is entirely in the public domain, consists of a single perl script called poprelayd and some sendmail code. The perl code could use a bit of cleaning up; anybody who wants to do this feel free to get in touch with me.


There are instructions in the INSTALL file in the package. Here is an overview of the setup procedure that may or may not be out of date:

You'll need to integrate this code into your .mc file. Here are some notes on how it works:

You may also want to turn on the access_db feature (see cf/README in your sendmail distribution for details). This will let you relay for specific domains other than your machine's, so that you can serve as a backup MX host or accept mail for multiple domains, for example.

Once you've done this, put poprelayd someplace handy and configure it. You may want to change the following values in the /etc/mail/poprelay.conf:

Now just add something to your system init files to run poprelayd with the -d option when your system starts, start the daemon, and you should be set.

If you have any comments on this, please feel free to send me e-mail: my address is cjs@cynic.net.

Installation Notes:

As of 1998-10-15, this package has now seen several hundred downloads, and I've gotten a bit of feedback on it. The following notes deal with the most common issues I hear about.

  1. Non UW imapd/popd log entries that poprelay doesn't parse properly. This can be fixed by updating the regular expression in the scandir function. I cannot help you write a new regular expression in poprelayd, however, there are several available here. If you need to write your own it is not a difficult job. If you're not using UW imapd/pop3d and you don't know perl, you have two options. The first is to hire a perl guru to do this for you. I shouldn't take more than about a half hour of his time, and thus shouldn't cost much. The net abounds with perl gurus. The second is to go buy a copy of Larry Wall's excellent book Programming Perl and spend two or three hours one evening with the first chapter. This will teach you enough to update that function yourself, and this might be the excuse you've been looking for to get started with perl. If you're doing it this way, note that the gethostbyname() line in that function is not necessary if your daemon logs IP addresses; mine doesn't, so I have to do a reverse lookup on the name to get a list of IP addresses.

  2. Debugging Rulesets: if your ruleset doesn't appear to be working properly (for example, it always denies relaying, even when you think it should be allowing it), try running sendmail on an alternate port in debug mode, do an SMTP session by hand, and examine the debug output carefully. A typical command line would be
    sendmail -d21.15 -bd -OQueueDirectory=/tmp -ODaemonPortOptions=Port=2525
    Then you'd telnet to port 2525 on your machine, enter   MAIL FROM:foo@bar.com   and examine the debug output to see just what the rules are and aren't matching.

  3. Problems `opening' the DB file: Under some systems, sendmail and the perl DB_File module are not compiled with the same database code. (One might be using DBM and the other Berkeley DB, or they might be using two different major versions of Berkeley DB, for example.) The usual symptom is that after you've done the makemap of /etc/mail/popip.db, poprelayd (or perhaps sendmail) complains that it can't open the file. The solution is to recompile either sendmail or perl (sometimes both!) to use the same DB routines. (SuSE 6.2 is apparently one of the systems affected by this.) So far this problem hasn't shown up on RedHat.

[ home ]   [ up ]