rails mailer and attachments

i got a problem with rails achtionmailer 3.0.7.

when i send a email with attachment, sometimes the attachment is not
displayed as such and is not be found in the email, but the size of the
email is still big (as with attachment). it's probably hidden base64
encoded in the sourcecode.

now the hard part. i only got this information from customers and cannot
stage this error in my development environment.

my code is quite easy:

def offer(docs = [])
  # attach files
  docs.compact.each do |document|
    attachments[document.filename] = File.open(document.url, 'rb')
{|file| file.read} ## I need to read 'rb' because i am on a win-server
  end

  mail(:to => "<email>", :subject => "<subject>")
end

any suggestions? how can i assure, that the attachment will be
displayed?
the attachments are always pdfs (if thats somehow important).

i got a problem with rails achtionmailer 3.0.7.
when i send a email with attachment, sometimes the attachment is not
displayed as such and is not be found in the email, but the size of the
email is still big (as with attachment). it’s probably hidden base64
encoded in the sourcecode.

now the hard part. i only got this information from customers and cannot
stage this error in my development environment.

my code is quite easy:

def offer(docs = [])

attach files

docs.compact.each do |document|
attachments[document.filename] = File.open(document.url, ‘rb’)
{|file| file.read} ## I need to read ‘rb’ because i am on a win-server
end

mail(:to => “”, :subject => “”)
end

any suggestions? how can i assure, that the attachment will be
displayed?
the attachments are always pdfs (if thats somehow important).


Posted via http://www.ruby-forum.com/.

The attachment is most likely there. It’s likely not displayed by the client due to the way the actionmailer and/or mail gem structured the email (in terms of the “multipart/*” hierarchy). Some clients are pickier than others and won’t display parts (“attachments”) unless the exact, “proper” structure is followed.

To be sure this is the problem, however, you need to open the email in a text editor and sketch out the structure of its parts. For example, a typical email (w/a text and html part) with a file attachment and some inline images (displayed by the HTML) might look like:

  • Main email: multipart/mixed

    First part: multipart/alternative

    • First sub-part: text/plain (text version of email)
    • Second sub-part: multipart/related (container for html part)
      • First sub-sub-part: text/html
      • Second sub-sub-part: image/png (displayed in html using cid reference)
      • Third sub-sub-part: image/jpeg (ditto)

    Second part: application/pdf (attached PDF file)
    Third part: image/jpeg (attached image file)

The above structure is tried and true and displays in most (all?) email clients (yes, I’ve had this issue before and hand-coded my own wrapper around the mail gem to guarantee this structure; we’ve tested it in Outlook, Outlook Express, Thunderbird, Evolution, Gmail, Roundcube, …etc.).

Now, if you’ve got a plain-text only email the structure can (and should) be much simpler.

Let us know what the structure is and we can tell you if this is your problem or not.

Thank you for your answer. i opened my email in thunderbird => view
sourcecode (hope that shows everything):

Sorry for not responding for so long. Yes, the message looks fine. In fact, I copies/pasted the text you provided into a text file (and added in some dummy data in the <…> placeholders) and saved it w/an *.eml extension. When I opened it with Thunderbird (in a Windows XP virtual machine) it displayed the attachment just fine. I’ve attached a screen shot showing this.

Which email client isn’t showing this message correctly?

thunderbird.png

thanks for all your work.

"Which email client *isn't* showing this message correctly?"

that's the hard part. my clients (VERY few of them) sometimes just say:
"we didnt receive any attachments"

but i am guessing that they are using some standard clients. because
when i send the same pdf with thunderbird to them, they receive it.

any ideas?

The last idea is that some clients might not like having a “Date” header in each message part since, technically, I think there should only be a “Date” header in the main email message (not sure though, did a quick scan of some email/multi-part RFCs but couldn’t find anything definitive). Regardless of what the “standard” is, though, some clients may be choking because of the non-“Content-X” headers in the multi-part sections (possibly including the “Mime-Version” headers).

Anyhow, just a thought.

so you think, i have to set the mime-type of each attachment
manually/explicitly?

No.

First off, I’d recommend possibly contacting people in the “Ruby’s Mail Discussion Group”

https://groups.google.com/forum/#!forum/mail-ruby

I was saying that the problem might be that there are extraneous “Mime-Version” and “Date” headers at the start of each of the 2 parts of the multi-part message. These headers are needed (“Date” is required for all emails and “Mime-Version” is required multi-part messages) at the email message level (the first chunk of headers before the multi-part sections in the body). However, these headers are not needed in the header sections of the individual parts of the multi-part message. My theory is that some clients may (incorrectly) be choking (and not displaying the fact that you’ve got an attachment) because of these unnecessary headers.

This is totally a shot in the dark. Without combing through all the email/multi-part/mime RFCs and doing extensive testing of this theory using hand-crafted messages in many email clients, I have no way to verify this.

My actual recommendation to you is that you really see if you can somehow get a communication channel directly to a client that next reports having this problem. My understanding being that your problem is sporadic. I don’t know how your organization/company is setup and/or how many layers/levels of organizational/corporate barriers exist to make this difficult or impossible. But you need to reproduce the problem else all we can do is speculate.

Perhaps you could include a footer/sub-text on messages w/instructions that clients contact a specific email address or phone number if they get an email and they can’t see their attachments? Then have at least a few instances of the next few support requests for this specific problem redirect to you or your development team. Then you could perhaps talk the client through the steps necessary to tell you exactly what type and versions of OS and email client software their running. You could also have them send the broken message to you by forwarding it as an attachment.

Then you can extract the message and set up a test environment w/the broken email client software and verify that the forwarded email doesn’t “work” in said client. At this point, using a simple text editor, you could then test theories as to why its broken by making a series of changes (keeping the original) one at a time to the email and opening it in the broken client until you isolate the exact aspect of the message causing the client to not display the attachment.

Only then, once you know what the real problem is, can you get advice as to what to do using actionmailer and the mail gem to send emails that won’t have the attachment problem.

I sympathize with you. I basically had a very similar problem and had to solve it for my company using this technique. However, my problem had to do with Thunderbird not liking the default way the hierarchy of “parts” in our multi-part messages (as created by the mail gem using the most obvious message construction code) were constructed/organized. Your example, however, was a simple “multipart/mixed” mixed message w/a text part and an attachment. If this is how all your messages are structured (no “multipart/alternative” stuff) then you’ve got a different problem that me.

Hope you find what the problem is.

wow, thank you for your (long and detailed) answer. i will try it your
way. and yes its really sporadic (i guess 3 - 5 problems in maybe 9000+
emails).

if i have any further hints on whats wrong i will get back to you (if i
may) or the mail group.

thanks again