we have nDLP Prevent appliance (9.2.1) configured to scan outgoing messages and sent them to Internet through EMG. All things are working except that some emails are stuck at deffered queue on Prevent, i.e. Prevent can't send some messages because for some reason EMG just don't accept them. See below log file from Prevent:
May 22 09:40:51 DLPPrevent1 sendmail: r4M6ep8r016424: from=<user_1@some_domain>, size=8262, class="0", nrcpts=1, msgid=<OF32280CEE.5C8666FB-ON43257B73.00249114-43257B73.0024BFF7@some_domain>, proto=ESMTP, daemon=MTA, relay=[172.30.69.44]
May 22 09:40:51 DLPPrevent1 sendmail: r4M6ep8r016424: Milter add: header: X-RCIS-Action: ALLOW
May 22 09:41:35 DLPPrevent1 sendmail: r4M6ep8r016424: to=<keys@another_domain>, delay=00:00:44, xdelay=00:00:44, mailer=relay, pri=128262, relay=[172.30.69.43] [172.30.69.43], dsn=4.0.0, stat=Deferred
May 22 10:46:51 DLPPrevent1 sendmail: r4M6ep8r016424: to=<keys@another_domain>, delay=01:06:00, xdelay=00:00:54, mailer=relay, pri=218262, relay=[172.30.69.43] [172.30.69.43], dsn=4.0.0, stat=Deferred
May 22 11:47:42 DLPPrevent1 sendmail: r4M6ep8r016424: to=<keys@another_domain>, delay=02:06:51, xdelay=00:00:00, mailer=relay, pri=308262, relay=[172.30.69.43], dsn=4.0.0, stat=Deferred: Connection reset by [172.30.69.43]
May 22 12:55:41 DLPPrevent1 sendmail: r4M6ep8r016424: to=<keys@another_domain>, delay=03:14:50, xdelay=00:01:01, mailer=relay, pri=398262, relay=[172.30.69.43] [172.30.69.43], dsn=2.0.0, stat=Sent (Requested mail action okay, completed.)
172.30.69.43 - Cluster IP for EMG
As you could see it took about one hour and four times for Prevent to send email through EMG. What could be the reason for "Connection reset" from EMG? How to troubleshoot this connection resets because these reset not seen in reports?Message was edited by: dtomko on 5/22/13 12:48:39 PM CDT
Well, sort of, but I really thought accessing that via the GUI (downloading the same and take a peek into that).
/I assume syslog collection and necessary type of entries are enabled (mail log)./
One more thing: your log excertp here does not reveal the cause (i.e. return message of EMG) of each individual rejection, just when the email has suceeded in sending.
This reminds me of one thing that could be one possible reason: greylisting active in EMG. Greylisting behaves in such a way that in won't accept mails from *new* clients in a configurable time, then accepts and then again does not accept. I won't go in too much detail, because this is just a assumption. but if your Prevent appliance sends only irregularly email and tjhose emails irregularly got rejected, greylisting could be the reason.
But speaking of this: in addition to the syslog, you can use the Message Search or message log in the EMG GUI Reports section. Depending on the type of rejection the reason can be logged in one or both places.
I'd start with the message search and took last the syslog (because of the searching requires more manual effort)
To see if greylisting is enabled or not please go to Email - Email configuration - Receiving email - Recipient authentication, as far as I know greylisting settings are the first on the page. Be sure to check Protocol Preset too next to it, because greylisting might not be enabled for Default preset but enabled for certain other circumstances - please use the dropdown menu and select each other preset you might see there and that bring up greylisting settings for that preset condition.
It is best though to use the Email - Email Reports - Filter (add search criteria, Apply, then switch to Details tab to the left) section for log entries and search for the IP or domain or whatever distinguising feature of emails sent by Prevent appliance.
I'd like to stress that a "connection reset" could be due to any other filter that is set to "Close connection", it is not clear to me (and perhaps you too) in which phase gets Prevent appliance email blocked, that would help estimate the stage and filtering method. Could you check on which mail stage get Prevent email a block? On connection, on MAIL FROM, on RCPT TO, etc.