Skip to main content
Topic: EA wont Send EMail when using php mail instead of smtp. (Read 698 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EA wont Send EMail when using php mail instead of smtp.

I'm posting this up because I got bit by an "update" to my hosts email server.  This isn't an EA BUG (unless you consider EA has the option of using php's native Mail() function a bug!

Background - I have a simple email script on my server that sends an email to people who activate it. Suddenly, people stopped getting it. I assumed there was something on their end because it worked for me just fine.  I discovered recently it wasn't their mail server, it was MY mail server..  

I isolated the problem to be a change either in the formatting of the email presented by php mail() to my hosts' mail server, or in my case now, more likely my host's mail server itself .. the result being that the email going out that used to start off with:

Return-Path: <hosted_user@host.hostdomain.com>

Now starts off with:  Return-Path: <nobody@host.hostdomain.com>

I didn't notice because the return addy for that script is "no_reply@mydomain.com", so the bounces go to bit-heaven.

And yes, EA using php mail() WAS also affected.

I found a bunch of EA bounce messages on the server (I guess I didn't have EA set for gathering bounce mails), that said: "Mail sent by user nobody being discarded due to sender restrictions in WHM->Tweak Settings.
 
cPanel's WHM->Tweak Settings checklist includes: Prevent “nobody” from sending mail — Enable this setting to block email that the nobody user sent to the remote address.
 
Note the key phrase "remote address". If the recipient address is on the host, it goes out fine. That would include you, most likely, so nothing appears amiss when you use or test it.

No wonder my forum traffic dropped off noticeably recently..
 
The simplest fix is for the host to "uncheck" that setting, and voilla! 

Otherwise, switch EA to sending mail via SMTP instead of "PHP Mail", or if there's more affected than just EA, install a mail handling program that allows for more customization than php's mail() function does.

Neither I, nor my host, have discovered what changed the "hosted_user" to "nobody". (The server owners probably did an "upgrade" to the mail server and didn't tell anyone).   :unamused:

Last Edit: May 23, 2023, 01:30:00 am by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

Re: EA wont Send EMail when using php mail instead of smtp.

Reply #1

Very glad you found the problem and have a solution  :cool:

Re: EA wont Send EMail when using php mail instead of smtp.

Reply #2

Quote from: Spuds – Very glad you found the problem and have a solution  :cool:

Yea, that's the main issue..  But as it turned out, I actually was receiving bounce messages turned on - they apparently go to Admin Moderation, but, in 1.1.6, the code Emailpost.subs.php  to view the bounced email gets hung up looking for "Html_2_BBC" at line 75, or so says the Error message and the log files when Admin tries to see what the email is.  So there's no way to know what the bad message is - it's not a message that will post if approved, so all admin can do with it is delete "whatever it was" (someone not a member sending email to the forum? Could be anything, or anything else, and probably is.. my own mail server was way down on the likely possibilities list..).

I sent you a PM on that, Spuds, since I can't find "Html_2_BBC" either (I'm no smarter than the code apparently, I too occasionally get wrapped about the axle looking for things that evidently don't exist :rolling_eyes:), and I'm not 100% positive that code call is in the original 1.1.6 Emailpost.subs.php file (I think it is, but I did some fiddling with that file awhile back and while my backup files show the same code call, I still don't rule out the possibility this is yet another self-inflicted head-wound). . I was thinking of commenting the "Html_2_BBC" call out just to see what happens but decided to wait for your feedback before I break something else or call it a "bug".
Last Edit: May 23, 2023, 01:39:00 am by Steeley

// Deep inside every dilemma lies a solution that involves explosives //


Re: EA wont Send EMail when using php mail instead of smtp.

Reply #4

Quote from: tino – https://github.com/elkarte/Elkarte/blob/patch_1-1-10/sources/subs/Html2BBC.class.php

It’s a class, and should be in the main Elkarte sources folder. Likely thing is it’s not included so falls over.

If your error is the class doesn’t exist

And it didn't..  so I downloaded it so it does now exist, and now it works..  :partying_face:

I also found the link to the 1.1.6 release here in the forum, (since navigating github is yet another skill I haven't mastered) and pulled down the install package (no idea where that went - but I didn't have it/them either on my server or my own desktop box).

And, I can see there IS an html2bbc.class file in the 1.1.6.zip, and the 1.1.6.tar.gz, packages, but in the subfolder /Sources/ElkArte, which doesn't exist on my server (there's other files in that folder that also aren't installed on my server).  Since I don't know how the install package set up the structure on my server, I'm not going to guess what happened or didn't happen so that those files didn't get installed. Perhaps there was some setting during install that queried for "BBC support inclusion" that I declined? That was about three years ago, and I can't remember off the top of my head what I did last Saturday :unamused: much less back in 2020. So, lacking any conclusive evidence to suggest that this wasn't self-inflicted, I'll not call "bug!" 

Anyway, Admin can now see the "bad emails" - and sure enough, it's the bounces from my mail server telling me what took me 3 days to figure out was going on by other more laborious and convoluted means.

Thank you for the assist Tino!  :thumbsup: 



Last Edit: May 23, 2023, 08:18:19 pm by Steeley

// Deep inside every dilemma lies a solution that involves explosives //

 

Re: EA wont Send EMail when using php mail instead of smtp.

Reply #5

In conclusion, my Failure Analysis of this issue revealed the following:

Nobody was prevented from performing as intended until that was discovered, analyzed, and corrected so that in the end, nobody could perform as intended. :stuck_out_tongue::upside_down::rofl:

// Deep inside every dilemma lies a solution that involves explosives //