Home Project Download QuickStart ManPage Debugging MailingList ChangeLog

Pop-before-smtp Debugging

If you're having trouble getting pop-before-smtp to work, this page should hopefully help you to track the problem down.

This doc assumes that you've already installed the pop-before-smtp software. If you did not, you will need to add the following option to the indicated test commands (put it first on the line):

    --config=./pop-before-smtp-conf.pl

You need to be root for most (if not all) of the testing.

To Diagnose what is going wrong, let's step through all the potential failure points:

Ensure that pop-before-smtp has the modules it needs to run.
If you can run this command without seeing any load errors:
```
    pop-before-smtp --dumpconfig
```
then pop-before-smtp has all the perl modules that it needs. If it complains, please see the Modules Section of the QuickStart Guide guide for what perl modules to install.
Ensure that your $pat choice and maillog are right.
Run the following debug command:
```
    pop-before-smtp --debug --nowrite --reprocess
```
You should see messages about what IPs the script finds and what it does with them. (Press Ctrl-C to abort the script when you've seen enough.)
If you see only "ignoring" messages, then you should ensure that someone has connected from a non-localnet IP. If they have, you'll need to fix the definition of what is a local-network IP. For instance, Postfix users would edit the "mynetworks" definition in the main.cf file. People with non-Postfix setups might have a list of local-net definitions in the pop-before-smtp-conf.pl file.
If you didn't see any IP mentions, either you don't have any POP/IMAP connections in the maillog, or you don't have the right $pat variable uncommented. Look at the maillog file manually to see what's up. Make sure at least one person has connected via POP/IMAP from a non-localnet IP. Then ensure that the maillog filename is set correctly, and that you've chosen the right $pat definition. You might even need to edit the regular-expression pattern. If you need help with this, contact the mailing list.
Retest until things look good, then kill the test program.
Ensure your config file has any needed optional sections enabled.
Some systems require the use of the BerkeleyDB, NDBM, or some other database format. (Please consult your mail system's docs if you don't know what it expects.) The Config Section of the QuickStart Guide mentions a few of the most common, but you can just read through the pop-before-smtp-conf.pl file and see if any of the disabled sections might apply to your setup.
Ensure that the pop-before-smtp daemon is running.
Check the output of "ps -ef" to ensure that the pop-before-smtp daemon is actually running. If it is not, use its init script to start it up:
```
    /etc/init.d/pop-before-smtp start
```
If it is running, check what command-line flags it is being run with. It should not have any of the debug flags mentioned above, such as --nowrite or --reprocess. Some older scripts set the mail-log file to watch. If yours does, I'd recommend removing that from the init.d script and setting the right mail-log value in the pop-before-smtp.conf.pl (restart the daemon after making any changes).
Ensure that the DB file was updated.
Look for the DB file and ensure that it has a recent modify date. You can run the following command to ask the script what setup it is using, which will tell you the name of the DB file:
```
    pop-before-smtp --dumpconfig
```
However, that value can be wrong if your init script is overriding it via the command-line, so your should verify that your init script isn't specifying an overriding --dbfile value. (If it's there, remove it and make sure that the config file has the value that you need to use.)
You can see the IPs that are in the file using this command:
```
    pop-before-smtp --list
```
If the DB file was not updated, make sure that pop-before-smtp is running. Ensure that you're running pop-before-smtp with enough permissions to write the DB file. Ensure that someone from a non-localnet IP has successfully accessed their POP or IMAP mailbox.
Ensure that your SMTP software has been configured to honor the pop-before-smtp DB.
The SMTP Section of the QuickStart Guide mentions how to setup Postfix and Sendmail to use the pop-before-smtp.db file. Make sure that the SMTP software is expecting the same DB file that pop-before-smtp is creating, and in the right format.
Try to send email from a non-localnet IP.
Check your POP/IMAP email from a non-localnet IP. The DB file should be updated (as long as that IP is not already in the file). You should also be able to send mail via your SMTP server from the same non-localnet IP. If not, ensure that your POP/IMAP and SMTP settings are correct for your client software. Also double-check the SMTP config settings in the previous step.
Verify that the DB version is right for your mail software.
If your SMTP software is complaining about the DB file being invalid, your perl DB_File module is probably generating the wrong version of the file for your mail system. You can use "file" to look around a bit, like this (edit the filenames appropriately):
```
    file /etc/mail/pop-before-smtp.db
    file /etc/mail/aliases.db
```
If the DB created by pop-before-smtp is quite a bit older/newer or in an unexpected format, there are a couple ways to fix this. One quick thing to try is to have your mail software create the DB file instead of pop-before-smtp. If that doesn't work, you'll need to reconfigure pop-before-smtp to be compatible with a DB version that your mail software accepts.
So, first try creating the DB file using some utility software that is supplied with your MTA. For instance, Postfix has the postmap command (make sure you've halted the pop-before-smtp script before doing this, and substitute the correct path for your DB file if you aren't using the default):
```
    cd /etc/mail
    rm pop-before-smtp.db
    touch pop-before-smtp
    postmap pop-before-smtp
    rm pop-before-smtp
    file pop-before-smtp.db
```
For Sendmail, you can use the makemap command (this also assumes the default path):
```
    makemap hash /etc/mail/pop-before-smtp.db </dev/null
    file /etc/mail/pop-before-smtp.db
```
You should then be able to restart pop-before-smtp and have it use the just-created DB file.
The next thing to try is to edit the pop-before-smtp-conf.pl file to enable an alternate database style -- for example, the BerkeleyDB code section will sometimes create a more recent DB version than the default DB_File module (be sure to delete the old pop-before-smtp.db file when you change the DB-creation code). Or you may need to choose a different DB style, such as NDBM, CBD_File, etc.
If the DB format is still not right, you may need to update the appropriate perl module to a more recent version. For most people they can just install the latest binary package (RPM, deb, etc.) for their system. If you find that you need to compile an update yourself, keep in mind that a perl module such as DB_File is built upon a C library, so you'll need to update the developement environment for that C library before re-building the perl module.
Finally, you should test that something hasn't gone wrong with your setup to make it an open relay. The easiest way is to use the tests provided by mail-abuse.org. From a shell on your SMTP system, run this command:
```
    telnet relay-test.mail-abuse.org
```
This will take a few seconds to sort itself out then the test will begin back to the same IP that you connected from (there is no prompting). You'll see the test output scroll by, and at the end you should see a summary of "System appeared to reject relay attempts" if everything is OK.
These tests do NOT blacklist you if you are "open", so no worries about being RBL'ed if it is found that you are running as an open-relay -- just fix the problem and re-run the tests.

Return to the pop-before-smtp home page.