Virtual Users With Postfix, PostfixAdmin, Courier, Mailscanner, ClamAV On CentOS - Page 6

Want to support HowtoForge? Become a subscriber!
 
Submitted by thim (Contact Author) (Forums) on Thu, 2007-02-01 17:22. ::

Queue Management

You might want to view the mailqueue, if some mails are still pending or so.

postqueue -p

Time to learn something about a helper application that comes with Postfix: postsuper. Set a mail on hold:

postsuper -h MESSAGEID

Every message has its unique ID provided by Postfix when it accepts a message. If you want to address all mails in the queue use ALL.

When you delete a mail it goes like this:

postsuper -d MESSAGEID

Delete all mails in the queue:

postsuper -d ALL

 

Debugging

Postfix logging

Postfix daemon processes run in the background, and log problems and normal activity to the syslog daemon. The syslogd process sorts events by class and severity, and appends them to logfiles. The logging classes, levels and logfile names are usually specified in /etc/syslog.conf. At the very least you need something like:

vi /etc/syslog.conf

mail.err                               			/dev/console
mail.debug                            			/var/log/mail/maillog
or
# Log all the mail messages in one place.
mail.*                                           	-/var/log/mail/maillog

After changing the syslog.conf file, send a HUP signal to the syslogd process.

ps aux | grep sys

root      2585  0.0  0.0  3628  632 ?        Ss   Nov27   0:00 syslogd -m 0

kill –HUP 2585

IMPORTANT: many syslogd implementations will not create files. You must create files before (re)starting syslogd.

IMPORTANT: on Linux you need to put a "-" character before the pathname, e.g., -/var/log/maillog, otherwise the syslogd process will use more system resources than Postfix.

Another method is to check the postfix config files.

postfix check

egrep '(reject|warning|error|fatal|panic):' /some/log/file

The first line (postfix check) causes Postfix to report file permission/ownership discrepancies.

The second line looks for problem reports from the mail software, and reports how effective the relay and junk mail access blocks are. This may produce a lot of output. You will want to apply some postprocessing to eliminate uninteresting information.

The two major log files that you should check are:

  • messages (or messages.log)
  • maillog - located in /var/log and/or /var/log/mail

 

Debugging authentication problems

Courier-authlib includes a couple of debugging tools. These can be handy if you are having problems eg auth'ing via POP3, but aren't sure if its your POP3 config that's broken or whether its actually the courier-authlib that's not working properly.

Display all accounts:

/usr/sbin/authenumerate

Perform a test authentication, and show all values returned from courier-authlib:

/usr/sbin/authtest someuser@yourdomain.com somepassword

A common problem after installing the Courier authentication library is that authentication, using authtest, doesn't work. Below shows how to use courier's debugging features to pinpoint the problem.

Turn on debugging:

vi /etc/authlib/authdaemonrc

DEBUG_LOGIN=1    # turn on authentication debugging
DEBUG_LOGIN=2    # turn on authentication debugging AND show passwords

This setting is located at the very end of the configuration file.

After changing this setting, restart the authentication daemon by running the authdaemond stop and authdaemond start commands.

/etc/init.d/courier-authlib restart

At this point, all debugging output goes to syslog at level debug, which is normally not shown. You will probably need to change your /etc/syslog.conf file to be able to see these messages. If you have an existing entry which says mail.info (which means facility mail, level info or higher) then you can just change this to mail.debug. Alternatively you can add a new entry like this:

vi /etc.syslog.conf

*.debug                        /var/log/debug
Don't forget to create this file, and to send a HUP signal to syslogd to make it re-read its configuration:

touch /var/log/debug
kill -HUP syslogd

If you don't want to mess around with your syslog configuration, you can also start authdaemond manually, and log its output to a file:

/usr/bin/authdaemond >filename 2>&1

Issue a manual login like listed below.

 

Debug SMTP

If AUTH is listed you can log in to the server. This will usually allow some things which are normally restricted, for example relaying. You will need to use your username and password in Base64.

telnet localhost 25

AUTH LOGIN
334 VXNlcm5hbWU6
bmFtZQ==
334 UGFzc3dvcmQ6
U2VjcmV0
235 2.0.0 OK Authenticated

 

Debug POP3

telnet localhost pop3

user USERNAME
pass PASSWORD
stat
quit

You can see if your POP3 server is working correctly. It should give back +OK Hello there. (Type quit to get back to the Linux shell.)

 

Debug IMAP

telnet localhost imap

a login USERNAME PASSWORD
a examine inbox
a logout

 

Debug POP3 over SSL

openssl s_client -connect x.x.x.x:995

(Then use same commands as in POP3 example.)

 

Debug IMAP over SSL

openssl s_client -connect x.x.x.x:993

(Then use same commands as in IMAP example.)

 

Debug Maildrop

maildrop -V9 -d someone@yourdomain.com

maildrop: authlib: groupid=1001
maildrop: authlib: userid=1001
maildrop: authlib: logname=someone@yourdomain.com, home=/var/vmail, mail=yourdomain.com/s/someone/Maildir/
maildrop: Changing to /opt/mail
<press CTRL-D here>


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.