Archived Forum Post

Index of archived forum posts


Zeros padded at the end of attachment

Mar 26 '14 at 05:36

I am using the MailMan and the Mime components to send encrypted and signed e-mail with an attachment. This has worked fine for several customers and in the test system for the customer in question.

Now we have gone into production and here we are using a new set of certificates for encryption and signing. The e-mails are sent without any problems. However, the recipient of the e-mails now reports that some of the attachments are padded with a lot of zeros (the example file I got is originally about 560kb, but what they get is about 970kb with 410kb of zeros).

All customers are communicating with the exact same system using the same software, so it's difficult to understand what's going on. I can see that the .eml file which we create (this is written to file just before we send it) is actually bigger than .eml-files created with bigger attachment files from other customers. This means that the problem is probably on our side. I don't have access to the certificates and the system we are communicating with, so it's hard for me to do any debugging (the system runs abroad within a secure network).

There is a possibility that my stream writer (see below) creates the zeros, but I want to ask if this is something that might have a logic explanation before digging deeper into this.

var msw = new MyStreamWriter();
using (var stream = new MemoryStream())
     msw.WriteToStream(stream, fileRepresentation);
     message.AddDataAttachment(message.Subject, stream.GetBuffer());

But just previous to this code we have used the same class to write it to a file instead of to an attachment, and that file gets the correct size.

Is there anything which can explain this behavior?

This is with ChilkatDotNet4.dll


Test using the latest version of Chilkat (v9.5.0)

Using v9.5.0, examine the contents of the message.LastErrorText after calling AddDataAttachment. It should tell you the exact number of bytes you passed to it. (It will also show the filename you passed to it.) The LastErrorText always contains information, even for success cases -- which is to help understand what happened when the method succeeded, but did not do what was expected.