Email Ticket Importing suddenly stopped working?

[coreyman]

So email ticket importing was working, but now it's stopped working and I didn't know. No notifications on the dashboards, not seeing any errors. Running the cron manually is successful. Where do I begin troubleshooting this? I've looked in logs_blesta and I don't see anything. I enabled error logging in blesta configuration and ran the cron, no errors. I added the mail accounts manually to my email client to verify the connection details and I can see tons of mails there that aren't in blesta as tickets.

[Paul]

Importing via POP/IMAP?

Does your PHP still have mailparse? It's likely something changed.

Do you see login attempts from Blesta in your mail server's authentication logs?

[coreyman]

On 1/21/2019 at 2:46 PM, Paul said:

Importing via POP/IMAP?

Does your PHP still have mailparse? It's likely something changed.

Do you see login attempts from Blesta in your mail server's authentication logs?

Yes importing via POP/IMAP.

PHP has mailparse -

php -m
[PHP Modules]
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
ionCube Loader
json
libxml
mailparse
mbstring
mcrypt
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zlib

I do see login attempts in the auth logs of my mail server when executing the cron manually.

[Paul]

2 hours ago, coreyman said:

I do see login attempts in the auth logs of my mail server when executing the cron manually.

Are you saying that it works when running the cron manually? Or you see failed authentication logs on your mail server when running the cron manually but not automatically?

If you get different behavior running manually vs automatically, probably your PHP environment via CLI is different than your web server. Do you see anything in the Blesta logs when that task runs? Typically at ../logs_blesta/ but defined under Settings > System > General.

[coreyman]

On 1/24/2019 at 10:34 AM, Paul said:

Are you saying that it works when running the cron manually? Or you see failed authentication logs on your mail server when running the cron manually but not automatically?

If you get different behavior running manually vs automatically, probably your PHP environment via CLI is different than your web server. Do you see anything in the Blesta logs when that task runs? Typically at ../logs_blesta/ but defined under Settings > System > General.

 

I get the following when running the cron -

/usr/bin/php /var/www/xxx/index.php cron
Attempting to run all tasks for BitAccel.
Attempting to apply credits to open invoices.
Attempting to apply credits for client group General.
Completed applying credits for client group General.
There are no invoices to which credits may be applied.
The apply credits task has completed.
Attempting to deliver invoices scheduled for delivery.
No invoices are scheduled to be delivered.
The deliver invoices task has completed.
Attempting to provision paid pending services.
The paid pending services task has completed.
Attempting to unsuspend paid suspended services.
The unsuspend services task has completed.
Attempting to process service changes.
The process service changes task has completed.
Attempting to process renewing services.
The process renewing services task has completed.
Attempting plugin cron for order accept_paid_orders.
Finished plugin cron for order accept_paid_orders.
Attempting plugin cron for support_manager poll_tickets.
Finished plugin cron for support_manager poll_tickets.
Attempting plugin cron for mass_mailer export.
Finished plugin cron for mass_mailer export.
Attempting plugin cron for mass_mailer mass_mail.
Finished plugin cron for mass_mailer mass_mail.
All tasks have been completed.
Attempting to run all system tasks.
All system tasks have been completed.

I'm seeing successful login attempts to the mail server. I'm waiting 5 minutes between running it, and the scheduled task for ticket import is scheduled to run every 5 minutes. I disabled the cron while I was running it manually.

I do see this in general-notice log but it's not generated each time I check mail, and it's currently 14:51:51 on my server.

[2019-01-25 19:45:03] general.NOTICE: E_NOTICE: iconv(): Detected an illegal character in input string {"code":8,"message":"iconv(): Detected an illegal character in input string","file":"/var/www/xxx/plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php","line":342}

No other logs are being populated for today.

total 180
drwxr-xr-x 2 www-data www-data  4096 Jan 25 12:00 .
drwxr-xr-x 7 root     root      4096 Dec  7 13:22 ..
-rw-r--r-- 1 www-data www-data  2091 Dec  4 17:45 general-error-2018-12-04.log
-rw-r--r-- 1 www-data www-data  1195 Dec  5 08:57 general-error-2018-12-05.log
-rw-r--r-- 1 www-data www-data 14556 Dec  7 13:10 general-error-2018-12-07.log
-rw-r--r-- 1 www-data www-data   879 Dec  8 16:05 general-error-2018-12-08.log
-rw-r--r-- 1 www-data www-data  3539 Dec  4 17:49 general-info-2018-12-04.log
-rw-r--r-- 1 www-data www-data 11635 Dec  5 10:05 general-info-2018-12-05.log
-rw-r--r-- 1 www-data www-data   104 Dec  7 08:32 general-info-2018-12-07.log
-rw-r--r-- 1 www-data www-data   787 Dec  8 16:06 general-info-2018-12-08.log
-rw-r--r-- 1 www-data www-data   263 Dec 16 23:30 general-info-2018-12-17.log
-rw-r--r-- 1 root     root      2055 Dec 20 11:00 general-info-2018-12-20.log
-rw-r--r-- 1 root     root      2271 Jan  2 10:05 general-info-2019-01-02.log
-rw-r--r-- 1 root     root     11481 Jan  3 14:00 general-info-2019-01-03.log
-rw-r--r-- 1 www-data www-data  1461 Jan  8 15:00 general-info-2019-01-08.log
-rw-r--r-- 1 root     root       615 Jan  9 10:00 general-info-2019-01-09.log
-rw-r--r-- 1 www-data www-data 10453 Jan 19 12:05 general-info-2019-01-19.log
-rw-r--r-- 1 www-data www-data  1587 Dec  4 17:02 general-notice-2018-12-04.log
-rw-r--r-- 1 www-data www-data 12443 Dec  5 15:10 general-notice-2018-12-05.log
-rw-r--r-- 1 www-data www-data   530 Dec  6 14:35 general-notice-2018-12-06.log
-rw-r--r-- 1 www-data www-data 12455 Dec  7 13:20 general-notice-2018-12-07.log
-rw-r--r-- 1 root     root      1204 Jan 22 16:05 general-notice-2019-01-22.log
-rw-r--r-- 1 root     root      2408 Jan 23 14:20 general-notice-2019-01-23.log
-rw-r--r-- 1 root     root       376 Jan 23 19:50 general-notice-2019-01-24.log
-rw-r--r-- 1 root     root      1204 Jan 25 13:45 general-notice-2019-01-25.log
-rw-r--r-- 1 www-data www-data   436 Dec  5 08:21 general-warning-2018-12-05.log
-rw-r--r-- 1 www-data www-data   379 Dec  7 13:25 general-warning-2018-12-07.log
-rw-r--r-- 1 root     root       698 Dec 27 12:15 general-warning-2018-12-27.log
-rw-r--r-- 1 www-data www-data  1090 Jan  8 15:00 general-warning-2019-01-08.log
-rw-r--r-- 1 www-data www-data   218 Jan 19 12:04 general-warning-2019-01-19.log

I see my test message I sent the department in the IMAP folder via outlook. The checkbox for this department is not checked for 'Allow only clients to open or reply to tickets'

I thought my "Box Name" setting must be wrong. I have the mailserver setup to store mail in the default directory, not .INBOX When I try to set BOX NAME to blank it doesn't let me. I went into SQL and set it to blank manually AND IT WORKS

mail_location = maildir:/var/mail/vhosts/%d/%n

%d is domain , %n is the username

Can someone please fix the issue where the form doesn't allow you to set a blank box_name per department as our mailserver is setup this way.

It took me forever to figure this out.

Hopefully if anyone else has a mail issue they can read my thread for troubleshooting tips.

[Paul]

To be clear, I've attached a screenshot:

Are you suggesting we allow this to be set to blank? And blank worked for you after manually modifying it in the database?

[coreyman]

48 minutes ago, Paul said:

To be clear, I've attached a screenshot:

Are you suggesting we allow this to be set to blank? And blank worked for you after manually modifying it in the database?

Yes, because my mailserver puts incoming mail in the root of the mailbox. It requires no box name. By default outlook looks here for mail, you have to manually configure outlook to look in .INBOX. I think .INBOX is a 'cpanel' constructed way of configuring a mail server.

[coreyman]

A year and a half later and I see this is still an issue and, it looks like the fix I found doesn't work in the latest version of blesta since we upgraded from 4.4.1 to 4.10

I've tried setting every port and security combination available. I know what ports work and are configured on our server, imap/993/ssl. This same combination works in any mail client I use. There are no errors in logs_blesta when it is configured with imap/993/ssl/blank box name. In fact I do not even see a login attempt in my mailserver logs.

 

[cincay]

On 1/26/2019 at 6:11 AM, Paul said:

To be clear, I've attached a screenshot:

Are you suggesting we allow this to be set to blank? And blank worked for you after manually modifying it in the database?

What is the best option? IMAP, POP3, or piping?