Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Attachments not being received by one user (but get through fine to other recipients)

Status
Not open for further replies.

kopja

Technical User
Jul 20, 2005
63
US
Hello all

We have a client which sends us frequently certain documents. Do not know what version, but I know they use Outlook.
When this client sends us email with attachments,
- all internal users get the email+attachment,
- but one manager (CCed on same email) gets only the email (no attachment).
- Size of the email (as seen by manager) is small too, according to his Outlook, (not the usual size on other people's mailbox_
- Size of the email by other users is appropriate (they do get the attachment after all).
- Logging in OWA as manager still the same issue (email only, no attachment).

This only happens for attachment sent to this manager from this particular client, attachments from other people sent to manager show up fine.
If the sender FW an email with an attachment to same manager, attachments come through.
Attachments are mostly PDFs, but issue happens with other types of attachments as well.
When I check our antispam server (inside the firewall), the size of the email is appropriate (indicating the attachment is making it through fine).
Also, the other users receive the same email fine, so it seems to have something to do with the Exchange server

We all are in a AD windows 2003 domain, with single Exchange 2003 as mail server, with all updates installed.
Workstations are a mix of Windows 7 and XP, version of Office/Outlook is 2007 for all.

I have had the client send the email as RTF, HTML, TXT format, still same result (manager does not get attachment)

Any ideas? Is there any logging event I can look at? When I look at C:\program files\exchsvr\name\...log, there is no indication of size there.

Anyhelp is greatly appreciated.

Thank you.


 
When you look at the Exchange message tracking logs for the email to that manager (from the anti-spam server) do you see the message size being the "with attachment" size, or smaller? It would be good to know if the message had an attachment for that user when it hit Exchange.

Another thing to try: close the user's Outlook completely for a while and resend a message. Does it have the attachment in OWA? I'm thinking it's possible that local AV or Outlook removes the attachment and saves the message back to the server. If you check it in OWA after the Outlook has already gotten it, maybe the attachment is gone at that point. Determining at what stage the attachment disappears is the critical thing.

Dave Shackelford
ThirdTier.net
TrainSignal.com
 
Our incoming email flow goes like this Internet --> Firewall --> Sonicwall AntiSpam --> Exchange Server
- Sonicwall message audit shows the message being full size
- The logs on exchange server, under C:\ProgramFiles\exchsvr\servername\..20121212.log also indicate the full size of the email (including attachment)
- Is there any other logs somewhere else I should be looking at?

I will have the manager try with Outlook closed and let you know how that goes. (It may take a while to coordinate this)
But I thought if Outlook strips attachments, the email message would have a 'yellow bar' or something like that saying the attachment was stripped?

 
I had the sender send another email, and manager had Outlook closed the whole time.

Manager received the email (opened through OWA, outlook still closed), still no attachment (and no indication of an attachment)

Any ideas?


 
In the Exchange System Manager you can go to near the bottom of the hierarchy and choose Message Tracking. That't the tool you should use to find out the process the message underwent once it got to your server and how big it was at each step. I think it looks in the log you referenced, but it also traces the path and shows the values at each point.

Dave Shackelford
ThirdTier.net
TrainSignal.com
 
On ESM, message tracking, the size from sender shows up correct.
12/13/2012 12:03PM Sender client@clientdomain.com Size 88K

When I click on History, it says
12/13/2012 12:03PM SMTP: Message Submitted to Advanced queueing EVENT ID 1019
12/13/2012 12:03PM SMTP: Message Started Message submission to advanced queue EVENT ID 1025
12/13/2012 12:03PM SMTP: Message Submitted to Categorizer EVENT ID 1024
12/13/2012 12:03PM SMTP: Message Categorized and queued for routigng EVENT ID 1033
12/13/2012 12:03PM SMTP: Message Queued for local delivery EVENT ID 1036
12/13/2012 12:03PM SMTP: Message Message delivered locally to user@ourdomain.com EVENT ID 1023
12/13/2012 12:03PM SMTP Store Driver: Message delivered locally to Store to user@ourdomain.com EVENT ID 1019

There is no option I can see here (under message history) to show the message size




 
Sorry, last row event ID is 1028 (not 1019)
 
Do you see anything in the server's Application log at that exact time (12:03pm) that is Exchange transport related? We may need to enable a more diagnostic level of transport logging to reveal more details. To enable a higher level of

You're right, the message size doesn't show in the tracking history details. It does on all future versions of Exchange, but not on 2003.

Dave Shackelford
ThirdTier.net
TrainSignal.com
 
Nothing on the server appliaction log.
I have increased the logging level to Medium
on ESM->Diagnostics Logging-->MSExchange Transport-->SMTP Protocol, Queuein Engine, Routing Engine, Categorizer

Is there any other setting I need to add?

 
Ok, I went to ESM->Diagnostics Logging-->MSExchange Transport
I put logging level to Medium on Queueing Engine, Routing Engine, Categorizer
I put logging level to Maximum on SMTP Protocol

I had the client send another email.
This is what shows on antispam server (the message was delivered, along with attachment
Unique Message ID: 201212141346140028048
Subject: Test
From: 'Client' <ClientAddress@CLIENTDOMAIN.com>
To: USER@MYDOMAIN.com
Date received: Fri Dec 14, 2012, 08:46:00 GMT-05:00
Message size: 87 K
Threat: Good
Category: None
Audit trail: USER@MYDOMAIN.com
Identified as: Good
Message location: Delivered
Accepted by: 192.168.0.3:25 on Fri Dec 14, 2012 at 08:46 GMT-05:00


On Exchange server, application log there is no event occurring at the time
On Exchange tracking tools, it shows:
12/14/2012 9:01AM Sender... Subject.... recipient... Size 88K (so it recognizes the full size, 88k)

On the message history, it shows
12/14/2012 9:01AM SMTP: Message Submitted to Advanced queueing EVENT ID 1019
12/14/2012 9:01AM SMTP: Message Started Message submission to advanced queue EVENT ID 1025
12/14/2012 9:01AM SMTP: Message Submitted to Categorizer EVENT ID 1024
12/14/2012 9:01AM SMTP: Message Categorized and queued for routigng EVENT ID 1033
12/14/2012 9:01AM SMTP: Message Queued for local delivery EVENT ID 1036
12/14/2012 9:01AM SMTP: Message Message delivered locally to user@mydomain.com EVENT ID 1023
12/14/2012 9:01AM SMTP Store Driver: Message delivered locally to Store to user@mydomain.com EVENT ID 1028


On the C:\Program Files\Exchsrvr\SERVER\20121214.log shows
# Message Tracking Log File
# Exchange System Attendant Version 6.5.7638.1
# Date Time client-ip Client-hostname Partner-Name Server-hostname server-IP Recipient-Address Event-ID MSGID Priority Recipient-Report-Status total-bytes Number-Recipients Origination-Time Encryption service-Version Linked-MSGID Message-Subject Sender-Address

2012-12-14 14:1:9 GMT 192.168.0.245 emailsecurity.MYDOMAIN.com - BOSDC02 192.168.0.3 USER@MYDOMAIN.com 1019 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 Version: 6.0.3790.4675 - Test ClientAddress@CLIENTDOMAIN.com -
2012-12-14 14:1:9 GMT 192.168.0.245 emailsecurity.MYDOMAIN.com - BOSDC02 192.168.0.3 USER@MYDOMAIN.com 1025 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 Version: 6.0.3790.4675 - Test ClientAddress@CLIENTDOMAIN.com -
2012-12-14 14:1:9 GMT 192.168.0.245 emailsecurity.MYDOMAIN.com - BOSDC02 192.168.0.3 USER@MYDOMAIN.com 1024 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 Version: 6.0.3790.4675 - Test ClientAddress@CLIENTDOMAIN.com -
2012-12-14 14:1:9 GMT 192.168.0.245 emailsecurity.MYDOMAIN.com - BOSDC02 192.168.0.3 USER@MYDOMAIN.com 1033 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 Version: 6.0.3790.4675 - Test ClientAddress@CLIENTDOMAIN.com -
2012-12-14 14:1:9 GMT 192.168.0.245 emailsecurity.MYDOMAIN.com - BOSDC02 192.168.0.3 USER@MYDOMAIN.com 1036 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 Version: 6.0.3790.4675 - Test ClientAddress@CLIENTDOMAIN.com -
2012-12-14 14:1:9 GMT 192.168.0.245 emailsecurity.MYDOMAIN.com - BOSDC02 192.168.0.3 USER@MYDOMAIN.com 1023 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 Version: 6.0.3790.4675 - Test ClientAddress@CLIENTDOMAIN.com -
2012-12-14 14:1:10 GMT - - - BOSDC02 - USER@MYDOMAIN.com 1028 563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com 0 0 89818 1 2012-12-14 14:1:9 GMT 0 - - Test ClientAddress@CLIENTDOMAIN.com -


So it shows the size 89818 (which is approx 88k)

The user however, only received a 13k message.
THe headers of the message (as received by user) are below.
It shows something about winmail.dat, but there is no winmail.dat attachment at all, and the size itself is 13k (not 88k).
Microsoft Mail Internet Headers Version 2.0
Received: from emailsecurity.Mydomain.com ([192.168.0.245]) by mail.Mydomain.com with Microsoft SMTPSVC(6.0.3790.4675);
Fri, 14 Dec 2012 09:01:09 -0500
Received: from emailsecurity.Mydomain.com (127.0.0.1) id hpcmqe0171st for <USER@Mydomain.com>; Fri, 14 Dec 2012 08:46:15 -0500 (envelope-from <CLIENT@CLIENTDOMAIN.com>)
Received: from p01c12m094.mxlogic.net ([xxxxxx])
by emailsecurity.Mydomain.com (SonicWALL 7.3.6.7163)
with ESMTP; Fri, 14 Dec 2012 08:46:14 -0500
Received: from unknown [xxxxxxxx] (EHLO mail29.messagelabs.com)
by p01c12m094.mxlogic.net(mxl_mta-6.16.0-0) over TLS secured channel
with ESMTP id 3213bc05.0.2019145.00-2330.2863391.p01c12m094.mxlogic.net (envelope-from <CLIENT@CLIENTDOMAIN.com>);
Fri, 14 Dec 2012 07:01:07 -0700 (MST)
Received: (qmail 8499 invoked from network); 14 Dec 2012 14:01:06 -0000
Received: from unknown (HELO EXCHANGE07.CLIENTDOMAIN.com) (216.207.90.34)
by server-6.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 14 Dec 2012 14:01:06 -0000
Received: from ALC-NYC-CAS-002.CLIENTDOMAIN.com ([xxxxxxx]) by EXCHANGE07.CLIENTDOMAIN.com with Microsoft SMTPSVC(6.0.3790.3959);
Fri, 14 Dec 2012 09:00:54 -0500
Received: from ALC-NYC-MBX-001.CLIENTDOMAIN.com ([xxxxxx]) by
ALC-NYC-CAS-002.CLIENTDOMAIN.com ([xxxxxx]) with mapi id 14.01.0355.002;
Fri, 14 Dec 2012 09:00:53 -0500
Content-Type: multipart/mixed;
boundary="_000_563B07C6D97138478ED4021C45694E2623231864ALCNYCMBX001all_"
From: CLIENT <CLIENT@CLIENTDOMAIN.com>
To: "USER (USER@Mydomain.com)" <USER@Mydomain.com>
Subject: Test
Date: Fri, 14 Dec 2012 14:00:53 +0000
Message-ID: <563B07C6D97138478ED4021C45694E2623231864@ALC-NYC-MBX-001.CLIENTDOMAIN.com>
Content-Language: en-US
MIME-Version: 1.0
X-Mlf-AddressBook: CLIENT@CLIENTDOMAIN.com,people,allowed
X-Mlf-Connecting-IP: xxxxxx
X-Mlf-Country-Code: US
X-Mlf-Threat: nothreat
X-Mlf-Threat-Detailed: nothreat;none;none;list_addrbk_sender
X-Mlf-UniqueId: i201212141346140028048
Return-Path: CLIENT@CLIENTDOMAIN.com
X-OriginalArrivalTime: 14 Dec 2012 14:01:09.0678 (UTC) FILETIME=[780234E0:01CDDA03]

--_000_563B07C6D97138478ED4021C45694E2623231864ALCNYCMBX001all_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

--_000_563B07C6D97138478ED4021C45694E2623231864ALCNYCMBX001all_
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"

--_000_563B07C6D97138478ED4021C45694E2623231864ALCNYCMBX001all_--


I do not know where else to look.
Any ideas?







 
The fact that winmail.dat is mentioned in the header means that the sender is using Rich Text Format (RTF) to send the mail. If there is any problem on the receiving end reading RTF, then the attachment would be gone, replaced by the winmail.dat file. In this situation, one thing you could try would be having the sender change their settings to use HTML or plaintext when sending to your domain and see if the issue goes away completely.

I'm going to do more research and see if there's a reason why one particular receiving mailbox (not Outlook client, since this happened even in OWA) would treat inbound RTF-format messages differently.

Dave Shackelford
ThirdTier.net
TrainSignal.com
 

Thanks for looking into this, I appreciate it.

I believe the sender defaults the messages to HTML, and attachments do not come through.
However, I have also had the sender send the message as TXT, and still no attachment.

In other users, (not related to this issue) sometimes I do see the winmail.dat, but it is an actual winmail.dat file attachment.

In this case however, the 'headers' mention a winmail.dat, but there is no actual winmail.dat inside the email (and also the overall size of the email is small)

One more thing we have discovered:
We have a email distribution list, in which said manager is a member.
If the sender sends the email to the distribution list, manager gets the email, with the attachment.
However, if the sender sends the email addressed to manager, and CC the DL, manager only gets the email (no attachment), where as other members get the full email (with attachment).

This is not really an acceptable workaround though (as said manager is the one who sends most emails, and client communicates with her, not always with the DL)


 
Anyone has any ideas how to resolve this issue?
 
Is there any antivirus program running on the local client? It sounds like it is stripping away the attachment. Usually it adds a notice.

Can you have the sender send you the email, then you can try sending to the one who cannot receive it. It almost has to be something on the users machine, not within exchange itself. By sending this from your computer it disects out the unknown pieces a bit more.
 
There is an antivirus (McAfee Enterprise), but there is nothing to indicate that it is deleting attachments (meaning there is nothing on the activities log of McAfee and no indication on the email itself).
Also, we have had the senders send the email, user had Outlook closed the entire time, and just logged in to OWA, still no attachment.

Our user can send emails to them just fine, she does that several times a week.


 
Is this user whitelisted?

So here is another test.

Did you try this:
Can you have the sender send you the email, then you can try forwarding to the one who cannot receive it.

Another suggestion, create a mapi profile on another computer for the user having the issue (preferrably one who can receive it now) and try having the email attachment resent.

Until you narrow where the issue is its still too wide open to determine the point of failure.
 
The user is white listed on all antispam.

The sender usually sends it to a email DL, and CCs our manager.
Other members of the DL get the email fine, along with attachment. Once received, the others can also FW it fine to this manager (managers gets the attachment).
If the sender just sends it to the DL (of which manager is a member), the manager receives the email fine with attachment.
Only when the email is directed to the manager (on TO or CC), the manager does not get the attachment.
But there are many emails that need to go only to manager, not to the DL, so this is not really a solution

I will try the creation of another profile and see how that goes.
It may take a while as the manager would have to get the client to do this.



 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top