All,
There is a problem with ActionMailer not being able to send emails with
inline images - this doesn''t seem to be fixed in the trunk, and
there''s
an outstanding ticket:
http://dev.rubyonrails.com/ticket/2179
I''ve been looking into this today because it''s something I
needed to be
able to do, and I seem to have got it working. This is almost certainly
a bodge (I''m no Rails or MIME expert).
If there are more experienced rails developers than me who can take
this and make a patch from it, go for it. I don''t have the time right
now to do the patch and the tests, alas.
The aim for me was to be able to do things like this:
inline_attachment :content_type => "image/jpeg",
:body => File.read("#{RAILS_ROOT}/public/images/bg.jpg"),
:filename=>"bg.jpg",
:cid =>
''<cid.bg-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org>''
The problem as described in the ticket, that ActionMailer::Part#to_mail
does not cope with inline elements that have a filename, nor does it
send headers attached to message parts.
I''ve added code to the ticket which makes this possible, and implements
inline_attachment().
If anyone is interested enough to try it out, and perhaps create a
patch, that''d be great.
Mike
In article <89043ad2a1ea6ff768e67a2135e0dc57-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org>, mike-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org says...> The aim for me was to be able to do things like this: > > inline_attachment :content_type => "image/jpeg", > :body => File.read("#{RAILS_ROOT}/public/images/bg.jpg"), > :filename=>"bg.jpg", > :cid => ''<cid.bg-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org>'' > > > The problem as described in the ticket, that ActionMailer::Part#to_mail > does not cope with inline elements that have a filename, nor does it > send headers attached to message parts.I haven''t looked at the ActionMailer code, but I''d avoid calling it "inline_attachment"; when we were creating M/HTML, the intent was to have a series of parts, some of which might be inline, and some of which might be attachments. That''s still communicated today via Content- Disposition: Inline or Content-Disposition: Attachment, but clients like Outlook Express tend to blur the line, "helpfully" displaying any images inline, no matter how the sender intended them! But I digress... "inline" and "attachment" are two opposite dispositions of a MIME part, which (MIME-wise) should really only differ by the Content-Disposition: header - if I were implementing them from scratch, I''d probably make both wrappers around "part". Sadly, "part" already means "inline_part" in Rails, but other than that, if something else is going on in ActionMailer, it''s not following MIME semantics. Is there a reason the problem can''t be solved by adding :filename to "part", and allowing it to send headers properly? -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler
On 10 Oct 2005, at 00:28, Jay Levitt wrote:> I haven''t looked at the ActionMailer code, but I''d avoid calling it > "inline_attachment"; when we were creating M/HTML, the intent was to > have a series of parts, some of which might be inline, and some of > which > might be attachments.Right - ActionMailer defines a container method called ''part'' for describing inline content parts (text, html parts), and a method ''attachment'' for defining attachment files. ''inline_attachment'' was the suggestion in the implementation plan in the ticket, that''s all.> That''s still communicated today via Content- > Disposition: Inline or Content-Disposition: Attachment, but clients > like > Outlook Express tend to blur the line, "helpfully" displaying any > images > inline, no matter how the sender intended them!That is what this method is trying to set, correctly, yes.> But I digress... "inline" and "attachment" are two opposite > dispositions > of a MIME part, which (MIME-wise) should really only differ by the > Content-Disposition: header - if I were implementing them from scratch, > I''d probably make both wrappers around "part".They are, effectively.> Sadly, "part" already > means "inline_part" in Rails, but other than that, if something else is > going on in ActionMailer, it''s not following MIME semantics. Is there > a > reason the problem can''t be solved by adding :filename to "part", and > allowing it to send headers properly?There isn''t - inline_attachment, like attachment, is merely a wrapper to the ''part'' container method itself, so: inline_attachment :content_type => "image/jpeg", :body => File.read("#{RAILS_ROOT}/public/images/bg.jpg"), :filename=>"bg.jpg", :cid => ''<cid.bg-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org>'' is equivalent to: part :content_type => "image/jpeg", :body => File.read("#{RAILS_ROOT}/public/images/bg.jpg"), :filename => "bg.jpg", :transfer_encoding => ''base64'', :headers => {''Content-ID'' => ''<cid.bg-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org>''} So it could be done away with entirely, or as it''s just a convenience method, given a fluffier name. To my mind there''s a case for a really fluffy ''inline_image'' method that takes a file path, and sorts out :filename, :body, :transfer_encoding _and_ the Content-ID header. Now, if only the part and attachment methods could co-exist with the neat template autodetection stuff, I''d be even happier. Mike
In article <c8102874e04ee04bbe67df1307e91b1d-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org>, mike-GDRLylaSUshUrdklU0bPTip2UmYkHbXO@public.gmane.org says...> > I haven''t looked at the ActionMailer code, but I''d avoid calling it > > "inline_attachment"; when we were creating M/HTML, the intent was to > > have a series of parts, some of which might be inline, and some of > > which > > might be attachments. > > Right - ActionMailer defines a container method called ''part'' for > describing inline content parts (text, html parts), and a method > ''attachment'' > for defining attachment files.Yes, but the inline_attachment name seems imply that an image or other binary file is always an attachment. My disagreement is that "inline vs. attachment" (dispositions) and "text vs. binary" (content types) are orthogonal distinctions. Inline parts are displayed inline, and attachments are displayed separately. An image part can be inline, or it can be an attachment. Ditto for any text part. No given part can be both inline AND an attachment, so the name "inline_attachment" is an oxymoron. Maybe "inline_binary_part"? I actually think your instincts are right - the "fluffy" inline_image function is a lot more useful than the generic "inline_attachment", which is really just one-and-a-half parameters away from "part"; that''s not quite a good mapping onto MIME, and not a direct mapping onto the way an app wants to use it either. -- Jay Levitt | Wellesley, MA | I feel calm. I feel ready. I can only Faster: jay at jay dot fm | conclude that''s because I don''t have a http://www.jay.fm | full grasp of the situation. - Mark Adler