Email Attachments are corrupted

[Russell Stevens]

What needs to be done to get SmtpMail.Send to work with an attachment - ex.

Imports System.Web.Mail

Dim ms as New MailMessage
Dim mattach As New MailAttachment("FullPathToPDFFile",MailEncoding.UUEncode)
ms.To = "(e-mail address removed)"
ms.From = "(e-mail address removed)"
ms.BodyFormat = MailFormat.Text
ms.Subject = "Test"
ms.Body = "Test Message"
ms.Attachments.Add(mattach)
SmtpMail.Send(ms)

I have previously reported that if you do not set the Encoding to UUEncode,
that pdf file attachments will be corrupted (the default is supposed to be
UUEncode but if you do not explicitly set it, it ends up being Base64).
However, some perfectly good pdf files still cannot be emailed as
attachments. The pdf files can be emailed using Outlook, AOL, and any other
email program I have tried, but not from a Win2K server using the above
code. The last two lines of the pdf file are

9369
%%EOF

These two lines are just dropped when the attached pdf file is sent. This is
100% reproducible. These two lines do NOT begin with periods so the metabase
setting for DisablePickupDotStuff should not apply (and from what I can tell
this only applies to IIS 5, not IIS 6).

I am using the 1.1 Framework on a Win2003 server. Microsoft - why doesn't
this work and what needs to be done to get it to work?

Thanks
Russ Stevens

 

[Peter Huang]

Hi Russel,

First of all, I would like to confirm my understanding of your issue.
From your description, I understand that when you use the System.Smtp.Mail
class to send mail with a pdf attachment. And the pdf file will be clipped
two lines at the end of the pdf file.
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

Firstly we need to isolate the problem by following the steps below.
From your description, you will send the mail by using the local smtp
server.
So we can send a mail to an account in local smtp domain.
We can check the local smtp domain by running the "inetmgr" and navigating
to Internet Information Services/<Computer Name>/Domains

Check the domain name (e.g. computername.fareast.corp.microsoft.com)
Then in the code we can specify the recipient's email address to
(e-mail address removed).

So that after the mail has been sent we can find the the mail in the
C:\Inetpub\mailroot\Drop, it should be a .eml file.

We can use the Outlook express to open the .eml file to see if the pdf file
has been corrupted.
If the file has been corrupted we can know that this may caused by the
local smtp server or the system.web.mail, so can you mail me a test pdf
file which will reproduce the problem.

If the file was not corrupted, I think this should be corrupted when we
relay the mail to the next smtp server.


When we send a mail use the system.web.mail, the mail will be generate and
sent to the local smtp(if we do not specify the smtpserver). At first the
mail will be at the C:\inetpub\mailroot\pickup directory and then was move
to the drop folder( if the recipient is in the local smtp domain) or relay
to another smtp server. So to troubleshoot the problem we need to know in
which steps the problem occurs.

Please apply my suggestion above and let me know if it helps resolve your
problem.


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter Huang]

Hi Russell,

Yes, I can reproduce the problem on my side with the PDF you provided.

Based on my research, the problem will not occur, if we use the Base64
encoding.
Dim mattach As New MailAttachment("c:\ie.pdf", MailEncoding.Base64)

You may have a try to see if the Base64 encoding works for you.

Also I have tried call the CDOSYS.DLL directly in VB6 using UUEncoding, I
can also reproduce the problem, because the System.Web.Mail is a warp of
the CDOSYS.DLL. But Outlook will not use the CDOSYS.DLL to send mail, so
that you can send the pdf file in outlook.

Also I have tried to build a txt file ended with
9369
%%EOF

But I can not reproduce the problem with the prebuilt text file even if I
have save it as test.pdf filename.

So the problem seems to specified to the pdf file, did many of your pdf
file have the problem and they are all ended with the string below?
9369
%%EOF


Or I think you may try to use the MailEncoding.Base64 as a workaround.

Now I am researching the issue, if I have any new information I will get
back and post here ASAP.

Thanks for your understanding.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[CJ Taylor]

Peter,

These were the two best explanations you have ever given. Nicely done.

-CJ

 

[Russell Stevens]

<<Or I think you may try to use the MailEncoding.Base64 as a workaround.>>

Peter,

NO - NO. Base64 is even worse. It corrupts a much larger number of files.
Microsoft's previous fix for the Base64 problem was to use UUEncode. Per
the documentation, UUEncode is supposed to be the default if you do not
specify it. However, it is NOT the default - so if you don't specify
UUEncode then Base64 is used and lots of files then get corrupted.

My server emails out many thousands of pdf files daily. This is a major
headache that I cannot solve. I don't know if your encoding routines are
just broke and don't work or what the issue is. However, I am not the only
one with this problem. I would hate to guess how many millions of corrupt
email attachments have been sent because of this bug. Microsoft needs to fix
it. I reported these problems on this forum last November!

Using Outlook to send these emails is not an option. I almost get the
impression that someone at Microsoft doesn't like pdf and goes out of their
way to make sure that handling them is a nightmare. My web pages require
numerous hacks to determine which version of IE is being used so that a pdf
file can be returned to the browser (each version requires special
handling). For Netscape, I don't even have to check the version - pdf files
just work. Getting the pdf file to the user via a browser is sometimes
impossible if the user uses IE and it turns out that I cannot reliably email
them either.

I also find out that Microsoft has code that strips out periods in
attachments (this is the default behavior and requires system hacks to get
around). Attachments should NOT be modified in any way.

Base64 works for some files, UUEncode works for some files, but there is
no logical explanation of why one works or doesn't work and no way of
telling in advance which one will work (sending two emails, one each way, is
not an option).

I suspect the problem is not with what is in the file, but has more to do
with the length of the file - ie - your encoding routines are probably doing
things in blocks and something is wrong with the block arithmetic.

Thanks
Russ Stevens

 

[CJ Taylor]

Hmmm apparently my kudos to Peter were unwarrented...

Well... you'll have that.

 

[Russell Stevens]

CJ,

<<Hmmm apparently my kudos to Peter were unwarrented...>>

Actually I am tickled that he looked and tried my sample and could verify
that there is a problem. The typical response is that something must be
wrong with the user's code. Duplicating the problem is the first step to
getting it fixed.

Russ

 

[Roosevelt Sheriff [MS]]

Hello Russell,

I took a look at the issue and using you repro code "as is" I was able to
reproduce the problem. However, as Peter suggested later in this thread, if
I didn't specifying an encoding at all or used Base64 the problem does not
occur. Have you confirmed that this in your enviornment?

I ran the same test with several different PDF files that I have locally on
my machine and was not able to reproduce the problem with any of them. You
mentioned that using Base64 causes the problem to occur even more than then
when using UUEncoding. Can you supply a PDF file where the problem occurs
even when using UUEncoding?

BTW, not that this is a solution, I also did the following test. I opened
the ie.pdf file in Visual Studio and edited the end of the file and remove
the whitespace (seemed like a return carriage) from the end of the file as
saved it as ie2.pdf. I used WinDiff to ensure that the files were the same
and there were with the exception that whitespace was missing which was
pointed out by WinDiff. I then sent that file (ie2.pdf) from the
application and I didn't see the problem no matter which encoding I used.

I took a look at a few other PDF files to see if the return carriage at the
end of the file was something standard and it seems that it is although I
couldn't reproduce the problem with any other PDF but the one you sent in.

Thanks
Roosevelt

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Russell Stevens]

Roosevelt,

<< if I didn't specifying an encoding at all or used Base64 the problem does
not
occur. Have you confirmed that this in your enviornment?>>

If you don't specify anything, then you get Base64 (UUEncode is supposed to
be the default according to the documentation but it isn't). Base64
(explicit or implicit) works for this particular pdf file. However, for me,
it corrupts a much larger number of pdf files. I don't have one handy that I
can send you but I did send one to Peter Huang ([email protected]) on
this forum back in November of last year. He was able to duplicate the
problem with the pdf file that I sent then using Base64. His workaround at
that time was to use UUEncode which worked for that particular file.

I have thus been using UUEncode but have now discovered pdf files that it
corrupts. Seems to be no rhyme or reason (attachments should not be
modified) except for the white space issue that you mention. Base64 corrupts
some, UUEncode corrupts some - as far as I know, when one doesn't work, the
other does (I don't recall having a pdf file that was corrupted by both).

I suppose I could strip white space off the end of pdf files but I am not
certain if that might corrupt some of them. I suspect this is an encoding
issue - but it should be fairly easy to duplicate and locate the problem
(easy for Microsoft - impossible for me).

Russ Stevens
R&R EdWare

 

[Roosevelt Sheriff [MS]]

Russ,

Let me have a closer look at the problem. I'll update you as soon as I know
more.

Thanks
Roosevelt

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Roosevelt Sheriff [MS]]

Hi Russ,

In search of a workaround I tried by passing System.Web.Mail and use CDOSYS
directly. I don't seem to have the problem this way. Will this be an
acceptable workaround for you? See my code below and let me know if how
this works for you.

Add references to "Microsoft CDO For Windows 2000 Library" & "Microsoft
ActiveX Data Objects 2.5 Library"

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click
Dim oMsg As CDO.Message = New CDO.Message
Dim iConfg As CDO.Configuration
Dim oFields As ADODB.Fields
Dim oField As ADODB.Field
Dim oAttach As CDO.IBodyPart

iConfg = oMsg.Configuration
oFields = iConfg.Fields

oField =
oFields("http://schemas.microsoft.com/cdo/configuration/sendusing")
oField.Value = CDO.CdoSendUsing.cdoSendUsingPickup

oFields.Update()
oMsg.Configuration = iConfg

oMsg.TextBody = "Test message body."
oMsg.Subject = "Test SMTP Message Send using pickup"
oMsg.From = "(e-mail address removed)"
oMsg.To = "(e-mail address removed)"
oAttach = oMsg.AddAttachment("C:\Data Files\emailtest\ie.pdf")

oMsg.Send()

oAttach = Nothing
oMsg = Nothing
iConfg = Nothing
oFields = Nothing
oField = Nothing

'Be sure to call GC.Collect() or else .Net will keep an open handle
the attached file.
'The file will seem as though it is in use by any other application
including itself.
GC.Collect()
End Sub


Thanks
Roosevelt

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Russell Stevens]

Roosevelt,

I will try the CDOSYS code - note quite sure what the

oFields("http://schemas.microsoft.com/cdo/configuration/sendusing")

line is all about. I would prefer to use the much simpler .NET stuff.
However, I am finding that a lot of the .NET Internet stuff for doing the
most basic of things is totally buggy. For example, if you want to upload a
file to a web server using WC.UploadData using basic authentication, then
every byte is sent three times (a 1 MB file takes 3 MB to upload). Microsoft
has provided a workaround but we are on Framework 1.1 rapidly heading toward
Whidbey and these basic features for uploading files and sending email are
not being fixed.

Programmers don't want undocumented workarounds that may break in the
future - we want it to work the way it was designed and documented. How many
millions of corrupt emails and terabytes of unnecessary bandwidth must be
wasted before this is fixed.

Thanks
Russ Stevens
R&R EdWare