Leaderboard
Popular Content
Showing content with the highest reputation on 03/06/2022 in all areas
-
Ok, let me clarify a few things for you. There is no such thing as phpmail. You are introducing confusion thinking that such a thing exists. PHP has a mail() function, which is somewhat configurable via the php.ini. By default it pipes mail input directly to whatever the local "Mail transfer agent" aka "MTA" is. The MTA is operating system dependent, but it's some server process that implements Simple Mail Transfer Protocol (SMTP) which is the protocol mail *servers* use to send and receive emails. Whether or not those emails actually get sent as expected or received, after mail has been called, has many complicated issues associated with it, and is the domain of experienced email system administrators. In your case, that is entirely within the purview of Network Solutions. I will offer just a few issues: To send email requires DNS, specifically MX records for a domain. In most cases systems are not sending email directly out of a specific application server. They instead are using the hosting companies email servers. To send email on behalf of a domain requires at very least SPF, and increasingly DKIM setups for the email servers on behalf of a domain The network solutions script is a red herring. We need to see what your script is doing. There are many ways to send email. We also need to understand more about these emails you send. What is the from address? Is it from you at your domain? What do the headers look like for the test emails you can send out? Is NS proxying your emails for you? What code packages the "html" version THe RFC's for how emails work has specific requirements for what an email is supposed to look like. An "html" email is not a replacement for a standard email. Technically an html email is just a attached version of the email that should be packaged with an original ascii only version. Email clients then will retrieve the html version and display that. Many email systems are highly fault tolerant, and not unlike the way browsers will tolerate broken html and still display something for you in most cases, that doesn't mean you should or your software should ignore the standard and correct format for emails. It is never correct to take code that would send an html email and then just add html tags to the body and send that instead, even if it has worked for you to some degree in the past. Some email systems will reject that email outright and you will likely never know that they were rejected. Some mail clients won't work or the email will look bad. Viewing html emails is actually a choice for the email client. Some people use clients that don't render html or they intentionally turn it off. That might be the minority, but it is another reason to have a properly constructed email. You really have a number of issues: You have limited control of your hosted environment? You aren't an expert on how email administration works or php You're running a really old script on a version of php that has been End of life for a long time You don't seem to have any test environment, so you're experimenting with your production environment, with limited visibility into that Apparently your script has some bugs, but again we haven't seen it, or any portion of it. To summarize. Yes you should use PHP 7.4 (at minimum). That is the *oldest* supported PHP version available. You might very well be better served by using one of the many current supported PHP mail libraries rather than something as low level and hosting dependent as mail(). For example, many libraries actually implement SMTP themselves, and give you a lot more control over the process of sending emails programmatically, while at the same time insuring that the delivered email data is actually compliant with email standards For any email sending you need a good handle on the questions I raised previously (how will you actually "send" email, in terms of what user@domain the email is coming from. Is this from your domain, and if so, is the email setup for the domain valid and workable. Anyone can setup something that "delivers" emails via smtp that will promptly be rejected or accepted and deleted with you never being the wiser. Here is an article talking about the best known php mailer libraries. The ones I would suggest considering are listed below. phpmailer https://github.com/PHPMailer/PHPMailer Probably this is the library you should use in renewing your existing email script. symfonymail https://symfony.com/doc/current/mailer.html This took over for the popular swiftmailer you may see mentioned as an alternative The php Composer tool was released a decade ago. There is no excuse left for a project that is not using composer to manage your dependencies. This is also why you probably need a dev/test environment within which you can run composer. Composer will download and manage your dependencies. It will build a standards compliant autoloader for your application that you include so that class libraries like phpmailer can be properly autoloaded Porting your email script is probably the path to getting something reliable and supported. I hope this helps you start moving yourself in the right direction. If you want to start answering some of the questions I posed, and need help and advice in doing so, feel free to follow up. Sending email seems simple but it has become a very complicated endeavor over the years, and like many things that seem simple on the surface, have a lot of hidden complexity to them, especially when things go wrong.1 point
This leaderboard is set to New York/GMT-05:00