Problem with mysql postfix backend with amavisd

Mark Martinec Mark.Martinec+amavis at
Sat Jul 5 15:48:15 CEST 2014


 > We have an issue with our mailrelay system.
 > Amavisd with spamassassin.
> Backend is Postfix with HASH db and mysql database. When the mail starts
> coming in, everything looks fine, but after a few minutes we see a lot
> of these errors.
> ----------------------------------
> :
> Works fine :
> virtual_alias_maps = hash:/home/postfix/namen
> Errors :
> virtual_alias_maps = hash:/home/postfix/namen,
> mysql:/home/postfix/
> ----------------------------------
> Temporary lookup failure; from=<X.XXXXXXXX at>
> to=<xxxxxxxx at> proto=ESMTP helo=<localhost>
> Jun 26 14:25:27 mx4 amavis[8448]: (08448-02) smtp resp to RCPT (pip)
> (<xxxxxxxx at>): 451 4.3.0 <xxxxxxxx at>: Temporary lookup
> failure

The "451 4.3.0 ..." comes from the back-end Postfix instance.

> This happens only if the mysql backend is being used. If the mysql is
> being turned off in the config everything works as expected. Our setup
> is as followes :
> --> 25 / Postfix / smtpd
> --> / amavisd
> After spamcheck
> --> / Postfix smtpd
> Delivers to final recipient.
> We have noticed that recipient translations are being done twice. First
> before, and again after the spamcheck. We think the second translation
> is going wrong sometimes. Is there a way to disable recipeint check on
> second smtpd hop. (More of a question to postfix list)

It is a postfix question. It is possible to have virtual alias
mapping individually enabled/disabled in the front or the backend
instance, although it is a bit of a hackery, as the virtual_alias_maps
setting is property of a cleanup service, so you need to have
two cleanup services, then configure smptd and pickup services
to use one of the other. This is documented in
README_FILES/README.postfix in the amavis distribution.

For simpler cases it may suffice to use:
   -o receive_override_options=no_address_mappings
on one smtpd service in

> Can anyone help with this error ? Mysql database performance issue is
> not the case. After extensive monitoring we found that max connections
> and memory is fine.

Definitely looks like an issue with MySQL. No idea there.


More information about the amavis-users mailing list