SwiftMailer, PhpMailer, etc: Difference between mail() and sendmail

Question

I often read that PHP's mail()-Function uses sendmail internally.

So why do Mail-Libraries like SwiftMailer, PhpMailer, etc give us the chance to CHOOSE between mail() and sendmail?

Isn't it the same thing?

Never heard anyone saying that it's NOT the same thing!

Please help, 'cause I'm really confused about that!

Answer 1

A typical sendmail binary (e.g. one from postfix), even if called via PHP's mail function, opens a synchronous connection to localhost and conducts a full SMTP transaction. This can mean that it's actually slower than using SMTP directly - and in fact the postfix docs recommend using SMTP to localhost in preference to sendmail if you're looking for performance. In particular you can benefit from keepalive when sending lots of messages by using SMTP.

One trick is that you can pass an additional parameter to sendmail (specifically -O DeliveryMode=b) to tell it to operate asynchronously, in which case it returns immediately, making your mail sending much more responsive, but because PHP isn't set up to handle that, you lose the ability to handle errors that may occur so this is not recommended. You can use this either by calling the sendmail binary yourself with those options, or by passing it in the $additional_parameters parameter.

Generally there isn't really any difference between mail and sendmail options in PHPMailer, though it might possibly be useful if you want to use a sendmail binary other than the one that PHP is set to use.

Answer 2

On unix-like systems, mail() does indeed use sendmail, but this is not the case on Windows (which doesn't have sendmail at all, so mail() instead sends through SMTP).

The real benefit of Swiftmailer, et al., is that they provide an OOP wrapper around sending email, so that your email content generation is abstracted (properly generating MIME envelopes and getting headers correct can be tricky, especially when user input requires escaping), and also the actual transport mechanism is abstracted as well (so you could replace an SMTP or sendmail transport with a custom transport using a mail provider's API without having to change all your code).