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

• require modifications to your POP and IMAP servers;
• don't handle the POP3 logfile being rotated by newsyslog;
• regenerate the full database every thirty seconds;
• use several background daemons (tail, the logfile scanner, the database updater, the expiry daemon) where one should do; and
• make changes to sendmail.cf rather than the .mc file used for the M4 configuration system.

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.

Setup:

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:

• The localip map should contain a list of all the IP addresses and networks that are allowed to relay without authentication. Any final octets left unspecified are wildcards, so 192.168 will match 192.168.0.0/16, for example. The data assigned to each key don't matter, but you can set it to OK or something similar if you want to avoid complaints from makemap about keys without data.
• The popip map should be created empty (with makemap hash popip </dev/null); poprelayd will keep it updated.
• The relay map should contain a list of domains to which you will relay mail, regardless of where it's from. (That is, if the domain to the right of the @ sign in the SMTP RCPT TO: command appears in this file, the mail will be relayed.) Put any domains for which you do backup MX in this file. All subdomains of the specified domains will be relayed as well; for example, putting in foo.com will also relay mail destined to bar.foo.com.
• The rules in the Local_check_rcpt ruleset will have to be integrated with your own rules, if you use them. Note that I put the address into cannonical form (with a dot after the domain name) even if the domain doesn't resolve; that's so you get a `proper' bounce message rather than `Relaying not allowed' if the domain is not set up poperly in DNS. This may conflict with your rules.

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:

• $logfile: the file to which your POP3 daemon logs its messages.
• $pidfile: where you want to put the file containing the daemon's PID.
• $dbfile and $dbtype: the location of your datbase, and the type. This type has to be something that the DB_File perl module understands; it's not been tested with anything except DB_HASH.
• $timeout_minutes: the number of minutes after which an entry in the authorised IP address map will be removed. Every minute or so the daemon goes through the entire file removing addresses older than this number of minutes.
• sub scanaddr: this is the subroutine that determines if a log line is a valid POP3 authentication. If it is, it must return a list of IP addresses that are now allowed to relay mail. This is currently written to use the output from the University of Washington pop2, pop3 and imap daemons; you'll need to change this if you use another daemon. Some examples of modified scanaddr() routines for other pop3 servers are available here .

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.