pmpass is a bash shell script that checks your mail log for today's successful uw-imap POP3/IMAP logins and regenerates sendmail's access.db database to allow relaying for those IP addresses.
Please do not use this script! This approach is a very poor substitute for SMTP AUTH. Configuring sendmail to use authentication is described in detail at sendmail.org. I have also prepared a quick start guide on configuring sendmail to use SMTP AUTH and STARTTLS on Red Hat Linux. I've left this page here for historical interest, because I believe that it contains some log parsing techniques that are more secure than in similar applications I've inspected. It has been my experience that other POP-before-SMTP applications are easily bypassed.
pmpass scans the selected maillog(s) for successful POP3/IMAP logins. It compiles a list of these IP addresses, formatted for use with access.db to allow relaying. If this list shows any change from the previous list, a new access.db is created.
To use pmpass, simply install it somewhere in root's path, such as
/usr/local/sbin. Be sure to make it executable:
chmod 700 /usr/local/sbin/pmpass
No daemons need to be recompiled, and sendmail.mc doesn't need to be edited, as long as the access database feature is enabled. Many distributions enable this by default.
All file locations are set as variables in the beginning of the script.
The defaults should work for systems that keep sendmail configuration files
in /etc/mail and log all mail messages to
/var/log/maillog. Change the values to match your system, if necessary.
Support files will be created automatically when pmpass runs. Log messages will
be sent to /var/log/pmpass by default. You may want to set up syslog to rotate it, or
comment it out in the script if you don't want logging. At least keep an eye on
it, as it will just grow and grow and grow...
The mail log(s) to parse are specified in $MAILLOG. This can be a
list separated by spaces and can contain wildcards. The following will all
work:
MAILLOG="/var/log/maillog"
MAILLOG="/var/log/maillog /var/log/maillog.1"
MAILLOG="/var/log/maillog*"
Most installations will just use the current mail log.
When it runs, pmpass will check for the existence of a file used to further limit
the lines from which it will extract IP addresses (/etc/mail/pmpass_restrict
by default). This file is used by egrep, and offers the powerful ability
to narrow the scope of the pmpass IP address extraction algorithm, which is already
robust and secure. Any strings in this file will reduce the number of successful logins that
are considered. It is not possible for the file to grant relaying to an IP address that would
otherwise be denied. However, it is possible to carelessly filter out all
lines, ending up without any valid IP addresses to add to the access.db. At its simplest, it
can be a list of valid users:
rob
robert
foobarcar
In this example, only lines containing the specified strings would be considered for IP
extraction. Note that robert is redundant, as it would be caught by rob.
See the man page for egrep for examples on how to use regular expressions to refine
your searches.
Keep in mind that all lines that match the search terms will be considered. Here's a more sophisticated example:
Auth
\brob\b
This gathers lines that used encrypted authentication and any lines
that contain the string rob surrounded by word edges (nonalphanumeric
characters), so it wouldn't catch robert and would catch rob regardless
of the login method used. Remember, search terms are sought only in lines
that wouldn't otherwise violate builtin restrictions, so attempts
to inject one of these strings into a failed login will not succeed in bypassing
the system.
--force or -f: regenerate access.db (useful after editing the access
file)
--test or -t: show extracted IP's, but don't make new access.db
--version or -v: show version info
--help or -h: show usage
Run pmpass in root's crontab every 5 minutes:
*/5 * * * * /root/bin/pmpass
This means that a user will be able to relay within at least 5 minutes of checking their mail. Of course, it's usually sooner, but it's the luck of the draw. Also remember that the default installation will reset every day at midnight. I haven't tested this with enormous log files, where it may be necessary to adjust the time to allow for completion. The script doesn't attempt to remember its position in the log and will scan the entire file each time.
20050402:
v. 0.03:
v. 0.02:
v. 0.01-alpha: