Email attachment names

I am adding features to a web app I wrote years ago, and have found the following now:

When adding attachments, (in this instance images), the name must have a space in it to appear correctly in the receiver’s email program if using Mac Mail.

I have replicated this issue, and if the file name has no spaces in it, e.g. “file1.jpg” vs “file 1.jpg” it comes in named as “Mail Attachment”. If I rename the same file with a space it sends and appears correctly. The file is not damaged, as if I save it to the desktop, and add an extension it opens fine.

I have tried adding various MIME types, encoding directives, etc, but no changes.

My iOS devices show the attachments in-line correctly.

Incidentally, the images are not displayed in-line in Mac Mail, but as attached files.

This behaviour may exist in desktop apps, also, but I haven’t tested that.

Has anyone any ideas of what causes this to happen, or how to correct the issue without renaming images prior to sending?

Cheers.
Bobby

Nope, have never seen this. My attachments show up just fine without space in a desktop app. How do you send the mails (code please)? Also please post the relevant section of the source of the mail.

I am building on the ImageUploader example project, to test out the bits and pieces before putting into my existing program.

The list of available files is in a list box. Here is the code that sends the email. (I have left out the bit showing the server, etc.)

For i = 0 to UploadedPictureList.RowCount -1
If UploadedPictureList.Cell(i,1) = “X” Then
picPath = UploadedPictureList.RowTag(i)
file = new EmailAttachment
mail.bodyPlainText = mail.bodyPlainText + " - " + PicPath
mail.bodyHTML = mail.bodyHTML + " - " + PicPath
file.LoadFromFile GetFolderItem(picPath)
mail.attachments.append file

End If

Next I

// send the email
UploadPage.MailSocket.messages.append mail
UploadPage.MailSocket.sendMail

If UploadPage.MailSocket.LastErrorCode = 0 Then
MsgBox (“Sent”)
Else
MsgBox (“There was an error sending this attachment. Please try again.”)
End If

That looks good. And the source of the mail?

There seems to be a bug in Xojo 2015r4 in regard to attachment names. See https://forum.xojo.com/30366-email-s-attachments-showed-in-outlook-2013-as-dat .

The source of the email is totally from within the app. The user clicks on a row(s) with an image name, and the row shows an “X” in a cell to denote selection. The loop just goes through and grabs though, and sends “me” the email, with the attachment. There is nothing weird added into the body. I put the file path into the body, just when I was testing another error… but that isn’t even really needed.

Is that what you are asking?

Add a line before you send your mail

dim temp as string = mail.Source

Now view temp in the debugger and post the section with the attachment like

Content-Type: application/gzip; name=“Session_Log_2016-02-11_14-28-52.txt.gz”; name*=utf-8’‘Session_Log_2016-02-11_14-28-52.txt.gz
x-mac-type=“00000000”
x-mac-creator=“00000000”
Content-transfer-encoding: Base64
Content-disposition: attachment; filename=“Session_Log_2016-02-11_14-28-52.txt.gz”; filename*=utf-8’'Session_Log_2016-02-11_14-28-52.txt.gz

I’ll change the program to allow me to run it locally and check that, and come back to you. (Currently it is running on one of my production servers, and not on the machine with the debugger.

Cheers.

I have put a text box in and displayed the source in that box.

You can test, and use your own email address, if you like, and it will send to you.

http://www.techternatives.com/cgi-bin/ImageUploader/imageuploader.cgi

Thanks for the assist.

Here is the relevant part:

Content-Type: application/base64; name=“Paris.jpg”; name*=utf-8’‘Paris.jpg
x-mac-type=“3F3F3F3F”
x-mac-creator=“3F3F3F3F”
Content-transfer-encoding: Base64
Content-disposition: attachment; filename=“Paris.jpg”; filename*=utf-8’'Paris.jpg

And, yep, it looks exactly like the bug I found (42655). Please add your information and your vote.

My attachments also sometimes came in differently. Using Mac mail as client.

Although the attachment itself was fine, the name could be something like:

utf-8"test.html

Putting a simple str() around the name parameter (which was already a string by the way) seems to have solved it…

Correction. Nope. It was one of those sometimes lucky moments.

That lovely tiny bug still isn’t fixed. You can use curl (directly or with mbs) or the chilkat plugin to send attachments with proper names.