Eq4bits
02-28-2014, 12:04 AM
Since the previous issue (with mod_security) was fixed the other day - https://vborg.vbsupport.ru/showthread.php?t=308221 - my vB has not been sending out email notifications like it should. I ran email diagnostics from within my vBulletin admincp and got the result below:
Pertinent PHP Settings
SMTP:
localhost
sendmail_from:
None
sendmail_path:
/usr/sbin/sendmail -t -i
Results
The mailing function returned an error while trying to send the mail.
Check your mail server to ensure it is configured correctly to allow PHP to send mail from it. You should also check your mail server's error log for more diagnostic information.Further 'help' popup gave the following info:
The "Email" diagnostic will send a test email to the address you specify. If you receive the test email then PHP and your mail server are configured correctly. Otherwise they are not configured correctly and you need to contact your host.Since the test email did not work I have to assume the php & mail server are not configured correctly so as suggested I contacted my host giving them the above info.
To which my host replied:
I've checked the settings area to see if anything was set incorrectly but I can't seem to find anything there that would help. There are rumours that changing localhost to 127.0.0.1 would make it work correct. I've also tried logging in via SSH to reproduce the command that's being used but I'm unable to find the exact command being used.
Are you able to provide us with the cronjob that is being set or the sendmail command being used by vBulletin so we can investigate further?What is the exact command that vBulletin is using to send email?
I checked my includes/config.php file and found this:
// It is also necessary to specify the hostname or IP address and the port the server is listening on
/*
$config['Datastore']['class'] = 'vB_Datastore_Memcached';
$i = 0;
// First Server
$i++;
$config['Misc']['memcacheserver'][$i] = '127.0.0.1';
$config['Misc']['memcacheport'][$i] = 11211;
$config['Misc']['memcachepersistent'][$i] = true;
$config['Misc']['memcacheweight'][$i] = 1;
$config['Misc']['memcachetimeout'][$i] = 1;
$config['Misc']['memcacheretry_interval'][$i] = 15;does something need to be changed there?
or here?:
// Optionally, PHP can be instructed to set connection parameters by reading from the
// file named in 'ini_file'. Please use a full path to the file.
// Example:
// $config['Mysqli']['ini_file'] = 'c:\program files\MySQL\MySQL Server 4.1\my.ini';
$config['Mysqli']['ini_file'] = ''; Or is there something else somewhere else that I need to tweak? My host is obviously clueless (in most cases). =S
Seems like I get one thing fixed and something else frells up =S
*********************
ETA: this is what my 'email queue' cron job looks like...
00, 10, 20, 30, 40, 50 * * * * Process E-Mail Queue
Process the next batch of the e-mail queue.
In my admincp>Email Options
Enable Email feature is set to 'Yes'
my mail queue setting is set to 'Yes'
Use Cron Based Sending set to 'Yes'
Number of Emails to send per Batch '21'
Email send delay 'none'
SMTP Email set to 'No'
--------------- Added 1393595945 at 1393595945 ---------------
Nevermind. Either it worked itself out or host figured it out.
Pertinent PHP Settings
SMTP:
localhost
sendmail_from:
None
sendmail_path:
/usr/sbin/sendmail -t -i
Results
The mailing function returned an error while trying to send the mail.
Check your mail server to ensure it is configured correctly to allow PHP to send mail from it. You should also check your mail server's error log for more diagnostic information.Further 'help' popup gave the following info:
The "Email" diagnostic will send a test email to the address you specify. If you receive the test email then PHP and your mail server are configured correctly. Otherwise they are not configured correctly and you need to contact your host.Since the test email did not work I have to assume the php & mail server are not configured correctly so as suggested I contacted my host giving them the above info.
To which my host replied:
I've checked the settings area to see if anything was set incorrectly but I can't seem to find anything there that would help. There are rumours that changing localhost to 127.0.0.1 would make it work correct. I've also tried logging in via SSH to reproduce the command that's being used but I'm unable to find the exact command being used.
Are you able to provide us with the cronjob that is being set or the sendmail command being used by vBulletin so we can investigate further?What is the exact command that vBulletin is using to send email?
I checked my includes/config.php file and found this:
// It is also necessary to specify the hostname or IP address and the port the server is listening on
/*
$config['Datastore']['class'] = 'vB_Datastore_Memcached';
$i = 0;
// First Server
$i++;
$config['Misc']['memcacheserver'][$i] = '127.0.0.1';
$config['Misc']['memcacheport'][$i] = 11211;
$config['Misc']['memcachepersistent'][$i] = true;
$config['Misc']['memcacheweight'][$i] = 1;
$config['Misc']['memcachetimeout'][$i] = 1;
$config['Misc']['memcacheretry_interval'][$i] = 15;does something need to be changed there?
or here?:
// Optionally, PHP can be instructed to set connection parameters by reading from the
// file named in 'ini_file'. Please use a full path to the file.
// Example:
// $config['Mysqli']['ini_file'] = 'c:\program files\MySQL\MySQL Server 4.1\my.ini';
$config['Mysqli']['ini_file'] = ''; Or is there something else somewhere else that I need to tweak? My host is obviously clueless (in most cases). =S
Seems like I get one thing fixed and something else frells up =S
*********************
ETA: this is what my 'email queue' cron job looks like...
00, 10, 20, 30, 40, 50 * * * * Process E-Mail Queue
Process the next batch of the e-mail queue.
In my admincp>Email Options
Enable Email feature is set to 'Yes'
my mail queue setting is set to 'Yes'
Use Cron Based Sending set to 'Yes'
Number of Emails to send per Batch '21'
Email send delay 'none'
SMTP Email set to 'No'
--------------- Added 1393595945 at 1393595945 ---------------
Nevermind. Either it worked itself out or host figured it out.