0

I have a Zimbra installation running on Centos 6.6:

Release 8.6.0_GA_1153.RHEL6_64_20141215151155 RHEL6_64 FOSS edition.

I have one account on the server that receives mail forwarded from another server which is derived from a ticketing system and a considerable amount doesn't get delivered. The inbound mail only comes from three addresses, which I have whitelisted in the account. I can see that the mail is getting delivered by tailing /var/log/zimbra.log and that mails that don't reach the inbox seem to get the message 

NOQUEUE: filter: RCPT from xxx.xxxx.com[xx.xx.xx.x]: <support@xxx.com>: Sender address triggers FILTER smtp-amavis:
 [127.0.0.1]:10026; from=<support@xxx.com> to=<xxx@xxx.co.uk> proto=ESMTP helo=<xxx.xxx.com>

The mail can be tracked through the log:

Jul 23 16:15:38 ns3002961 postfix/smtpd[28408]: 72BEFA3776: client=xxx.xxx.com[74.63.41.50]
Jul 23 16:15:38 ns3002961 postfix/cleanup[28410]: 72BEFA3776: message-id=<nry29p.3h7nbr@secure.xxx.com>
Jul 23 16:15:38 ns3002961 postfix/qmgr[28883]: 72BEFA3776: from=<support@xxx.com>, size=2292, nrcpt=1 (queue active)
Jul 23 16:15:38 ns3002961 amavis[27867]: (27867-15) Passed CLEAN {RelayedInternal}, ORIGINATING LOCAL [74.63.41.50]:28770 [74.63.41.50] <support@xxx.com> -> <xxx@xxx.co.uk>, Queue-ID: 72BEFA3776, Message-ID: <nry29p.3h7nbr@secure.xxx.com>, mail_id: VcJMRzM4207u, Hits: -, size: 2351, queued_as: A88BDA3D77, 147 ms
Jul 23 16:15:38 ns3002961 postfix/smtp[28413]: 72BEFA3776: to=<xxxx@xxx.co.uk>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.29, delays=0.14/0/0/0.15, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10030): 250 2.0.0 Ok: queued as A88BDA3D77)
Jul 23 16:15:38 ns3002961 postfix/qmgr[28883]: 72BEFA3776: removed

but doesn't arrive at the inbox. In a couple of instances it seemed like there might be a banned word filter operating because the originating addresses of the mails (the clients who send the mail) contained words that could be regarded as part of a spam mail, and whitelisting them has actually worked, but the issue is inconsistent and will fail to deliver mails even when other mails from the same user have been delivered.

I have run

zmprov ms `zmhostname` zimbraMtaLmtpHostLookup native

as suggested here and I have the option of turning off spam altogether for the account but I want to know why it's being blackholed and not being delivered anywhere if that's an option, and if logging can be improved as I'm not getting a reason why the mail isn't being delivered.

Simon Greenwood
  • 1,343
  • 9
  • 12
  • Update: I've now increased amavisd logging and set the spam kill rate to 0 in the COS too see if that makes a difference. – Simon Greenwood Jul 23 '15 at 17:15
  • You can see the emails are not delivered in /opt/zimbra/log/mailbox.log in the following format. 2015-09-01 09:16:11,889 INFO [LmtpServer-5462] [name=;mid=;ip=] lmtp - Not delivering message with duplicate Message-ID – eranga Sep 01 '15 at 03:47

1 Answers1

0

The answer in this case seems to have been that the support system sends mails with duplicate IDs, one for the message, and one for the change of ticket status, and Zimbra's default action is not to deliver duplicate mails. The answer was therefore to run

zmprov mcf zimbraMessageIdDedupeCacheSize 0

as the zimbra user and restart the mailbox daemon:

zmmailboxdctl restart

Delivery seems a lot more successful now and it did make sense as an issue in this case. The function isn't documented officially as far as I can see.

Simon Greenwood
  • 1,343
  • 9
  • 12
  • I would recommend using a dedupcache to a lower value like 50-100 rather than disabling this. Disabling this will have an impact on the end user receiving duplicate emails when an email is sent to 2 or more distribution lists where the same user is a member. – eranga Sep 01 '15 at 03:21
  • That's a good idea for broader use and I'll explore it for general support, but what I would really like to see is that the actions is logged somehow as it seems dangerous to make any mail disappear without someone knowing about it (ah, just seen your other comment). – Simon Greenwood Sep 01 '15 at 06:58