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:
2013-07-19 14:22:07,739 WARN [AetnaEscalationsDM] QuartzWorker-1 ServiceRunner AetnaEscalationsDM AetnaEscalationsDM: 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.
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?
More info on the "Sender is Anonymous" issue, from the debug log:
2013-07-19 14:48:40,244 DEBUG [IT POP3] QuartzWorker-0 ServiceRunner IT Help Desk The message has been rejected (Sender is anonymous, no default reporter spe cified and creating users is set to false (or external user management is enable d). Message rejected.): From :null, Subject: Excel file size issue, Date:
I don't understand where it's getting the "From :null" - the message clearly has a From: field. Could it be parsing it wrong somehow and looking at the wrong place in the mail? I do note that the Debug log of the mail itself cuts off before it gets to the From field, but considering it cuts out mid-line, that's just a character limit on the log and not the email handler only reading half the message.
Unfortunately, this is absolutely not correct; As I pointed out in my original question, the message clearly DOES have a from field that clearly does contain an email address that MATCHES a JIRA user. I copy/pasted both the address from the mail and the address from JIRA into a text editor so I could view them one above the other, and they are exactly the same.
I don't want to assign a default reporter - this does not resolve my issue. The problem is that for some reason, JIRA is not parsing the "From" address out of mail correctly, because it is coming up with "Null" when there is in fact an address present in the mail. Any idea how this gets parsed?
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.
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" <firstname.lastname@example.org>
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, email@example.com 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.
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot