After investigating this issue further, I have identified several distinct issues that have over time stemmed from the original issue - the original issue being: the loss of one or more parts of an email message (content or attachments) when trying to create JIRA issues from emails. The original issue has been resolved in part by Jeff, but under certain situations, JIRA logs may still report the following warning:

WARN [jira.issue.managers.DefaultAttachmentManager] Cannot create attachment without a filename - inline content? See http://jira.atlassian.com/browse/JRA-10825 (file=tempattach51383dat).

It should be known that this is largely benign - it simply means that while processing the email message, some parts of it were flagged as being required to be attached to the JIRA issue, but no filename for the attachment could be determined. The most common scenario of this happening is when you have an email message in both plain and rich text format; JIRA attempts attach the rich text part, but it does not have a filename, and so this fails. In this case, the effect is minimal, as the meaning of the message is usually conveyed through the plain text part anyway.

If however, you are finding that JIRA is still losing important parts of your messages, as what appeared to be the case for Bruno, please feel free to raise a support case at http://support.atlassian.com, providing examples of email messages that will reproduce the issue.

The following are the known and reproducible issues that stemmed from this issue that are still open:

• JRA-12525 - Emails containing attachments with non-ASCII names lost
• JRA-10827 - Capture (HTML) emails in their original format
• JRA-12534 - JIRA fails to add attachments with long filenames from RFC 2231-compliant mail clients

The following have been resolved:

• JRA-12530 - Renamed email attachments lose extension
• JRA-15133 - "message" type attachments get lost when creating issues from emails

Cheers,
Michael Tokar [Atlassian]

This issue has a long history, and over time, several issues have been discussed which could be separated out into distinct problems. It also makes it hard to identify what specific problem each of you is having when you do not reference a relevant comment. For this reason, I have split one of the previously discussed issues into a new issue.

If you are suffering from the problem Andreas describes in this comment, could you please now follow this cloned issue instead: JRA-15133. For clarity, the problem I am referring to is the matter of attaching .eml or .msg files as attachments, which do not get attached to created issues by JIRA.

Investigations into a fix for JRA-15133 have begun, so please make sure you watch that issue for any updates.

Thanks for your patience!

Regards,
Michael Tokar [Atlassian]

I have just encountered this and it is going to kill me dead-in-the-water. Being able to process emails is key to our system. What is happening here.

http://jira.atlassian.com/browse/JRA-10825

Hello guys,

I am also experiencing the problem. We often get mails forwarded from our customers - as attachements. Is there a suitable workaround for that problem like maybe forwarding all mails with email-attachements to a generic address or something?

Best regards,
Andy

Is there a work-around for this issue? I cleared about 75,000 copies of the broken attachment this morning. Luckily it's only 23kb in sze.

Example of the emtpy tickets

We are using 3.9.1 Enterprise and are having the same issues as described above.

Steps I have taken (from JRA-12525):

• updated to JavaMail 1.4 and enabled -Dmail.mime.decodeparameters=true on startup
• sending emails from Mail.app in rich text or plain text

Our scenario is that emails go first through mailman and then reach Jira (the IMAP account that Jira checks is subscribed to some of those lists).

Our tickets get to Jira but the body of the email is empty, just has the default Mailman signature that's added at the bottom of the emails (I've added a screenshot).

Looking at the logs, I see (with the logs enabled, note, I've edited it a bit for presentation, just inserted carriage returns)

A27 FETCH 2 (BODYSTRUCTURE)
* 2 FETCH (BODYSTRUCTURE ((("text" "plain" ("charset" "ISO-8859-1" "format" "flowed")
        NIL NIL "quoted-printable" 235 15 NIL NIL NIL)
        ("application" "pgp-signature" ("x-mac-type" "70674453" "name" "PGP.sig") 
        NIL "This is a digitally signed message part" "7bit" 169 NIL ("inline" ("filename" "PGP.sig")) NIL) 
        "signed" ("protocol" "application/pgp-signature" "micalg" "pgp-sha1" "boundary" 
         "Apple-Mail-4-120089029") NIL NIL)("text" "plain" ("charset" "us-ascii") NIL NIL 
         "7bit" 141 4 NIL ("inline" NIL) NIL) "mixed" ("boundary" "===============0103440808==") NIL NIL))
A27 OK Fetch completed.
A28 FETCH 2 (BODY[2]<0.141>)
* 2 FETCH (FLAGS (\Seen \Recent) BODY[2]<0> {141}
_______________________________________________
Finance mailing list
Finance@rsp.com.au
http://lists.rsp.com.au/mailman/listinfo/finance
)
A28 OK Fetch completed.
A29 FETCH 2 (BODY[2]<0.141>)
* 2 FETCH (BODY[2]<0> {141}
_______________________________________________
Finance mailing list
Finance@rsp.com.au
http://lists.rsp.com.au/mailman/listinfo/finance
)
A29 OK Fetch completed.
A30 FETCH 2 (BODY[1.1]<0.235>)
* 2 FETCH (BODY[1.1]<0> {235}
Sorry

thanks you

?B

=E9

--=20
bruno mattarollo
chief technology officer | bruno.mattarollo@rsp.com.au
rising sun pictures - http://www.rsp.com.au/

gpg fingerprint: 65A6 C94A 1978 9B42 6ED2 FBCE 1BD2 756B 3A80 D8FC

)
A30 OK Fetch completed.
A31 FETCH 2 (BODY[1.2]<0.169>)
* 2 FETCH (BODY[1.2]<0> {169}
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkbc4TAACgkQG9J1azqA2PwIQgCgq4/cZNqS5UgQfmJqYlofwkW+
agIAn1GIkQlomuwEGXt9CuLIWlgKn965
=AfAt
-----END PGP SIGNATURE-----
)
A31 OK Fetch completed.
2007-09-04 14:39:09,883 JiraQuartzScheduler_Worker-1 WARN [jira.issue.managers.DefaultAttachmentManager] 
   Cannot create attachment without a filename - inline content? See http://jira.atlassian.com/browse/JRA-10825 
(file=tempattach51383dat).

I am a bit at a loss on what to do here ... emails from Mailman are not, AFAIK, illegal in their format ...

Using 3.9.1 Enterprise.
I also get this message:

2007-06-22 13:08:37,275 JiraQuartzScheduler_Worker-0 WARN [jira.issue.managers.DefaultAttachmentManager] Cannot create attachment without a filename - inline content? See http://jira.atlassian.com/browse/JRA-10825 (file=tempattach10344dat). 

for email without attachments.

We want to attack the email bugs as a cluster so this will be scheduled once we can dedicate the resources to get the email bugs we have out of the way.

Another possible cause is that the attachment name is too long, and JavaMail can't handle it (another RFC 2231 violation, but this time without an easy fix). See JRA-12534

Note for users experiencing this problem

The most likely cause of disappearing attachments and log errors like:

WARN [jira.issue.managers.DefaultAttachmentManager] Cannot create attachment without a filename - inline content? See http://jira.atlassian.com/browse/JRA-10825 (file=tempattach52584dat).

is that JIRA has received an email with RFC 2231-encoded attachment names, from mail clients like Thunderbird, Opera and KMail. The fix is to enable RFC 2231 parsing, as described in this JIRA bug report.

This issue should now only affect customers trying to attach *.msg messages to an e-mail in Outlook. The problem is that when attaching a mail message to a mail sent from Outlook, the content headers for this attachment in the mail source will look as follows:

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

This content header is the same if a user has Outlook configured to automatically attach the original mail thread when replying to an e-mail (which is fairly common). This is the reason why JIRA currently doesn't handle attachments of this type. For messages sent from Outlook, we have no way of telling if the attachment is a proper attachment, or simply the e-mail message thread the user replied to. JIRA would end up saving a lot of message threads as attachments, even though users did not intend this to happen.

This is a problem that other e-mail clients also have (when Thunderbird receives an e-mail from Outlook with a *.msg attachment, it displays it both inline and as an attachment, because it also can't determine if it's meant to be an attachment or part of the message thread).

We therefore wont implement a quick fix for this problem, as we'll need to make a design decision about how we can best handle this case without ill-affecting all our customers.

Just as a side note: E-mails sent from Thunderbird with *.msg attachments will also not be attached in JIRA if the *.msg file has a long filename. This is because Thunderbird uses RFC2231 compliant headers for long filenames, which the javamail API (which JIRA uses to handle e-mails) currently doesn't handle.

Apparently people are still seeing this with 3.7.2.

I updated to 3.7.2 and can now process my emails. Thank you!

Stewart,

It's a "warning" message, so somewhat benign. One of your mails was pure or partly HTML with the somewhat uncommon multipart/related MIME type, and JIRA didn't know how to handle it.

I hope this is all fixed in 3.7.2, just released, which has the patched atlassian-mail.jar.

BTW the error message above was only received once, and then did not repeat itself. And did import the messages. So I'm happy.

hi, I'm also evaluating JIRA and am also getting the same message as Kevin Kuphal:

"2007-01-16 17:29:01,778 JiraQuartzScheduler_Worker-3 WARN [jira.issue.managers.DefaultAttachmentManager] Cannot create attachment without a filename - inline content? See http://jira.atlassian.com/browse/JRA-10825 (file=tempattach39625dat)."

BUT messages that were in the POP account and IMAP account that I was monitoring have now appeared in JIRA. So perhaps the error message is benign?

BTW, I think it's EXCELLENT that you are able to include an actual issue-tracker bug ID number right in the error code; that certainly makes it easy to track down the nature of the problem. Kudos on that!

cheers
S

Is there any fix for this issues for 3.7.1 #185? I am currently evaluating JIRA and I am unable to create tickets automatically from Veritas Backup exec because of this issue:

2007-01-15 15:50:02,628 JiraQuartzScheduler_Worker-2 WARN [jira.issue.managers.DefaultAttachmentManager] Cannot create attachment without a filename - inline content? See http://jira.atlassian.com/browse/JRA-10825 (file=tempattach53997dat).

This has been fixed. Jeff had committed the change to atlassian-mail a while back and the change in JIRA has been in 3.7. We have now upgraded the version of atlassian-mail to include the fix Jeff committed.

We should create a unit test for this.

> 2006-10-01 20:40:23,362 WARN [jira.issue.managers.DefaultAttachmentManager] Creating attachment without a file. Aborting
>
> But multipart emails appear to be creating jira's now although I would like to be 100% sure they're working. Are you sure that the error message would change when the new jar is in use?

Sorry, that change is actually the JIRA code, not in atlassian-mail.jar. It isn't necessary for proper functioning of the patch.

Hi Jeff,

We're running into this same issue with Jira 3.6.5 EE. I replaced the existing atlassian-mail jars (there was one for jira and one for confluence) in the following locations:

[root@jira jira]# find . |grep atlassian-mail
./atlassian-jira/WEB-INF/lib/atlassian-mail-1.3.21.jar
./confluence-old/WEB-INF/lib/atlassian-mail-1.2.14.jar

I replaced both of those with atlassian-mail-1.3.22-DEV-2.jar and restarted jira. In the log file I am still getting the error message:

2006-10-01 20:40:23,362 WARN [jira.issue.managers.DefaultAttachmentManager] Creating attachment without a file. Aborting

But multipart emails appear to be creating jira's now although I would like to be 100% sure they're working. Are you sure that the error message would change when the new jar is in use?

Well, to be honest I didn't actually use your .jar file since I would lose all my customizations. I unzipped it, and placed the modified files in my standalone. No worries.

I've added further fix at:

http://repository.atlassian.com/atlassian-mail/jars/atlassian-mail-1.3.22-DEV-2.jar

> WARN [jira.issue.managers.DefaultAttachmentManager] Creating attachment without a file. Aborting

That is the old error. Perhaps you didn't remove the old jar? The new one would say "Cannot create attachment without a filename".

Jeff - FYI, I installed the files from your .jar into my standalone instance, and upon receipt of an email, the log produced this error:

WARN [jira.issue.managers.DefaultAttachmentManager] Creating attachment without a file. Aborting

Although the issue got created, with 2 attachments - one called Outlook.jpg (the in-line attachment) as well as the actual named attachment I had included. On furgher checking, it looks like that warning was there before I installed your change as well.

I have fixed atlassian-mail to not treat "multipart/related; type=text/html" as "text/html", and it now extracts text from the HTML body. I think this is good enough for 3.7.

In future, we should add some explicit handling for multipart/related emails. I've made a separate issue (JRA-10827) for that.

For those experiencing this bug, I have created a patched mail jar at:

http://repository.atlassian.com/atlassian-mail/jars/atlassian-mail-1.3.22-DEV.jar

Please download this and replace the existing atlassian-mail-*.jar with it. Please let us know how you go with it.

It should work with all JIRA 3.6.x releases. It may work with earlier releases (I haven't tested).

In this example, the multipart/related email is a HTML page, with a HTML part and two attachments. The parts are "related" because strictly speaking the images must be displayed inline with the HTML where the <img src="..."> tag occurs.

This happens because in MailUtils.getBody(), we have:

            if (contentType != null && contentType.toLowerCase().indexOf("text/plain") != -1)
                return (String) message.getContent();
            else if (contentType != null && contentType.toLowerCase().indexOf("text/html") != -1)
                return new HtmlToTextConverter().convert((String)message.getContent());

The indexOf("text/html") test matches the 'type' attribute of the multipart/related header, so that part isn't actually a String, and we get a ClassCastException.