[Resolved] Tickets Randomly Not Being Created From Emails

[davidbann]

Hi there,

I have set OTRS up on Windows 2003 x64. I have a dedicated mail account for clients to send support requests to. There are about 8 aliases for this account in order to manage the queues correctly.

I am finding that many emails are not picked up by OTRS - the emails that are sent are deleted from the support mail account, but no tickets are created. Unfortunately it seems pretty random and I can;t seem to pin point the problem, or even consistently replicate the error - All I know is that I have been running a lot of tests over the past few days, sending a lot of emails to the support mail address. I have made sure that the support mails are in fact arriving in the support inbox by logging onto webmail for the account before OTRS collects it. Then once the cronw job runs, I find that it misses a LOT of mails. It seems to be in spurts - so sometimes when the cronw job runs, it creates tickets, and other times, it just deletes all emails and doesn't create any tickets. I have tried sending to all of the alias addresses as well as directly to the main pop3 address, but I haven;t identified any pattern...

Has anyone ever had this problem? What is the best way to debug this issue? I have checked the cronw logs, but nothing there. Are there any other logs that I can check to get some clues on what is happening?

Note that the mail server is not the server that OTRS is installed on - not sure if this makes a difference though.

[ferrosti]

Set OTRS logging level to debug and have a look at OTRS own log. $OTRSHOME/var/log/somelogfile
OTRS logs every single mail when it is picket up, so it should go into this log.

Secondly, have a look at $OTRSHOME/var/spool whether there are any problem-mails.

[davidbann]

Set OTRS logging level to debug and have a look at OTRS own log. $OTRSHOME/var/log/somelogfile
OTRS logs every single mail when it is picket up, so it should go into this log.

Secondly, have a look at $OTRSHOME/var/spool whether there are any problem-mails.

Thanks a lot - how do I set the logging level to debug?

[davidbann]

I'm not sure what level of logging is currently set, but I have checked the logs and I see that quite often the following error appears:

[Thu Sep 2 17:30:26 2010][Error][Kernel::System::MailAccount::POP3::_Fetch][87] POP3: Can't connect to mail.mailer.domain.com

This is strange, because even though the PostMasterMailbox job runs every 5 minutes, it only gives this error every now and then - sometimes it works fine, and other times it fails. I have tested and noticed that even though I know for a fact that there are emails waiting to be collected, sometimes the log does not reflect any errors, but tickets aren't created either - no logs give any clue as to why the emails have been ignored... Other times, the emails are fetched and I get the following in the log:

[Thu Sep 2 18:38:36 2010][Notice][Kernel::System::Ticket::TicketCreate] New Ticket [2010090282000209/Testing Mail Sy] created (TicketID=66,Queue=Business Administration,Priority=3 normal,State=new)
[Thu Sep 2 18:38:36 2010][Notice][Kernel::System::Ticket::Article::SendAgentNotification] Sent agent 'NewTicket' notification to 'name@domain.com'.
[Thu Sep 2 18:38:38 2010][Notice][Kernel::System::MailAccount::POP3::_Fetch] POP3: Fetched 1 email(s) from support@mailer.domain.com/mail.mailer.domain.com.

I only have one email account set up - seems very strange that this is so random...

[ferrosti]

This seems very strange and I don think this is due to an OTRS bug, rather than some networking issue.

First of all you should disable your PostMaster crontab line and execute this command manually, while having a look at the log.
I know this problem from freemail accounts that don't allow more than one connection every now and then. Or this could be due to some bogus DNS failure ore something.
As soon as you run into this error, have a 'tracert' on your mailservers name.

[davidbann]

Thanks for the response,

I have actually already tried the manual approach, but I have not once found an error or problem with creating a ticket from email when running "C:/PROGRA~2/OTRS/StrawberryPerl/perl/bin/perl.exe C:/PROGRA~2/OTRS/OTRS/bin/PostMasterMailbox.pl" from the command line.

If I leave the cronw job to run this command, then sometimes it misses emails - it deletes them from the pop3 account, but does not create a ticket, and leaves no errors or information in the logs.

I have monitored the pop3 account via webmail to make sure that the emails are in fact being delivered, which they are. I can then see when the emails are deleted from the pop3 account after the cronw job runs automatically, but sometimes new tickets are not created...

Bearing all that in mind, is it still possible that this is caused by a DNS or networking problem?

[ferrosti]

Do you have some email filter setup in the OTRS admin interface?

Do you know the subject or parts of the missing mails, so that you could search for them in OTRS?

[davidbann]

Do you have some email filter setup in the OTRS admin interface?

Do you know the subject or parts of the missing mails, so that you could search for them in OTRS?

I have no email filters setup, and yes I know the contents of the emails - I am currently running tests, and this is not a productions system...

I have tried searching for the "missing" tickets but not found any.

I have now changed the crontab.txt file to exclude running PostMasterMailbox.pl, and rather used Windows Task Scheduler to run it every 5 minutes. So far it hasn't missed any emails, but I will keep testing and let you know the results. If the task scheduler works, then I can only assume that the problem lies with CRONW, and not with the network or with OTRS.

[ferrosti]

I do not assume this error to be part of cronw.
This is due the fact that cronw starts the PostMaster program and then has no more control of it. In case it did not start PostMaster no mails could have been deleted. Well, at least not by this program.

[davidbann]

I have been doing a lot of testing after switching from Cronw to windows task scheduler, and I haven't found any more problems... So the only thing I can point the problem down to is Cronw... There is no other way of explaining it - if cronw is running the post master email processor, then for some reason some emails aren't processed correctly - only deleted, and no new tickets created. If using windows task scheduler all emails are processed and new tickets are always created.

[davidbann]

As a final update to this, I have recently moved my OTRS installation to a new VPS with a new host. After the migration, cronw works perfectly well and all mails are delivered as expected. This is very strange, since the new VPS is almost identical to the old on - both Win2003 64bit, and I have used the exact configurations.

So it looks like I was wrong about cronw - I have no idea what was causing the problem, but there must have been something to do with the old VPS... I have done extensive testing on the new system, and not one lost email...