No, I do not enable mail for any domains on any of my website boxes because mail is either handled on separate dedicated mail servers or there is no email in use for a particular domain.
That being said, I just enabled email on this domain in Virtualmin.
Then I loaded the Roundcube script. I sent a test message through Roundcube to my email address and it came through. However, in the message header I see that the message came from username@localhost instead of the username@domain.com so am wondering if that is an issue.
Then I tested the form from within the WordPress site and it still did not work sending to my email address.
Then I tried putting the username@localhost as well as username@domain.com in the form output to see if they could be seen by Roundcube locally. The form output still did not show up anywhere.
Ok, I composed a test message and it did in fact send from Usermin. This message had the domain name in the senderâs address as opposed to @localhost like in the test through Roundcube.
To me that sort of answers the question. Virtualmin/Usermin is handling email.
WordPress is used by so many folk using Virtualmin (No idea why?) that I would have thought that if there was a built in problem the forum would be a flame
So this in my view goes back to something in WordPress (the way it is using email) and that probably is something to do with PHP (and that could be why it appears to be a Virtualmin problem.
Even so I would expect some error logged somewhere. But again that is only as good as the code in WP/PHP issuing it as an error.
Yes, there has not been any doubt that the issue is with how WordPress hands off the email to Postfix on this server. Since the site is managed by Virtualmin, I suspected I did not set something up correctly. Especially since no WordPress sites using forms will send. I have another Virtualmin server as well, and its WordPress sites with forms send email just fine. The only difference between the boxes are that this one is Debian 11 and the one everything works ok in is Debian 10. Both boxes are up-to-date packages wise.
I turned on debugging in the site and get no error indications at all. I even tested the error handling and it worked. I tried a script to send mail and first it generated a 500 error which showed up. Then I changed it (added the first line) to this and it didnât generate a 500 error - it just tells me the âEmail sending failedâ:
<?php
require_once( $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php' );
$to = 'me@mydomain.com';
$subject = 'Test Mail using WordPress from MyBox';
$message = 'Hello, this is a test email using the PHP mail() function in the root of a WordPress website on MyBox.';
$headers = 'From: webmaster@thedomain.com' . "\r\n" .
'Reply-To: me@mydomain.com' . "\r\n" .
'X-Mailer: PHP/' . phpversion();
if(wp_mail($to, $subject, $message, $headers)) {
echo "Email sent successfully";
} else {
echo "Email sending failed";
}
?>
But whenever I fill out a form and send it, whatever is failing does not generate an error in the error log. It simply doesnât work.
I had something similar to this long ago, where no email from forms would get sent out (using a different control panel) and it was a symbolic link to sendmail that had disappeared. Once fixed everything worked again. From what I can tell with my limited expertise, my Virtualmin boxes are not set up that way.
It looks like using the local email server is optional. Not using your email server would lose things like DKIM and SPF verification. Seems iffy at best to me.
Yes, I have seen that and thanks for reminding me of it. No doubt the plugin route works, I used it with one of the problem sites on this box. In my view itâs a Band-Aid, even though a very good one. Bottom line is that with many boxes Iâve never run into this before. And the operative sentence in that WP Forms article is:
For example, some hostsâ servers arenât configured to use WordPressâ built-in mailing function.
This is a configuration issue. This box isnât configured to use the WordPress mailing function. But searching for info on that is how I will stumble across the answer. I know that at some point once the configuration is set correctly it will have seemed to be so simple (LOL)! 20/20 hindsight.
The main takeaway here is that going through the local SMTP server will have other benefits. The mail is more likely to be accepted by other servers. Just as Virtualmin will do checks on SPF and DKIM, your script doesnât provide any of that, so other servers might drop the mail.
Your own server might be rejecting these mails because they fail basic checks. I donât know. It might explain the gap in you error logs.
Thanks for a bit more clarification. Iâm afraid I am not a Debian fan so cannot help those who do might find this difference of some help.
doesnât that require some specific setup inside Virtualmin (IIRC there is something about sendmail -> postfix and postfix -> sendmail in the documentation)
I have also noticed/realised that WordPress is an optional install under Install Scripts I wonder if that has some options that are specific or that the install script does something âhiddenâ which might make life different than if just loading a WP site into a raw public_html location. I am clutching at straws here as Iâm so anti WP I have never had the desire to find out. I am more interested in how it might be affecting Virtualmin.
I would think that would be the case for ALL emails from the box then, that use Postfix and/or Sendmail. However, all of my system mails get through just fine (when sites are created, backups are completed, etc.). The received headers indicate Postfix being used.
Additional tests from the command prompt show mail getting being sent also. Brings me back to a setting someplace.
Looking through the WordPress.org site it spoke to the php.ini file. Checked that and there was not an issue there although both servers indicate a reference to sendmail. I havenât seen anything yet indicating otherwise for that setting.
I expect to try checking if a raw WordPress install behaves any differently this morning.
I hear the anti-WordPress sentiment - thatâs how I felt being dragged into it kicking and screaming nearly twenty years ago now. But 40% of all sites using it now so being in the web business one has to deal with it.
Must be about the same time (mid 90âs) I ditched it along with PHP. Iâm now in the position I can dictate things like âonly Nodejs/Python/Go Appsâ and even then be fussy
PHP 7.4 ? now that is another issue. Virtualmin seems to install by default PHP 8.1 currently so why take a step back a whole version ? I thought WP was now happier working with 8.1
A search on here throws up some intriguing posts regarding sendmail in addition to the ones in documentation
Unfortunately, 7.4 is still necessary in many cases until all the plugins in use in a site are compliant with newer versions. Thereâs always been a lag in that respect.
Again, no problem using it on other boxes - my sending emails issue from WordPress is restricted to this particular box.
Have you look in the logs to see whatâs going on? Everybody is just guessing wildly, thereâs not reason to guess. In skimming this thread I see no logs. (I see that itâs not making it to the maillog, which means itâs not even trying to send locallyâŠbut no other logs to show us what it is trying to do.)
PHP logs somewhere. Either in a php.log or in the error_log for the domain.
Look at the danged logs to see what itâs trying to do.
When all else fails - some glimmer of hope can sometimes be found in a spark of light.
BTW PHP logs were suggested a long way back in topic and seem to recall there are none/empty. But if IR PHP can be written in such a way as to ignore writing to logs. (but yes I ditched PHP years ago !)
