Link to home
Start Free TrialLog in
Avatar of While1-Breathe
While1-Breathe

asked on

Email Issue - Header and attachments included in the body when received via MS Exchange

Hi,

I've got an issue where an automatically generated email with a pdf attachment gets corrupted when sent to (I believe) MS-Exhange servers.

I'm basing my suspcisoin that it is MS-Exchange specific as the emails in question are received perfectly through Gmail and another POP account i've tested it on. It also worked on a Zarafa account I was evaluating a while ago.

Our company uses a hosted Exchange solution so I'm limited in what I can tell about the server setup, and Microsoft products are not my strong suit in any case.

The problem email arrives with the header information included in the body of the email, and the PDF is printed as text at the footer. I've included a generic example of what appears in the body below.

I'm a little limited as to what I can work through in the system code as parts are proprietry and encrypted, however I suspect it isn't a programming issue since it seems to work fine on the other email systems. Just let me know if there's any other information you need and i'll do my best to source it.

Any leads would be appreciated as the automatic notifications are one of the key functions of the system.

Cheers in advance (and hope ;-),

W1B


From: "system@systemdomain.com" <system@systemdomain.com>
Reply-to: "system@systemdomain.com" <system@systemdomain.com>
Message-ID: <ae2b1fca515949e5d54fb22b8ed95575@system@systemdomain.com>

X-Priority: 3

X-Mailer: PHPMailer (phpmailer.codeworxtech.com) [version 2.3]

MIME-Version: 1.0

Content-Type: multipart/mixed;

      boundary="b1_ae2b1fca515949e5d54fb22b8ed95575"

Return-Path: system@systemdomain.com
X-OriginalArrivalTime: 20 May 2009 03:44:07.0758 (UTC) FILETIME=[3A8F86E0:01C9D8FD]


--b1_95e689ab9d0a41cb38410fec9182061e

Content-Type: text/plain; charset = "UTF-8"

Content-Transfer-Encoding: 8bit


[BODY CONTENT]


--b1_ae2b1fca515949e5d54fb22b8ed95575

Content-Type: application/octet-stream; name="1234.pdf"

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="1234.pdf"



JVBERi0xLjMKJeLjz9MKCjEgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cKL091dGxpbmVzIDIgMCBS

Ci9QYWdlcyAzIDAgUiA+PgplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvT3V0bGluZXMgL0NvdW50

[REST OF JUNK OMMITTED... IT GOES ON FOR PAGES]

Avatar of Mestha
Mestha
Flag of United Kingdom of Great Britain and Northern Ireland image

This is classic interference. If you are only testing it with a hosted environment that isn't enough to say it is an Exchange issue, because you have no idea what is going on behind the scenes. You don't know how the email is being routed, whether the host is using a separate SMTP gateway, AV and antispam filters. The usual cause is something scanning the traffic in a way that it should not, or the message is malformed in such a way that either Exchange or a third party tool cannot format it correctly for the client. You therefore see the raw attachment information instead.

Not really a lot you can do. If you have control over the way the email is generated then you will need to look at that, as it is the only part that you control. If you complain to the hosted Exchange company I know they will just tell you that all their other customers work fine so it must be your problem (and probably throw in the fact that they have 10,000 people on their hosting platform).

Unless you can build your own Exchange environment and replicate it with a clean installation (ie no third party tools involved on either the server or the client) then I would have to say it is either the way the message is being formatted or something happening in the hosted environment to corrupt the message format.

Simon.  
Avatar of While1-Breathe
While1-Breathe

ASKER

Thanks for the input!

I had a pretty strong suspicion I would get a response along these lines, there are a few to many black-box variables in the issue.

Just for my information, am I right to keep this thread open and add detail as it comes? Or is there a policy that I should start a new thread once I have more specifics? My hope was that EE could help me narrow the range of causes (if not solve it outright). Let me know and i'll sort it out...

What reasons are there for a blank header to be added to an email? Is this a common technique for a given purpose? I was thinking perhaps an for anti-virus or similar?

I'm in touch with the product support team and the hosted exchange support now, waiting on feedback which i'll post as I receive it.

Not sure that it will help, the email script in use is PHPmailer from Codeworx (http://phpmailer.codeworxtech.com).

Cheers,

W1B.



ASKER CERTIFIED SOLUTION
Avatar of Mestha
Mestha
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks Simon, I'll close the thread.

By 'Blank' I mean that the header that is actually used by the mail client does not contain to, from reply-to information... all of the correct info gets placed in the body.

The subject does get delivered however, so I'm betting something is triggering the email either in the mailer script of however the mailer class is being used.

I've confirmed this issue now across several exchange servers, both hosted and local which reduces the likelyhood of it being a server misconfiguration. I'll need to keep chasing the product support people. To give me a patch.

Thanks for your time!

Thanks for your help, I realise my question had too many variables. I was just hoping for a pre-fab solution ;-)
Just for completeness...

After switching the system to use SMTP instead the problem has vanished. It still isn't clear if the issue was due to the PHPmailer class or by the system using the class.