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
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,
- 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.
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
- 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
- $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
- $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 firstname.lastname@example.org.
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.
- 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.
- 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
Then you'd telnet to port 2525 on your machine, enter
MAIL FROM:email@example.com and examine the debug output to
see just what the rules are and aren't matching.
sendmail -d21.15 -bd -OQueueDirectory=/tmp -ODaemonPortOptions=Port=2525
- 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.