XF 1.3 Default Email Not Working + Other Issues

Wesker

Well-known member
We have a strange error here can't seem to figure out what is the cause of this:

- The email server is sending very old emails months old and contained in the email is just the subject not the body. We spoke with our host and they said their are errors with the script deferred.php which has been unaltered. When we disable deferred.php, the emails stop.

- During this time, cometchat also broke where now people cannot send replies (blank messages after typing). This isn't working with deferred.php disabled and enabled.

They both broke at around the same time. I'm not sure if they're related but hoping you guys may know what this and can put us in the right direction to fixing this.
 
The chat was fixed by doing a new installation/upgrade. Why it broke is still a mystery.

However, we're still trying to figure out what happened to the email server that is still broken and disabled temporarily.
 
If the emails are coming from deferred.php, the only thing I could really think of with XF out of the box is the mail queue. Do you have a lot of records in the xf_mail_queue table? Otherwise, I'd probably have to guess that there's an add-on involved.

You can look at the xf_deferred table to see if there are pending actions that might be relevant (there will always be one or two entries in that table; notably, cron will always be there).
 
If the emails are coming from deferred.php, the only thing I could really think of with XF out of the box is the mail queue. Do you have a lot of records in the xf_mail_queue table? Otherwise, I'd probably have to guess that there's an add-on involved.

You can look at the xf_deferred table to see if there are pending actions that might be relevant (there will always be one or two entries in that table; notably, cron will always be there).

Yes we have thousands of pages of mail queue in this table. Should I truncate this table?
 
If there are legitimate mails that haven't been sent, then truncating the mail queue table will prevent those from being sent, but it looks like something may have queued bad emails in the past. On the balance, emptying xf_mail_queue is probably the best option.
 
Here are some data the devs wanted me to send to you to confirm next step;

so we have 61020 emails waiting in mail queue
that's also not normal
SELECT count(mail_queue_id) FROM xf_mail_queue;
+----------------------+
| count(mail_queue_id) |
+----------------------+
| 61020 |
+----------------------+
1 row in set (0.03 sec)

As your current setup is not processing bounce emails, that might be another reason why email server got into issue. Out of this 61020 emails, there might be high number of hard bounces causing all this mess
 
Devs said all other files look good but also wanted you to take a look at this and give your thoughts on possible exploitation of the server:

http://i.imgur.com/TLllZXn.gif

Also on truncating they said that the queue would likely build up again so every few days we'd have to keep truncating until we figure out the source of the issue.
 
Bounces won't cause emails to stay in the mail queue. We don't queue them like that. There's no reason for the mail queue to build up like that either: it is normally emptied effectively immediately. It sounds like something--an add-on?--may have inserted a large amount of data into it.

As for the file health check, that doesn't automatically point to exploitation, but it'd be worth downloading those files and comparing them against known good versions (like from the XF zip for your version) to see if there are appreciable differences. That will tell you what's going on. If you've manually patched any files, then these errors would be expected.
 
Back
Top Bottom