I’m creating an email message using CDO object (and VB6, but that doesn’t really matter).
With New CDO.Message .To = '<address>' .Subject = 'Manifest test 8' .Organization = '<company>' .From = '<address>' .Sender = .From With .Configuration .Fields(cdoSendUsingMethod).Value = cdoSendUsingPort .Fields(cdoSMTPServer).Value = '192.168.0.4' .Fields.Update End With With .AddAttachment('c:\import\customermanifestOURACCOUNT11122008110032.dat') .Fields(cdoContentDisposition).Value = 'attachment; filename=''Consignor.dat''' .Fields.Update End With .Send End With
As you can see, the message is empty and contains an attachment that I rename in the email.
The attachment is an ASCII text file, fixed-width, that contains some output from our systems, one record per line, separated with CRLF.
When the message gets sent, all CRs get stripped out the attachment, so the receiver gets a file that only has LFs and therefore is corrupted.
I tried to change ContentEncoding to 7bit and base64, didn’t work.
I tried to set ContentMediaType for the attachment to text/plain, didn’t work.
I tried to not rename the attachment after adding, didn’t work.
The ContentMediaType for the attachment is set to application/octet-stream by default, so I can’t figure out why (and by what) it gets changed in the first place.
If I execute .SaveToFile() on the attachment right after .Send(), it saves valid file on the disk.
Is this a problem in my code, or is it a mail server setting or something?
Ok, that was weird.
We used our gmail accounts to test that thing, more specifically, gmail web interface. We clicked attachments links to save reveived files. And the files were corrupted.
As soon as we instead tried some thick clients, it turned out to be fine. All files get download properly without any corruptions.
So I assume this is a bug in gmail web interface (as opposed to gmail POP3 interface).