New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
We only allow local emails send via authenticated SMTP connections on our shared hosting packages (https://hosterion.com/web-hosting).
We've been doing it for man years and it has not been a problem, you just need to communicate this to new customers, especially to the ones migrating from another provider. A SMTP plugin is usually needed for scripts like Wordpress.
@intovps thanks for the response. Agreed SMTP is the best way generally, but it seems some were relying on PHP mail() which isn't really secure and a possible alternative is the local sendmail command via PHP (it seems this is what Swiftmailer/Laravel has done).
But that's not much use for software that needs to work in shared hosting if it is widely disabled.
What problem are you trying to solve?
If you're writing software you should support SMTP with and w/o authentication and maybe mail() as well.
What kind of issues on PHP Mail?
Agreed, always have done this - SMTP, sendmail (local), and PHP mail() - but working on a Laravel project can see that mail() support has been removed (see here). It's easy to re-add, no doubt, but not too keen on taking on the maintenance burden/overriding vendor packages.
https://blog.sonarsource.com/why-mail-is-dangerous-in-php?redirect=rips
Then I'd leave mail() if not supported by your framework. On any basic/lab server you can just use SMTP to localhost without authentication and you're done. You'd have that even on a dev machine. AFAIK mail() requires a local SMTP server anyway.
I think we may be talking about similar things here, the sendmail method executes the local sendmail command which is what I believe PHP mail() does anyway (by sendmail, I mean any SMTP server software that is compatible with sendmail). The problem is some shared hosts do not allow forking to launch sendmail.
As for unauthenticated local SMTP, that's another option; I haven't used control panels in a while so I wasn't aware they were not authenticating local connections. Thanks!
"using sendmail" sounds like PHP exec()-uting the sendmail binary which is inelegant. A bit of resources wasted and generally providers disallow exec() because is a tool used to (a) try to exploit local vulnerabilities and (b) launch attacks to other servers.
Unauthenticated SMTP makes sense in two scenarios: dev/staging machine when you want to run and test things quickly and some SMTP relay on another machine based on client IP. On a basic dev machine this could require some extra steps, but as I was saying any form of local mail sending requires a local mail server, hence you have SMTP on localhost:25. And AFAIK about any OS package will install and configure the mail server to not require auth on localhost.
So this would be mostly for servers without a panel.
For all others there's auth SMTP.
If I remember correctly the SMTP mail driver in Laravel uses Swiftmailer SMTP.
Why do you want to use mail() or sendmail?
Laravel does use Swiftmailer, supporting various mail engines. I don't particularly want to use PHP mail() or sendmail; I'm upgrading an open-source project with very outdated dependencies and mail() was dropped in newer Laravel versions, and I'm figuring out what the best direct replacement is.
SMTP is, of course, already supported but it seems many on shared hosting are using PHP mail().
The best direct replacement is SMTP.
PHP mail() uses SMTP or sendmail depending on the system.
Laravel mail has SMTP and sendmail drivers.
The whole purpose of Laravel and other frameworks is that they have a lot of built-in functionality that you can use.
If there is bad or deprecated code you should replace it with code that uses the build-in mail functionallity. When you have done that you can easily change the mail driver if it gets necessary.
Agreed completely. I'm working through updating/removing a whole mess of depreciated packages and overrides.
However, it's also important not to just randomly break things for existing users, hence why I am looking at the best method to replace PHP mail() without requiring too much - if any - changes from those using the software. Longer term and for new installs, it's not an issue as the functionality will be removed.