How can I make SmarterMail accept password protected zip files.
Question asked by Eddie Seasholtz - 1/29/2020 at 1:03 AM
I have smartermail server setup as a smart host.  I have clients that require password protected zip files when sending confidential information as an email attachment through this server. I can't find anywhere to turn off the setting that blocks password protected archives. So now every message that gets sent to a bank or another attorney, with a password protected zip file gets bounced back with a "Remote Server returned 552 Password protected zip file found inside of the email" error. How can I shut off or bypass that particular check in SmarterMail?

11 Replies

Reply to Thread
Sébastien Riccio Replied
If i'm not wrong, by default it should accept it though.

Are you sure it is SmarterMail rejecting the mail?
Do you use an outgoing gateway, or could it be that the error is sent by the recipient server which refuses the mail ?

It would be helpful if you have the delivery session log of this particular e-mail.

Sébastien Riccio
System & Network Admin

Eddie Seasholtz Replied
Yes, I'm positive it is the smartermail rejecting it. The log shows it dropping the connection and generating the bounceback mesage with the 552 error.  I sent the message out of OWA on an Exchange server with the password attached, that sends it to the SmarterMail smarthost gateway, which should then forward it on to my mailbox on my SmarterMail enterprise server. But it doesn't.  It stops as soon as it hits the Smartermail smarthost gateway server. The smarthost never attempts to contact the destination server.

The SMTP log shows the full transaction. The delivery log has almost no information about it.  Here they are from the SMTP and DELIVERY log sections, names and ip's changed...

[2020.01.29] 03:37:14.800 [][62984132] rsp: 220 pf1.thisismydomain.com
[2020.01.29] 03:37:14.800 [][62984132] connected at 1/29/2020 3:37:14 AM
[2020.01.29] 03:37:14.800 [][62984132] Country code: US
[2020.01.29] 03:37:14.800 [][62984132] IP in whitelist
[2020.01.29] 03:37:14.800 [][62984132] IP in authentication bypass
[2020.01.29] 03:37:14.800 [][62984132] cmd: EHLO mail.thisismydomain.com
[2020.01.29] 03:37:14.816 [][62984132] rsp: 250-pf1.thisismydomain.com Hello []250-SIZE250-AUTH LOGIN CRAM-MD5250-8BITMIME250-DSN250 OK
[2020.01.29] 03:37:14.816 [][62984132] cmd: MAIL FROM:<Administrator@thisismydomain.com> SIZE=3381150
[2020.01.29] 03:37:14.816 [][62984132] senderEmail(1): Administrator@thisismydomain.com parsed using: <Administrator@thisismydomain.com>
[2020.01.29] 03:37:14.816 [][62984132] rsp: 250 OK <Administrator@thisismydomain.com> Sender ok
[2020.01.29] 03:37:14.816 [][62984132] Sender accepted. Weight: 0. 
[2020.01.29] 03:37:14.816 [][62984132] cmd: RCPT TO:<eddie@thedestination.com>
[2020.01.29] 03:37:14.831 [][62984132] rsp: 250 OK <eddie@thedestination.com> Recipient ok
[2020.01.29] 03:37:14.878 [][62984132] cmd: DATA
[2020.01.29] 03:37:14.878 [][62984132] Performing PTR host name lookup for
[2020.01.29] 03:37:14.956 [][62984132] PTR host name for resolved as 123-123-123-123.static.myisp.net
[2020.01.29] 03:37:14.956 [][62984132] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2020.01.29] 03:37:14.956 [][62984132] senderEmail(2): administrator@thisismydomain.com parsed using: Administrator <Administrator@thisismydomain.com>

[2020.01.29] 03:37:15.675 [73356] Delivery started for Administrator@thisismydomain.com (via bypass) at 3:37:15 AM
[2020.01.29] 03:39:21.881 [73356] Removing Spool message: Killed: False, Failed: True, Finished: False
[2020.01.29] 03:39:21.881 [73356] Delivery finished for Administrator@thisismydomain.com at 3:39:21 AM   [id:58673356]
Heimir Eidskrem Replied
Would not turn that function off.
We see so much virus coming in password zip files.

Find another solution.
Password protected zip files are not really that secure in the first place.

Nathan Y Replied
Check the clamd.conf 
Eddie Seasholtz Replied
Nathan, thank you for the input. I thought of clamd as well, so I tried with clamd scanning turned completely off and Smartermail still blocks and bounces the message. So that one wasn't the culprit.

So I'm still searching for a way to turn this on or off if anyone else has a thought.

Matt Petty Replied
Employee Post
We don't have any code that checks for password-zipped files. We do have a check for file attachment type (is this a ZIP) but that's as deep as we go, doesn't actually read the attachment. Set your delivery logs to detailed, run a test, and then you can include a snippet here from the log and maybe we can spot the cause. When you copy that session onto the community remember to **blank out** email and IP addresses.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
echoDreamz Replied
Doesnt clamAV have a setting - ArchiveBlockEncrypted it defaults to off though.
Eddie Seasholtz Replied
Hello Matt!

Here's the delivery log and smtp log file snippets. Any help figuring out how to get this to pass the password protected zip file would be greatly appreciated. It is a VPN tunnel between these two servers with no other hops in between. Source server is an Exchange 2013 server. Destination server is SmarterMail server setup as a smarthost to route incoming and outgoing mail to and from the Exchange 2013 server. Removing the password from the zip file and sending the exact same message between the two servers allows the Smartermail server to accept the message.


[2020.02.11] 06:57:06.257 [10488] Delivery started for sendinguser@theirdomain.com (via bypass) at 6:57:06 AM
[2020.02.11] 06:59:09.353 [10488] Removing Spool message: Killed: False, Failed: True, Finished: False

[2020.02.11] 06:59:09.353 [10488] Delivery finished for sendinguser@theirdomain.com at 6:59:09 AM [id:68210488]


[2020.02.11] 06:57:03.475 [10.x.x.5][59174024] rsp: 220 smartermail.gatewayserver.com
[2020.02.11] 06:57:03.475 [10.x.x.5][59174024] connected at 2/11/2020 6:57:03 AM
[2020.02.11] 06:57:03.475 [10.x.x.5][59174024] Country code: Unknown
[2020.02.11] 06:57:03.475 [10.x.x.5][59174024] IP in whitelist
[2020.02.11] 06:57:03.475 [10.x.x.5][59174024] IP in authentication bypass
[2020.02.11] 06:57:03.507 [10.x.x.5][59174024] cmd: EHLO sending.exchangeserver.com
[2020.02.11] 06:57:03.507 [10.x.x.5][59174024] rsp: 250-smartermail.gatewayserver.com Hello [10.x.x.5]250-SIZE250-AUTH LOGIN CRAM-MD5250-8BITMIME250-DSN250 OK
[2020.02.11] 06:57:03.538 [10.x.x.5][59174024] cmd: MAIL FROM:<sendinguser@theirdomain.com> SIZE=3387724
[2020.02.11] 06:57:03.538 [10.x.x.5][59174024] senderEmail(1): sendinguser@theirdomain.com parsed using: <sendinguser@theirdomain.com>
[2020.02.11] 06:57:03.554 [10.x.x.5][59174024] rsp: 250 OK <sendinguser@theirdomain.com> Sender ok
[2020.02.11] 06:57:03.554 [10.x.x.5][59174024] Sender accepted. Weight: 0.
[2020.02.11] 06:57:03.585 [10.x.x.5][59174024] cmd: RCPT TO:<receivinguser@mydomain.com>
[2020.02.11] 06:57:03.585 [10.x.x.5][59174024] rsp: 250 OK <receivinguser@mydomain.com> Recipient ok
[2020.02.11] 06:57:03.663 [10.x.x.5][59174024] cmd: DATA
[2020.02.11] 06:57:03.663 [10.x.x.5][59174024] Performing PTR host name lookup for 10.x.x.5
[2020.02.11] 06:57:03.663 [10.x.x.5][59174024] PTR host name for 10.x.x.5 resolved as UnknownHost
[2020.02.11] 06:57:03.663 [10.x.x.5][59174024] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2020.02.11] 06:57:03.694 [10.x.x.5][59174024] senderEmail(2): sendinguser@theirdomain.com parsed using: Sending User <sendinguser@theirdomain.com>
[2020.02.11] 06:57:05.257 [10.x.x.5][59174024] Exception: (PooledTcpItem.cs) An existing connection was forcibly closed by the remote host
[2020.02.11] 06:57:05.257 [10.x.x.5][59174024] StackTrace: at System.Net.Sockets.Socket.BeginReceive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, AsyncCallback callback, Object state)
[2020.02.11] at MailService.TcpServerLib.Common.PooledTcpItem.BeginReceive()06:59:05.978 [10.x.x.5][59174024] rsp: 421 Command timeout, closing transmission channel
[2020.02.11] 06:59:05.978 [10.x.x.5][59174024] Successfully wrote to the HDR file. (F:\SmarterMail\Spool\SubSpool3\68210488.hdr)
[2020.02.11] 06:59:05.978 [10.x.x.5][59174024] data transfer failed.
[2020.02.11] 06:59:05.978 [10.x.x.5][59174024] disconnected at 2/11/2020 6:59:05 AM

Here is the bounce message info:

The following organization rejected your message: pf1.netfusionkc.com.

Diagnostic information for administrators:
Generating server: sending.exchangeserver.com
Remote Server returned '552 Password protected zip file found inside of the email'
Original message headers:
Received: from sending.exchangeserver.com (10.x.x.5) by
 sending.exchangeserver.com (10.x.x.5) with Microsoft SMTP Server (TLS)
 id 15.0.1497.2; Tue, 11 Feb 2020 06:56:59 -0600
Received: from sending.exchangeserver.com ([fe80::bdbb:edcb:xxxx:xxxx]) by
 sending.exchangeserver.com ([fe80::bdbb:edcb:xxxx:xxxx]) with mapi id
 15.00.1497.000; Tue, 11 Feb 2020 06:56:59 -0600
From: Sending User <sendinguser@theirserver.com>
To: "receivinguser@myserver.com" <receivinguser@myserver.com>
Subject: Fw: Scheduled backup > BackupSet >
 2020-01-29-21-00-00, was missed
Thread-Topic: Scheduled backup > BackupSet >
 2020-01-29-21-00-00, was missed
Date: Tue, 11 Feb 2020 12:56:58 +0000
Message-ID: <1581425819796.36297@theirdomain.com>
References: <82aaaab4-6975-41ac-95d6-e0f6e8d69ba3@sending.exchangeserver.com>,<1580383988709.87839@exchangeserver.com>,<1580384887399.46343@exchangeserver.com>,<1580385273375.21828@exchangeserver.com>,<1581402037480.40083@exchangeserver.com>,<1581402280766.58857@exchangeserver.com>,<1581425171777.6064@exchangeserver.com>
In-Reply-To: <1581425171777.6064@exchangeserver.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.xx.xx.8]
x-gfi-smtp-submission: 1
x-gfi-smtp-hellodomain: sending.exchangeserver.com
x-gfi-smtp-remoteip: 10.xx.xx.5
Content-Type: multipart/mixed; boundary="_004_158142581979636297exchangeserver.com"
MIME-Version: 1.0
Nathan Y Replied
Marked As Answer
Check the configuration of your SonicWall firewall/VPN device as it is performing SMTP inspection.
Eddie Seasholtz Replied
Nathan, I didn't even think of that. I had it in my mind that the traffic is being exempted from nat when it traverses the tunnel and I didn't even stop to think that the firewall may be inspecting the traffic before putting it across the tunnel. I'll check to see if that's it here shortly. That sounds like it is more than likely the answer. Sometimes it is so easy to overlook the simplest answer. Thank you!
Eddie Seasholtz Replied
Nathan, that was it. Thank you so much for pointing me in the right direction! It was inspecting the packet before sending it across the tunnel.

Reply to Thread