On 8/16/2010 5:28 PM, Alex wrote:
Hi,
I'm trying to get postfix-2.5.5 and amavisd-new-2.3.3 working together
with two postfix instances, /etc/postfix and /etc/postfix-out. I'm
receiving the following error:
Aug 16 18:05:05 smtp01 postfix/error[1655]: 07C7335815B:
to=<j...@example.com>, relay=none, delay=1152,
delays=1152/0.07/0/0.02, dsn=4.3.0, status=deferred (mail transport unavailable)
I believe this is a problem with the first instance, and its inability
to communicate with amavisd, correct? netstat shows me the following:
# netstat -tapn | egrep '10024|10025|25'
tcp 0 0 127.0.0.1:25 0.0.0.0:*
LISTEN 3161/master
tcp 0 0 64.XX.XX.23:25 0.0.0.0:*
LISTEN 3046/master
tcp 0 0 64.XX.XX.22:25 0.0.0.0:*
LISTEN 3046/master
tcp 0 0 127.0.0.1:10024 0.0.0.0:*
LISTEN 781/amavisd (master
tcp 0 0 127.0.0.1:10025 0.0.0.0:*
LISTEN 3161/master
Is it necessary to have another IP other than loopback to do this
properly? I had this working properly with a much older version of
postfix, but the upgrade killed it so I'm starting over.
I have inet_interfaces in the first instance configured to be the two
23 and 22 addresses on the 64 network, and in the second instance it
is configured to 127.0.0.1. Connecting to loopback on ports 25, 10024,
and 10025 using telnet are successful. This happens with currently
queued messages as well as new incoming messages.
I have the filter defined in main.cf in the first instance:
content_filter = smtp-amavis:[127.0.0.1]:10024
I have the smtp-amavis filter defined in master.cf in the second instance:
If you tell the first instance to send to smtp-amavis:, it
needs to know what that means. Make sure to define
smtp-amavis in the first instance master.cf
Your logging will be a lot easier to read if you use
syslog_name to tag each instance.
# postfix 1 main.cf
syslog_name = postfix-1
# postfix-2 main.cf
syslog_name = postfix-2
Or use whatever names make sense to you.
Could this have something to do with my transport maps? I have a few listed:
Not directly. Often multiple postfix instances is used for
per-recipient filtering, which can only be done via
transport_maps. It appears to be your content_filter
directive that causes the problem.
Usually when a system is configured for multiple postfix
instances like this, there is no need for a specific
content_filter directive.
# The 22 address
alex.example.com smtp:[127.0.0.1]:10024
# The 23 address
susan.example.com smtp:[127.0.0.1]:10024
# Probably covers everything, so the above really isn't necessary?
* smtp:[127.0.0.1]:10024
This should send everything to your amavis content_filter.
It looks to me as if you can simply remove the content_filter
setting from your main.cf to fix the problem.
example.com smtp:[127.0.0.1]:10024
.example.com smtp:[127.0.0.1]:10024
Some of the examples and documentation I have read use lmtp instead of
smtp. Why would someone choose one over the other?
Years ago lmtp was slightly faster because it would cache
(reuse) connections. Since both smtp and lmtp now cache
connections, there is no longer any advantage to lmtp with
amavisd-new.
It's best to stick with the official docs. Random how-to's
you find on the internet may not be peer-reviewed nor updated.
-- Noel Jones
