Email Handler not creating tickets, "ParseException: Expected ';', got ","

Question

Lately we've been seeing a lot of issues with tickets being created from emails.  There seem to be two major culprits according to the log:

#1:

2013-07-19 14:22:07,739 WARN [AetnaEscalationsDM] QuartzWorker-1 ServiceRunner  AetnaEscalationsDM AetnaEscalationsDM[10110]: Unable to create issue with mess
age. javax.mail.internet.ParseException: Expected ';', got ","

It's completely unclear to me where the , it is looking for is, and why it is expecting a semicolon.

#2:

Sender is anonymous, no default reporter specified and creating users is set to false (or external user management is enabled). Message rejected."

This one should be straightforward, but the mails in question are coming from a large variety of users, and the From: field in the emails exactly matches (even down to case) the email of the user in JIRA, and yet the match isn't being made.

Anyone have any ideas?

unknown · Answer

Given you're working on folders logging protocol details probably wont help, but you can certaily enable mail handling logging through JIRA Admin : System / Logging and Profiling section.

To test this is working isnt too hard, create a new incoming mail folder,  under JIRA_HOME/import/mail, refer to that in your mail handler instead, add a file and wait.  If it worked, likely you will get logging detail in atlassian-jira-incoming-mail.log and the file will be deleted, indicating success.  Check the related target project as well to see if an issue got created.  If a problem occurred, check the logs.

Repeat until you locate a problem.  Eventially you will find the user that does not match the pattern above and it will fail, the cause should then be obvious.

Understand what the error is telling you, JIRA is say the 'JIRA' user sender is: <null>, meaning, it doesnt have one, meaning it couldn't lookup a user with whatever the email address was.

The logging will contain the answers.

Michael Pureka · Answer

These emails are being read from a folder structure, so I am viewing them in Plain Text, not in outlook.   And there are a LOT of them, from different users, so the issue doesn't seem to be with just one specific email address or user.  In fact, it's not clear to me at this point whether JIRA is successfully importing any emails at all, which is very strange, since this was working not all that long ago.  Initially I was inclined to blame this on our having upgraded versions of JIRA, but the problem appears to predate that if the datestamps of emails that haven't been processed are any indication.

The syntax for the From line in any of these text-file emails is:

From: "Jane Doe" <jdoe@domain.net>

Nothing particularly nonstandard about it, and as mentioned, all of the email addresses I've checked match flawlessly against JIRA User emails.  This is plaintext to plaintext - I have the original emails that JIRA is attempting to process, there's no layer of obfuscation here except how JIRA does its parsing.

Also why would JIRA assert that the sender is "null" if the email address just doesn't match - doesn't it have a specific error for "Hey, jdoe@domain.net doesn't match a user" - that's a radically different fail case from "sender is null".  This is another factor that leads me to expect a parsing error instead of a non-matching email address - I am trusting the error I am receiving.

unknown · Answer

No, not clearly at all.  You provided no clear example of the actual email content, just commentary and logging.  If you dont provide details in your question, please expect un-detailed answers!

Yes, I understand in detail how email addresses get parsed, if if that email address (whos exact content and format remains a mystery) is not standards compliant it wont be parsed (as integral validation of the address will fail), or is not associated (exaclty) with a registered JIRA user then it wont be found, hence the sender would be Null?

I hear you, you believe everything is the same, it should work etc.  But clearly it doesnt, so moving forward, provide some useful refernce material, x out the address content.  BEfore you post two identical pieces of text, consider that what you may see in an email client like Outl$$k is not generally useful.  You will need to examine the mail header, to do so you'll need the problem email.

You could try to get the user to repost the message and see if it happens again, for one.  Failing that, there are a few mail handlers, some even with auditing that archive copies of problem mails, quite handy in situations like this.