SmtpMail Problems

  • Thread starter Thread starter Russell Stevens
  • Start date Start date
R

Russell Stevens

I generate pdf files on my server and allow users to access them via a
browser and also email them. Most files work fine whether the user uses his
browser or gets an email with a pdf attachment which he can then open with
Acrobat. All my pdf files work fine via a browser, but some are corrupted
by one byte when sent as an email attachment. The problem is 100%
reproducible - the code is trivial. Am I missing something obvious or is
this a bug with SmtpMail. ie

Imports System.Web.Mail

Dim ms As New MailMessage
ms.To = "(e-mail address removed)"
ms.From = "(e-mail address removed)"
ms.BodyFormat = MailFormat.Text
ms.Subject = "Test"
ms.Body = "Test Message"
Dim mattach As New MailAttachment("c:\temp\temp.pdf")
ms.Attachments.Add(mattach)
SmtpMail.Send(ms)

The pdf file is 16453 bytes. If retrieved via a browser, then view/saved it
is still 16453 bytes. If the exact same file is emailed as an attachment
using the above code, the attachment is one byte less at 16452 bytes.
Acrobat considers it a corrupt file and won't open it. Other pdf files do
not have this problem when emailed. I suspect the problem has nothing to do
with pdf files, but that some attachments are just clipped by 1 byte.

If I email the exact same file using an email program, the file is not
clipped by one byte.

Anyone seen this, have a workaround, or suggestions?

Thanks
Russ Stevens
 
it's probably to do w/ the encoding type. try setting to either binary or
utf-8.

see if that helps.

steve

| I generate pdf files on my server and allow users to access them via a
| browser and also email them. Most files work fine whether the user uses
his
| browser or gets an email with a pdf attachment which he can then open with
| Acrobat. All my pdf files work fine via a browser, but some are corrupted
| by one byte when sent as an email attachment. The problem is 100%
| reproducible - the code is trivial. Am I missing something obvious or is
| this a bug with SmtpMail. ie
|
| Imports System.Web.Mail
|
| Dim ms As New MailMessage
| ms.To = "(e-mail address removed)"
| ms.From = "(e-mail address removed)"
| ms.BodyFormat = MailFormat.Text
| ms.Subject = "Test"
| ms.Body = "Test Message"
| Dim mattach As New MailAttachment("c:\temp\temp.pdf")
| ms.Attachments.Add(mattach)
| SmtpMail.Send(ms)
|
| The pdf file is 16453 bytes. If retrieved via a browser, then view/saved
it
| is still 16453 bytes. If the exact same file is emailed as an attachment
| using the above code, the attachment is one byte less at 16452 bytes.
| Acrobat considers it a corrupt file and won't open it. Other pdf files do
| not have this problem when emailed. I suspect the problem has nothing to
do
| with pdf files, but that some attachments are just clipped by 1 byte.
|
| If I email the exact same file using an email program, the file is not
| clipped by one byte.
|
| Anyone seen this, have a workaround, or suggestions?
|
| Thanks
| Russ Stevens
|
|
 
<<it's probably to do w/ the encoding type. try setting to either binary or
utf-8.>>

Steve,

There are only two choices,

MailEncoding.Base64
MailEncoding.UUEncode

Neither one of them work.

Thanks
Russ Stevens
 
Steve,

Well, I guess I hadn't tried both choices. I had tried MailEncoding.Base64
and that did not work. I did not bother to specifically try
MailEncoding.UUEncode as the Micorosft Docs cleary state that
MailEncoding.UUEncode is the default when you don't specify an encoding.

So - it appears the Docs are wrong and in addition, why would Microsoft
pick a default that doesn't work.

Geesh.

Thanks
Russ Stevens
 
they picked uuencode b/c it was the first format for attachments...and it is
recognized by all email clients that support the receipt thereof. not all
clients support base64...but it is quickly becoming the default for the
clients' attachment encoding style. the choice is logical and formal and has
no association as to the functionality of the object's interface...there is
either an error in their code or an error in yours. i think theirs has been
tested a bit more and would have been patched by now if for some reason it
went un-detected...don't be so fast to throw stones.

code snippets help a lot in here.

steve

| Steve,
|
| Well, I guess I hadn't tried both choices. I had tried
MailEncoding.Base64
| and that did not work. I did not bother to specifically try
| MailEncoding.UUEncode as the Micorosft Docs cleary state that
| MailEncoding.UUEncode is the default when you don't specify an encoding.
|
| So - it appears the Docs are wrong and in addition, why would Microsoft
| pick a default that doesn't work.
|
| Geesh.
|
| Thanks
| Russ Stevens
|
|
|
 
<<code snippets help a lot in here>>

Not quite sure what you mean by that remark - I included the entire snippet.

<<there is either an error in their code or an error in yours. i think
theirs has been
tested a bit more and would have been patched by now if for some reason it
went un-detected.>>

Really - their Internet stuff is totally buggy. Try uploading a file to a
server that has basic authentication. For every byte that is uploaded, three
bytes get sent down the wire. They have known about this problem since I
reported it when they first released .NET and have still not patched or
fixed it - upload a 1 MB file and it takes 3 MB - 100% reproducible using my
code or Microsoft's.

As far as my code being bad, it is kinda hard to have an error in a single
line of code.

Dim mattach As New MailAttachment("c:\temp\temp.pdf")

The above line does NOT work. I quote from the Microsoft docs for the
constructor;

"Initializes a new instance of the MailAttachment class with the specified
file name for the attachment. Sets the Encoding property to UUEncode by
default.
Public Sub New(String)"

If you do not specify UUEncode, then the file ends up one byte short of a
load. The following works

Dim mattach As New MailAttachment("c:\temp\temp.pdf", MailEncoding.UUEncode)

although it should be equivalent to the above according to the docs. The
following does NOT work

Dim mattach As New MailAttachment("c:\temp\temp.pdf", MailEncoding.Base64)

It would appear to me that the default is probably MailEncoding.Base64 but
that doesn't seem logical because the default is typically the enum with a
value of 0 which is MailEncoding.UUEncode. The bottom line is that unless
you specify UUEncode (which is supposed to be the default) it doesn't work.
But it is not that simple either. It works "most of the time" if you don't
specify UUEncode (just use the default). It seems to work when sending 100s
of emails with attachments. Seems to have problems when only sending 1
email. I have not been able to determine a pattern. ie - the identical line
of code, identical file, sometimes works, sometimes doesn't, but if you
specify UUEncode, it seems to work all the time.

Russ Stevens
 
Hi Russel,

Based on my understanding, you are using SmtpMail send email with an pdf
attachment, just one of the pdf files has problem(one byte clipped)
I wonder this may be caused by the smtpserver setting.
You may try to take a look at the link below to see if that will help you.
Periods at the Beginning of a Line Are Removed When Placed into the SMTP
Pickup Directory
http://support.microsoft.com/?id=286358

If you have any concern on this issue, please post here.

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,

<<I wonder this may be caused by the smtpserver setting. You may try to take
a look at the link below to see if that will help you. Periods at the
Beginning of a Line Are Removed When Placed into the SMTP Pickup Directory>>

DisablePickupDotStuff - Now that is a strange, obscure setting <g>. However,
I don't think that is the problem. The pdf file doesn't start with a period
and I have the same problem on a Win2K server and my XP development box. It
also doesn't explain why using the attachment constructor with a default of
UUEncode doesn't work but specifically specifying UUEncode does work.

I also think this problem is much more widespread. I have talked to numerous
customers that kept getting corrupt email attachments. I would just have
them do a File, Properties and find that the file was missing a byte. I
always assumed that their email program was at fault. These attachments were
not sent by me, but by others. I now suspect that lots of other people are
experiencing this bug and may not know it.

If you like, I can email you a test file so that you can duplicate the
problem.

Thanks
Russ Stevens
 
Hi Russell,

Since I can not reproduce the problem, I think it is better that you can
send me a test file for me to reproduce the problem.
You may email to me by removing the online from my email address, I will
appreciate your efforts.
Another suggestion, have you tried use microsoft outlook or outlook express
to send the same attachment with the same smtp server as you use in your
code?

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.
 
Hi Russel,

Yes, I can reproduce the problem with your attachment.
After my test, I find that the code line
Dim mattach As New MailAttachment("FullPathToTest.PDF")
will use Base64 by default. You may use the code line below to check it
after the code line above.
Console.WriteLine(mattach.Encoding.ToString())
I have reported the issue. But I can guarantee if it will be fixed in
future.

Have you try to modify the SMTP server setting according to the KB link?
Periods at the Beginning of a Line Are Removed When Placed into the SMTP
Pickup Directory
http://support.microsoft.com/?id=286358

I compare the corrupted pdf file with the well pdf file using a hexadecimal
editor, and I find the different between then is the "." (2E in
hexadecimal).

If you have any question, please post here.

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.
--------------------
 
Back
Top