Postfix error

[Paul R. Ganci]

For well over a year and half I have had two incoming mail servers 
running postfix + amavisd + spamassassin + clamd on a CentOS 7 system 
working flawlessly. Over the past two days something has happened such 
that the postfix stops delivering messages to user inboxes with this 
message:


Jun  8 19:37:05 mx01 postfix/error[22985]: 7B867836338F: 
to=, relay=none, delay=295, delays=0.49/294/0/0.05, 
dsn=4.4.2, status=deferred (delivery temporarily suspended: conversation 
with 127.0.0.1[127.0.0.1] timed out while receiving the initial server 
greeting)


For whatever reason it appears that the clamd stops working and the 
backup clamscan does not takeover. As a result postfix stops mail 
delivery and begins to queue messages. When I restart amavisd and then 
flush the postfix queue the messages begin to be delivered again. Then 
for several hours everything works normally until some event causes 
clamd to stop again and the messages begin to queue again.


I have no idea where to begin to debug this problem. For the time being 
I created a cron job to fix the problem. But I definitely need to find 
the root cause of the issue. What bugs me as that everything has worked 
flawlessly for a year and a half and all of the sudden I have begun to 
have problems. Other than the postfix error message I don't see anything 
in the logs. Can anybody suggest a good way to debug the problem?


Also, has anybody else seen such a problem? If so, what did you do to 
fix it?


--
Paul (ga...@nurdog.com)
Cell: (303)257-5208

OT DMARC question

[Paul R. Ganci]

I notice that postfix generates bounce messages that without going 
through some effort do not get DKIM signed. I have setup my incoming 
gateway server so that messages to my email subscribers are bounced 
using a local_recipient_map. However I received a report from 
linkedin.com because a Linked-In subscriber sent a message to an email 
address of a non-existent local user. Linked-In flagged the 
Mailer-Daemon bounce message. It seems to me even if the message was 
DKIM signed the fact that the Return-Path header is <> would still cause 
a mismatch that should not pass the DMARC requirements. I was wondering 
how others handle this problem or is it really just a misconfigured 
Linked-In server? It is ironic that a bounce message resulting from a 
message to a non-existent address sent from linkedin.com would generate 
a DMARC fail by linkedin.com.

--
Paul (ga...@nurdog.com)
cell: (303)257-5208

Re: mysql local_recipient_map

[Paul R. Ganci]

On 06/19/2016 07:26 AM, Wietse Venema wrote:
Turn off chroot (edit master.cf, then do "postfix reload"). If RedHat 
decides to turn on chroot, then it is is their responsibility, not 
mine, to figure out what nsswitch, pam, etc. files are needed under 
/var/spool/postfix, and to keep those files in sync with the base 
operating system. 
Sorry I didn't mean to offend if I did.  As I said there is no issue 
running chroot. The setup works just fine and has for months now. Only 
recently did I try to use the mysql database with the 
local_recipient_maps and saw the issue I did. I am happy with my 
solution but was curious and thought you had some magic.


Thanks for your help.

--
Paul (ga...@nurdog.com)
Cell: (303)257-5208

Re: mysql local_recipient_map

[Paul R. Ganci]

On 06/14/2016 08:02 AM, Wietse Venema wrote:

Paul R. Ganci:

On 06/14/2016 04:28 AM, Wietse Venema wrote:

Paul R. Ganci:

  If the MYSQL library was handling the host name resolution
then why does the postmap -q query succeed? Shouldn't both queries fail?

Perhaps you are running postmap as ROOT; Postfix runs as on-root.

Indeed I was.

Perhaps you have chroot enabled in master.cf. This is the default on
debian/ubuntu. See http://www.postfix.org/DEBUG_README.html#no_chroot
Change the master.cf entry should to this:
 smtp  inet  n   -   n   -   -   smtpd
---^^^
Using chroot requires additional setup.
I am running CentOS 7 which runs postfix chroot. Everything works as 
expected in this mode except for the mysql configuration. You are 
suggesting a permissions problem but I have verified that even with 
world read access the problem occurs. I do not want to run postfix as 
root. I am okay with the setup as it is now however can you elaborate on 
what additional setup I would need to get the mysql database to work 
with a server name rather than a server IP address? I really thought it 
was as simple as making the config file and then just making the proper 
entry in main.cf ala:


local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf

There is definitely something strange because I just put back the server 
name and did a postmap query from a non-root account and it works fine. 
I also verified that I don't have a typo in the main.cf config so I 
really don't understand what might be different between the mysql access 
from postfix vs postmap.


--
Paul (ga...@nurdog.com)
Cell: (303)257-5208

Re: mysql local_recipient_map

[Paul R. Ganci]

On 06/14/2016 04:28 AM, Wietse Venema wrote:

Paul R. Ganci:

anyone know what I am missing in that it seems postfix did resolve the
IP address when communicating with the mysql database?

The host lookup is done by the MSQL library.
That doesn't seem correct to me because with hosts = 
server-1.example.comin/etc/postfix/local_recipient_map.cf


postmap -q sally@example.commysql:/etc/postfix/local_recipient_map.cf

works correctly

but the postfix daemon query fails (both requests work with an IP 
address). If the MYSQL library was handling the host name resolution 
then why does the postmap -q query succeed? Shouldn't both queries fail?


--
Paul (ga...@nurdog.com)
Cell: (303)257-5208

Re: mysql local_recipient_map

[Paul R. Ganci]

I changed the line hosts = server-1.example.com to use an IP address 
instead hosts = 192.168.1.200 and everything started working. Does 
anyone know what I am missing in that it seems postfix did resolve the 
IP address when communicating with the mysql database?



On 06/13/2016 07:52 PM, Paul R. Ganci wrote:
I have setup a mysql data baseto provide a list of of local email 
recipients for a gateway email server. The configuration file looks 
like this:


> cat /etc/postfix/local_recipient_map.cf
user = postfix
password = Secret
hosts = server-1.example.com
dbname = postfix
query = SELECT destination FROM postfix_virtual WHERE email = '%s'

If I do a test query ala:

> postmap -q sa...@example.com mysql:/etc/postfix/local_recipient_map.cf
sallysemail

This last command seems to indicate that the query completes 
successfully. So I then configured the main.cf per this extracted stanza:


# REJECTING MAIL FOR UNKNOWN LOCAL USERS
#
# The local_recipient_maps parameter specifies optional lookup tables
# with all names or addresses of users that are local with respect
# to $mydestination, $inet_interfaces or $proxy_interfaces.
#
# If this parameter is defined, then the SMTP server will reject
# mail for unknown local users. This parameter is defined by default.
#
# To turn off local recipient checking in the SMTP server, specify
# local_recipient_maps = (i.e. empty).
#
# The default setting assumes that you use the default Postfix local
# delivery agent for local delivery. You need to update the
# local_recipient_maps setting if:
#
# - You define $mydestination domain recipients in files other than
#   /etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
#   For example, you define $mydestination domain recipients in
#   the $virtual_mailbox_maps files.
#
# - You redefine the local delivery agent in master.cf.
#
# - You redefine the "local_transport" setting in main.cf.
#
# - You use the "luser_relay", "mailbox_transport", or 
"fallback_transport"

#   feature of the Postfix local delivery agent (see local(8)).
#
# Details are described in the LOCAL_RECIPIENT_README file.
#
# Beware: if the Postfix SMTP server runs chrooted, you probably have
# to access the passwd file via the proxymap service, in order to
# overcome chroot restrictions. The alternative, having a copy of
# the system passwd file in the chroot jail is just not practical.
#
# The right-hand side of the lookup tables is conveniently ignored.
# In the left-hand side, specify a bare username, an @domain.tld
# wild-card, or specify a u...@domain.tld address.
#
#local_recipient_maps = unix:passwd.byname $alias_maps
#local_recipient_maps = proxy:unix:passwd.byname $alias_maps
#local_recipient_maps =
#local_recipient_maps =
local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf

However after I issue

>postfix reload

I get the following warning in the /var/log/maillog file:

Jun 13 17:02:33 mx02 postfix/smtpd[24400]: warning: 
mysql:/etc/postfix/local_recipient_map.cf lookup error for 
"sa...@example.com"
Jun 13 17:02:33 mx02 postfix/smtpd[24400]: NOQUEUE: reject: RCPT from 
unknown[50.31.61.193]: 451 4.3.0 <sa...@example.com>: Temporary lookup 
failure; 
from=<bounces+1955696-a7dd-sally=examples@em2.imodules.com> 
to=<sa...@example.com> proto=ESMTP helo=


Can somebody tell me what I am doing wrong? Why does the postmap -q 
command line query successfully return a result but fail from postfix?


Thank you for your help.



--
Paul (ga...@nurdog.com)
Cell: (303)257-5208

mysql local_recipient_map

[Paul R. Ganci]

I have setup a mysql data baseto provide a list of of local email 
recipients for a gateway email server. The configuration file looks like 
this:


> cat /etc/postfix/local_recipient_map.cf
user = postfix
password = Secret
hosts = server-1.example.com
dbname = postfix
query = SELECT destination FROM postfix_virtual WHERE email = '%s'

If I do a test query ala:

> postmap -q sa...@example.com mysql:/etc/postfix/local_recipient_map.cf
sallysemail

This last command seems to indicate that the query completes 
successfully. So I then configured the main.cf per this extracted stanza:


# REJECTING MAIL FOR UNKNOWN LOCAL USERS
#
# The local_recipient_maps parameter specifies optional lookup tables
# with all names or addresses of users that are local with respect
# to $mydestination, $inet_interfaces or $proxy_interfaces.
#
# If this parameter is defined, then the SMTP server will reject
# mail for unknown local users. This parameter is defined by default.
#
# To turn off local recipient checking in the SMTP server, specify
# local_recipient_maps = (i.e. empty).
#
# The default setting assumes that you use the default Postfix local
# delivery agent for local delivery. You need to update the
# local_recipient_maps setting if:
#
# - You define $mydestination domain recipients in files other than
#   /etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
#   For example, you define $mydestination domain recipients in
#   the $virtual_mailbox_maps files.
#
# - You redefine the local delivery agent in master.cf.
#
# - You redefine the "local_transport" setting in main.cf.
#
# - You use the "luser_relay", "mailbox_transport", or "fallback_transport"
#   feature of the Postfix local delivery agent (see local(8)).
#
# Details are described in the LOCAL_RECIPIENT_README file.
#
# Beware: if the Postfix SMTP server runs chrooted, you probably have
# to access the passwd file via the proxymap service, in order to
# overcome chroot restrictions. The alternative, having a copy of
# the system passwd file in the chroot jail is just not practical.
#
# The right-hand side of the lookup tables is conveniently ignored.
# In the left-hand side, specify a bare username, an @domain.tld
# wild-card, or specify a u...@domain.tld address.
#
#local_recipient_maps = unix:passwd.byname $alias_maps
#local_recipient_maps = proxy:unix:passwd.byname $alias_maps
#local_recipient_maps =
#local_recipient_maps =
local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf

However after I issue

>postfix reload

I get the following warning in the /var/log/maillog file:

Jun 13 17:02:33 mx02 postfix/smtpd[24400]: warning: 
mysql:/etc/postfix/local_recipient_map.cf lookup error for 
"sa...@example.com"
Jun 13 17:02:33 mx02 postfix/smtpd[24400]: NOQUEUE: reject: RCPT from 
unknown[50.31.61.193]: 451 4.3.0 : Temporary lookup 
failure; from= 
to= proto=ESMTP helo=


Can somebody tell me what I am doing wrong? Why does the postmap -q 
command line query successfully return a result but fail from postfix?


Thank you for your help.