When configuring JIRA to create issues based on incoming emails, if an email contains an attachment that is itself an email (usually with ".eml" extension and content-type "message/rfc822"), this attachment will be dropped and not attached to the resultant issue. Here is an example of headers possibly encountered:

------=_NextPart_000_0017_01C759BA.AD6C8D30
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment

This was done because in some mail clients, when a user replies to a message thread, the mail client can be set to include the previously sent message(s) from that thread as an attachment. So, to avoid attaching unnecessary messages to JIRA issues, these attachments are dropped. However, this hinders the other main use case, that is, when users are forwarding an arbitrary email as an attachment as part of a new email which is to be picked up by JIRA.

There are also reported problems when doing similar attaching using Thunderbird. Under certain situations, Thunderbird will set the content type of the attached message to "application/octet-stream". If the attached message happens to have a long name, such that the name is split up over multiple header lines, as dictated by RFC 2231, this will cause the attached message to be dropped. Here is an example of possible headers:

--------------030108010505010604040402
Content-Type: application/octet-stream;
 name*0="SUPPORT+Updated+(JSP-9445)+get+warning+message+when+issue+is+cre";
 name*1="ated+from+e-mail+attachment+not+added.msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="SUPPORT+Updated+(JSP-9445)+get+warning+message+when+issue+is";
 filename*1="+created+from+e-mail+attachment+not+added.msg"

This is due to JavaMail not being able to parse the filename correctly (JIRA will not attach an attachment with a null filename).