7 Replies Latest reply on Jan 25, 2008 5:23 PM by sandy_brydon

    inline image email attachment

    sandy_brydon

      i'm am resurrecting my old post http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100391#4100391
      which i got little traction (probably because i just hung it off another chain).

      ----------------

      I am having trouble with how an inline attachment is supposed to work since it doesn't seem to be creating a boundary with Content-Type: multipart/related around the attachment, it merely relies on the outer multipart/mixed boundary defined in the header of the email.

      The effect is that my email client (Thunderbird) is treating the image as an attachment and is not placing it inline.

      ...
      <m:attachment
       value="#{emailService.params.get('img_logo')}"
       fileName="logo.gif"
       status="logo"
       disposition="inline" />
      <img src="cid:#{logo.contentId}" alt="logo" />
      ...
      


      (the attachment value references a java.net.URL - i doubt this matters, but just in case)

      everything else appears to be correct:
      - the header for the logo:

      Content-Type: image/gif; charset=ISO-8859-1; name=logo.gif
      Content-Transfer-Encoding: base64
      Content-ID: <ckgkyystehilrvoyfavc>
      Content-Disposition: inline; filename=logo.gif
      


      - the corresponding img tag:

      <img src="cid:ckgkyystehilrvoyfavc" alt="logo" />
      


      is this incorrect? perhaps i have misconfigured something?

      jboss-4.2.1.GA
      jboss-seam-2.0.0.CR3

        • 1. Re: inline image email attachment
          pmuir

          Ok. Update to Seam 2.0.1 (I don't think anything has changed, but its worth a try). Create a JIRA issue. If you can post an example of (the email source) what it looks like now and what it should look like that would be great!

          • 2. Re: inline image email attachment
            sandy_brydon

            I have now tried with Seam 2.0.1.CR1 with the same results.

            here is what is happening (i'll include all this stuff in the JIRA ticket as well):

            Header...
            Content-Type: multipart/mixed; boundary="outer-boundary"
            
            --outer-boundary
            Content-Type: image/gif; charset=ISO-8859-1; name=logo.gif
            Content-Transfer-Encoding: base64
            Content-ID: <image-content-id>
            Content-Disposition: inline; filename=logo.gif
            
            BASE64=ENCODED=IMAGE=DATA==
            --outer-boundary
            Content-Type: multipart/alternative; boundary="inner-boundary"
            Content-Disposition: inline
            
            --inner-boundary
            Content-Type: text/plain; charset=ISO-8859-1
            Content-Transfer-Encoding: 7bit
            Content-Disposition: inline
            
            my plain text
            --inner-boundary
            Content-Type: text/html; charset=ISO-8859-1
            Content-Transfer-Encoding: 7bit
            Content-Disposition: inline
            <html>
             <body>
             my html text<br />
             <img src="cid:image-content-id" />
             </body>
            </html>
            --inner-boundary--
            
            --outer-boundary--
            


            and here is how it looks like the boundaries/content types need to be set up:

            Header...
            Content-Type: multipart/alternative; boundary="outer-boundary"
            
            --outer-boundary
            Content-Type: text/plain; charset=ISO-8859-1
            Content-Transfer-Encoding: 7bit
            
            my plain text
            --outer-boundary
            Content-Type: multipart/related;
             boundary="inner-boundary"
            
            --inner-boundary
            Content-Type: text/html; charset=ISO-8859-1
            Content-Transfer-Encoding: 7bit
            <html>
             <body>
             my html text<br />
             <img src="cid:image-content-id" />
             </body>
            </html>
            --inner-boundary
            Content-Type: image/gif; name="logo.gif"
            Content-Transfer-Encoding: base64
            Content-ID: <image-content-id>
            Content-Disposition: inline; filename="logo.gif"
            
            BASE64=ENCODED=IMAGE=DATA==
            --inner-boundary--
            
            --outer-boundary--
            


            it's a bit hard to read so i'll summarize:
            - it looks like Content-Disposition: inline; is on every content declaration, i don't know if this matters
            - in order to have proper inline html image content it looks like both the file and the content it's being included in is required to be part of Content-Type: multipart/related; http://tools.ietf.org/html/rfc2387



            • 3. Re: inline image email attachment
              sandy_brydon

              now tested with Seam 2.0.1.CR2

              • 4. Re: inline image email attachment
                sandy_brydon

                symptoms as tested:

                Mozilla Firefox
                - displays the attached files, does not display inline

                Apple Mail
                - displays the attached files then the content of the email (images show up in both)

                gmail
                - shows as having attachments, prompts to display images - images display fine

                hotmail
                - shows as having attachments, prompts to display images - images display fine

                • 5. Re: inline image email attachment
                  pmuir

                  Excellent info, thanks!

                  As with you, I'm no expert in mail encoding either (it seems a bit of a black art!)

                  • 6. Re: inline image email attachment
                    sandy_brydon

                    jira issue: http://jira.jboss.com/jira/browse/JBSEAM-2534

                    NOTE: above Mozilla Firefox was supposed to be Mozilla Thunderbird (apologies)

                    • 7. Re: inline image email attachment
                      sandy_brydon

                      i blame dark wizards - it's always the dark wizards...