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 => “”, :subject => “”)
end

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

On Friday, July 22, 2011 5:27:18 AM UTC-6, Ruby-Forum.com User wrote:

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.

On Monday, July 25, 2011 1:05:35 AM UTC-6, Ruby-Forum.com User wrote:

X-Mozilla-Keys:
Content-Type: multipart/mixed;
----==_mimepart_4e2d13c67e1f9_f802f425a49071a

----==_mimepart_4e2d13c67e1f9_f802f425a49071a–

Look correct, right?

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?

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


From - Mon Jul 25 08:57:15 2011
X-Account-Key: …
X-UIDL: …
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Return-Path:
Delivery-Date: Mon, 25 Jul 2011 08:56:34 +0200
Received: <…>
Received: <…>
Date: Mon, 25 Jul 2011 08:57:10 +0200
From:
To:
Message-ID:
Subject:
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="–==_mimepart_4e2d13c67e1f9_f802f425a49071a";
charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:4sH+tl1KaCL9J0SiYZeTkVUH/mKVAi7kbImpVvQUvpK
v0S8xsUin+u9FXoHrGUSYSxJ6dVCFMI4XJOEjQ/u372LWpLWBP
XeT8gpckabGQClzxkFStLW8YqOC1otjEwhz8i7xjzdRUCy9fdh
Ij9wIq5taa9KEoR4vXlLdEBwxB6u6w7s4lCt2XTftaCGGP6y/A
z4rvh0KMtlQiuv3U71BXdHT8rFD2gjTHZMLE8xE1lE=
Envelope-To:

----==_mimepart_4e2d13c67e1f9_f802f425a49071a
Date: Mon, 25 Jul 2011 08:57:10 +0200
Mime-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID:


****

----==_mimepart_4e2d13c67e1f9_f802f425a49071a
Date: Mon, 25 Jul 2011 08:57:10 +0200
Mime-Version: 1.0
Content-Type: application/pdf;
charset=UTF-8;
filename=
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=
Content-ID:

----==_mimepart_4e2d13c67e1f9_f802f425a49071a–

Look correct, right?

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?

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

On Wednesday, July 27, 2011 4:03:03 AM UTC-6, Ruby-Forum.com User wrote:

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.

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

On Thu, Jul 28, 2011 at 8:02 AM, Damien K. [email protected]
wrote:

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.


Kendall G.