SMTP Connection - lost while reading message data

sparek-3

Well-Known Member
Aug 10, 2002
2,174
281
388
cPanel Access Level
Root Administrator
I've got a user that is unable to send out emails with attachments. Sending out a simple email with no attachment works just fine.

The exim_mainlog on the server is showing:

SMTP connection from XXXXXXXXX I=[XX.XX.XX.XX.XX]:PPP lost while reading message data (header)

I am not able to duplicate this at all when I try. I do not believe this to be a server issue, but I don't really know what the issue might be.

The user is using Norton's Anti-Virus, although they state that they have disabled that.

I suspect that the email client is funneling data through Norton's Anti-Virus, or perhaps something else, and that is failing. Despite Norton's allegedly being disabled, it's still messing with something. But I do not know how to advise the user accordingly.

The attachment in question is not that large, 40 to 50KB.

I'm ultimately at a loss. The data in the SMTP connection is being filtered some how. But since I'm not physically setting at the user's computer or know specifically what all they have changed or tampered with, I'm really at a loss.

Anybody had any similar issues? How did you resolve the issue for the user?
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
Hi @sparek-3

It does sound like the mail client is stripping the attachment. Have you had them try sending with an attachment using the webmail client rather than their local client?


Thanks!
 

Al Gilson

Member
Oct 15, 2015
10
0
1
Canada
cPanel Access Level
Root Administrator
Hi @sparek-3


Well, if it comes up again, that information would be useful to know.

Thanks!
I'm going to hijack this thread, as it sounds like what we're looking at too and I may be able to provide more info. I have two users at two different companies that are experiencing the same thing. They both connect to the same cPanel server. Both users are on machines that are brand new, less than a month old, both running Windows 10, Outlook 2016. One user is connecting via SMTP to our server on port 465 SSL security, and the other user is connecting on 587 STARTTLS. One user is using VIPRE anti-virus, and the other was on Sophos. I've disabled the AV on both, and the email still won't go.

When checking both machines, they'll have messages waiting in the outbox, and I'm seeing:
2018-11-14 16:52:57 SMTP connection from (LAPTOPHIM5UEV1) [x.x.x.138]:58650 lost while reading message data

When I do remote support on the machines, and send myself a test email, the email will go out. The system will say "Sending 1 of 7... Sending 2 of 7... and then hang there." The attachments on both are less than 300kb.

Oh wizards, any troubleshooting advice?
 

Al Gilson

Member
Oct 15, 2015
10
0
1
Canada
cPanel Access Level
Root Administrator
Hi @Al Gilson


I'd recommend the same troubleshooting as I recommended before. Is the same attachment able to be sent from their account using webmail?
I had the client send me the file via their @me.com address, and I tried it myself. No problem through the server. I then signed in to the webmail and sent it myself, from their account to my account (on Office 365) and the file arrived via webmail without any problems. When I go back in to the sent items folder in the webmail, I see:
Attachment stripped: Original attachment type: "application/pdf", name: "U1774.pdf"

I bet that's from Horde mail stripping the attachment. Yes, I can confirm that when I switch to Roundcube and resend the email, the attachment stays with the email in the sent items and the email arrives fine in my inbox.
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
Attachment stripped: Original attachment type: "application/pdf", name: "U1774.pdf"
So you're sending via webmail and getting this notice? Do you by chance have WHM>>Service Configuration>>Exim Configuration Manager -> Attachments: Filter messages with dangerous attachments enabled?

The list of attachments that's currently being stripped when that's enabled are as follows:

Code:
#               (?:ad[ep]                               # list of extns
#               |ba[st]
#               |chm
#               |cmd
#               |com
#               |cpl
#               |crt
#               |eml
#               |exe
#               |hlp
#               |hta
#               |in[fs]
#               |isp
#               |jse?
#               |lnk
#               |md[be]
#               |ms[cipt]
#               |pcd
#               |pif
#               |reg
#               |scr
#               |sct
#               |shs
#               |url
#               |vb[se]
#               |ws[fhc])
From:
Code:
/usr/local/cpanel/etc/exim/sysfilter/options/attachments
So technically a pdf shouldn't be stripped but I'd like to be sure that's not what's happening in this case.
 

Al Gilson

Member
Oct 15, 2015
10
0
1
Canada
cPanel Access Level
Root Administrator
So you're sending via webmail and getting this notice? Do you by chance have WHM>>Service Configuration>>Exim Configuration Manager -> Attachments: Filter messages with dangerous attachments enabled?
We do have filter messages with dangerous attachments enabled, and I have confirmed that we're using the default deny list. This attachment filtering was because of Horde mail, not because of these WHM settings. I can confirm that the email went through fine with both Horde mail and Roundcube, but the Roundcube sent items still has the attachment, whereas the Horde mail sent items does not because that's Horde mail's default to not save attachments after sending. In both cases, the recipient received the attachment.

I believe this has something to do with the handshake between a new Outlook 2016 and Exim when they're exchanging file attachments. Is there any place I can look to dig deeper in to the SMTP communication?
 

sparek-3

Well-Known Member
Aug 10, 2002
2,174
281
388
cPanel Access Level
Root Administrator
You mentioned that two users were having this issue and both had different virus scanners installed.

Have you tried a 3rd different setup that doesn't use any anti-virus software? Or perhaps completely removed the virus scanner on one of these user's computers?

I still think the issue is somehow related to the anti-virus software. I don't know if simply uninstalling the virus software is enough.

I suspect the email client (Outlook 2016?) has a proxy connection setup to send messages with attachments through the virus scanner. Even if the virus scanner is disabled, the email client is still trying to send the message out to that virus scanning proxy. Simply uninstalling the virus scanner may not remove that proxy connection setup.

I would be really interested to know if a plain-vanilla Outlook 2016 with no virus scanner ever being installed on the same network as one of these computers that is unable to send out these attachment is able to send the attachment or not.
 

Al Gilson

Member
Oct 15, 2015
10
0
1
Canada
cPanel Access Level
Root Administrator
You mentioned that two users were having this issue and both had different virus scanners installed.
Two different users, and two different companies with two different A/V systems. The server has around 600 users on it and I only heard from 2 with the issue; both running Win 10, Outlook 2016, and on new machines. Something seems suspect there. We could not recreate the issue here onsite. I also feel that A/V was probably playing a role in this, but... I was digging through exim_mainlog a bit more, and when looking for clues, I found this thread:
Tutorial - Reading and Understanding the exim main_log

Knowing I needed better logging, I changed log_selector to: +all, which restarted Exim.

Guess what? Everything works fine. The backlog of email in both suspect machines was instantly delivered. Sigh. No errors, no problem. I've since set the log_selector back to default and all mail is still flowing fine (as it should!).

Now I have the problem that I can't replicate the error to troubleshoot. I guess I wait for it to happen again, if it does, and then crank the logging back up and leave it as is.