Postfix: mail transport unavailable

[Wader]

Hi there,

I've just moved to a new dedi using ubuntu 10.04.2 following linodes setup guide for ISPConfig. http://library.linode.com/web-applic...tu-10.04-lucid

Everything seems to be working as intended other than my mail server. Firstly i had issues with ClamAV to which i disabled, however now i seem to be receiving the error "mail transport unavaliable". I have about 80 emails waiting in the mailqueue.

Here is the output from "postconf -n"

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
body_checks = regexp:/etc/postfix/body_checks
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
header_checks = regexp:/etc/postfix/header_checks
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_size_limit = 0
mime_header_checks = regexp:/etc/postfix/mime_header_checks
mydestination = iwader.co.uk, localhost, localhost.localdomain
myhostname = iwader.co.uk
mynetworks = 127.0.0.0/8 [::1]/128
myorigin = /etc/mailname
nested_header_checks = regexp:/etc/postfix/nested_header_checks
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virt                                                                                                 ual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipien                                                                                                 t_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonica                                                                                                 l_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = mysql:/etc/postfix/mysql-virtual_relaydomains.cf
relay_recipient_maps = mysql:/etc/postfix/mysql-virtual_relayrecipientmaps.cf
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_client_restrictions = check_client_access mysql:/etc/postfix/mysql-virtual                                                                                                 _client.cf
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, che                                                                                                 ck_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth                                                                                                 _destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual                                                                                                 _sender.cf
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysq                                                                                                 l:/etc/postfix/mysql-virtual_email2email.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_transport = maildrop
virtual_uid_maps = static:5000

As far as i know all my dns is exactly the same as before (updated to the new ip ofcourse)

[till]

How did you disable clamav? If you simply stopped it, then it will stop also mail delivery. Please see ISPConfig FAQ for instructions on how disable mail filtering:

http://www.faqforge.com/linux/contro...n-ispconfig-3/

[Wader]

Yes thats the same guide i followed to disable it, however looking at the error logs this morning it would seem its still trying to use Amavis.

Jun 1 08:41:05 velocity postfix/qmgr[22287]: warning: connect to transport private/amavis: Connection refused

This line appears in the warn logs many times, even though the use of Amavis and ClamAV has been disabled.

[cbj4074]

Apologies for "bumping" this post, but I had the same issue and was able to find a resolution that seems to be worth documenting.

I, too, followed the guide at http://www.faqforge.com/linux/contro...n-ispconfig-3/ in order to disable Amavis and ClamAV on a low-memory server.

Of course, at the time, I did not absorb the most important piece of the article, which is at the bottom (should it be moved to the top?):

The changes in postfix main.cf will get overwitten by a ispconfig software update when you select to reconfigure services during upadte, so you should comment out the lines again after you install a ispconfig update.

After performing ISPConfig3 and OS updates, mail delivery ceased to function. I'm not sure if I elected to reconfigure services, but if that is the default, then I probably did.

Issuing the command

# egrep '(warning|error|fatal|panic):' /var/log/mail.log | more

made it apparent that the problem was indeed Amavis:

postfix/qmgr[XXXX]: warning: connect to transport private/amavis: Connection refused

After examining

/etc/postfix/main.cf

I noticed that the lines I had commented per the KB article cited above were re-added at the bottom:

content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

So, I re-commented the lines and restarted Postfix.

Still, the problem was not resolved... until I re-queued all of the previously-queued mail:

# postsuper -r ALL

Problem solved.

I'm no expert in this regard, but it seems that Postfix may have been using cached configuration files (even though I had restarted the service several times after re-commenting the lines in question), as evidenced by

# grep -r "amavis" /etc/postfix
/etc/postfix/master.cf:#amavis unix - - - - 2 smtp
/etc/postfix/main.cf:#content_filter = amavis:[127.0.0.1]:10024
/etc/postfix/main.cf~:#content_filter = amavis:[127.0.0.1]:10024
/etc/postfix/main.cf~:content_filter = amavis:[127.0.0.1]:10024
/etc/postfix/master.cf~:#amavis unix - - - - 2 smtp
/etc/postfix/main.cf~3:#content_filter = amavis:[127.0.0.1]:10024
/etc/postfix/main.cf~2:#content_filter = amavis:[127.0.0.1]:10024
/etc/postfix/main.cf.bak:#content_filter = amavis:[127.0.0.1]:10024
/etc/postfix/main.cf.bak:content_filter = amavis:[127.0.0.1]:10024

Any expert comments as to why re-queuing the undelivered mail resolved the issue are appreciated.

[till]

Any expert comments as to why re-queuing the undelivered mail resolved the issue are appreciated.

What you describe here is the normal behaviour of postfix and not related to any config file caching. A restart of postfix doe snot requeue emails. If a email delivery fails temporarily, postfix adds the email to to the queue and retries delivery after a given timespan or when the messages are requeued manually.

[cbj4074]

Thanks for the clarification, Till.

Given your remarks, I have another question

After re-commenting the applicable lines in Postfix's configuration file and restarting the service, I attempted to flush the mail queue with

# postqueue -f

The queued messages still failed to be delivered.

So, once mail is queued while Amavis is mis-configured, said mail cannot be delivered successfully with a flush (even after the configuration issues are resolved)? The mail must be re-queued, instead?

[till]

amavisd acts similar to a mailserver, just that it listens only on localhost with IP 10024. If a mail is received by postfix and the postfix configuration redirected the email to this "internal" mailserver on port 10024, then a postqueue -f will just try to redeliver the emails to amavisd as amavisd is stored as next step for email processing in the mail inside the mailqueue while a full requeue will tell postfix to act as if the email is received again so that it decides again where to deliver the email.