Hacker News Reader

Comment by kogepathic | Hacker News Reader

Out of curiosity, why is PHPMailer invoking the command line at all?

It would seem much safer to establish a TCP connection to the local MTA over port 25 or 587 and send the message that way.

Admins can just use iptables to restrict access to the port to localhost, and/or do the same in their MTA config.

View on HN

It's using PHP's builtin mail() function, which happens to be a wrapper around /usr/bin/sendmail, and one of the parameters it takes is used as an "additional command-line parameter to sendmail". In particular, the "-f" switch is used to set the SMTP envelope MAIL FROM address. Apparently PHP's mail() tries to do some automagic shell escaping on the argument but it's likely not good enough and it also creates a conflict when callers such as PHPMailer also try to escape the parameter.

Software should never be using -f with user emails, regardless if it's sanitized or not. -f sets the return path, which will trigger DMARC protection if the domain doesn't allow it. For example, the yahoo.com policy will reject all mail if you try to set the return path to the user's yahoo.com address using -f.

The best way I've found to send mail on behalf of someone else is to leave the return path (-f) and From header pointing to your own domain, and use the Reply-To header with the users email.

PHPMailer can be configured to send mail through raw SMTP, by directly invoking sendmail, or by calling PHP's mail() function (which is a thin wrapper around sendmail). This vuln affects the last mode, where the command line is invoked by PHP itself. Yes, a good admin would configure mail differently, but this being PHP, it tries to be flexible and support the simplest options possible.

Using command line is the standard way in Linux and de-facto standard in *nix world.

"To deliver electronic mail (email), applications shall support the interface provided by sendmail (described here). This interface shall be the default delivery method for applications."

http://refspecs.linux-foundation.org/LSB_3.0.0/LSB-PDA/LSB-P...

Yes but PHP runs on non-*NIX platforms[0]. So why not use an interface which is (a) more secure, and (b) platform independent?

[0] http://windows.php.net/

Why do anything that makes sense? All I can say about the PHP maintainers' decision process without swearing is that it bewilders me.

Last time I tried configuring a Linux-hosted PHP to do SMTP on localhost:25 instead of shelling out to call sendmail, I found that only Windows builds even have that functionality compiled in. You can apply the same configuration options on a stock Linux build, and they won't cause errors, but they won't do anything, either. Maybe that's changed recently, but it would have to have been very recently, because I ran into this (for the umpteenth time) just a few months ago, while reworking my team's dev environment to allow for examining sent mail without requiring heroism.

I'm not a PHP hater, exactly. I don't like the language at all, but I understand it well and have made a very good living based partly on that knowledge. But the mail story in PHP has never not been a dumpster fire.

There are hundreds of ready made libraries which help you easily talk to SMTP without invoking a shell cmd. You also have the option to use sock functions (fsockopen) and write your connection wrapper. These are not windows-only features.

Of course. The part I still can't get my head around is where the language feature that'd relieve me of the need to vet a library, or worse write socket code by hand like some kind of barbarian, isn't compiled in for non-Windows platforms, because reasons.

¯\_(ツ)_/¯ PHP. This is one of the insane decisions made in PHP4 that stays there because it's always been there.

Reply on news.ycombinator.com