Forum: Ruby on Rails 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).

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.

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: <EMAIL>
Delivery-Date: Mon, 25 Jul 2011 08:56:34 +0200
Received: <...>
Received: <...>
Date: Mon, 25 Jul 2011 08:57:10 +0200
From: <FROM-EMAIL>
To: <TO-EMAIL>
Message-ID: <ID>
Subject: <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: <EMAIL>



----==_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: <ID>

****
<PLAIN TEXT>
****



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

<base64 ENCODED CONTENT OF PDF>


----==_mimepart_4e2d13c67e1f9_f802f425a49071a--




Look correct, right?

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
>
>
> <base64 ENCODED CONTENT OF PDF>
>
>
> ----==_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?

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?

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.

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

On Thu, Jul 28, 2011 at 8:02 AM, Damien Knight <lists@ruby-forum.com> 
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 Gifford

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