3

Mailer Error: Could not execute: /usr/sbin/sendmail

I'am using debian server, the file permission is 777(all alowed), so I can't execute it why is that?

//Create a new PHPMailer instance
$mail = new PHPMailer();
// Set PHPMailer to use the sendmail transport
$mail->isSendmail();
//Set who the message is to be sent from
$mail->setFrom('admin@test.com', 'test');
//Set an alternative reply-to address
//$mail->addReplyTo('replyto@example.com', 'First Last');
//Set who the message is to be sent to
$mail->addAddress($_POST['email'], $_POST['name']);
//Set the subject line
$mail->Subject = 'PHPMailer sendmail test';
//Read an HTML message body from an external file, convert referenced images to embedded,
//convert HTML into a basic plain-text alternative body
$mail->msgHTML("from test");
//Replace the plain text body with one created manually
$mail->AltBody = 'This is a plain-text message body';
//Attach an image file
//$mail->addAttachment('images/phpmailer_mini.gif');

//send the message, check for errors
if (!$mail->send()) {
    echo "Mailer Error: " . $mail->ErrorInfo;
} else {
    echo "Message sent!";
}
yeah its me
  • 1,131
  • 4
  • 18
  • 27
  • Dis is not a permission issue as you don't get a permission denied error – rullof Jan 13 '14 at 18:42
  • Anything which is mode 777 is a serious security issue. You should revert to an earlier backup of your system, or reinstall it from scratch. – tripleee Jan 13 '14 at 19:57
  • 1
    @tripleee `sendmail` is **777** by default, take it easy! Nobody reinstalls the system from the scratch, just because you `chmod` one file? Are you serious? – Ilia Ross Jan 13 '14 at 20:17
  • If a system binary is world writable, you can't know if you are already toast. Symlinks show as lrwxrwxrwx but the actual target **must** **not** be writable by every user on the system. – tripleee Jan 13 '14 at 22:04
  • @tripleee whatever you're saying has nothing to do with my answer. The fact is - it's writable. My recommendation was to make it default not to make it my fancy wrong way. The reason why it's `777` is unknown (at least for me, as 755 is more than enough). I could understand, if it was only symlink but it appears (from looking at the package), e.g. `sendmail-bin_8.14.4-2.1ubuntu4_amd64.deb` that the binary is also chmoded as `777`. Anyway, thanks for pointing out! – Ilia Ross Jan 15 '14 at 07:18
  • That would be a serious security problem in the package, but I guess you are still looking at a symlink, for which the permissions are always displayed like that. `usr/lib/sm.bin/sendmail` in `sendmail-bin_8.14.4-2.1ubuntu4_amd64.deb` is `chmod 2755`, owner `root:mail`. – tripleee Jan 15 '14 at 09:27
  • I will say it again: if **anyone** except yourself had access to the system at any point (perhaps without your knowledge) while a system binary was world-writable, the only way to make sure you are not hacked is to revert to a known-good backup, or reinstall from scratch. If you have been messing with the permissions of the system binaries yourself, similar advice applies, but not because of urgent security concerns, just because it is hard to know what they were like before you started messing up your system. – tripleee Jan 15 '14 at 09:30
  • @tripleee It's only one file. Agree with you, if you for example did `chmod -R 777 /*` – Ilia Ross Jan 15 '14 at 09:56
  • @tripleee `/usr/sbin/sendmail` is not a binary but always a symlink! Its permissions set to `777` by default on all systems (not sure why really).. – Ilia Ross Jan 15 '14 at 09:59
  • A symlink doesn't have permissions per se, it's not meaningful to `chmod` it and it is not meaningful to examine its permissions. – tripleee Jan 15 '14 at 13:23

2 Answers2

8

In Ubuntu sendmail is not installed by default. You will have to install it manually:

sudo apt-get install sendmail-bin

EDIT 1:

In case you're using PHPMailer you can set Sendmail path using:

$mail->Sendmail     = '/usr/sbin/sendmail';

It's easy to test if the problem in PHP code or in your mail server configuration, or even probably firewall. Try running from the command line and see if you receive your email:

/usr/sbin/sendmail -v my@address.com < email.test

Additionally you actually could receive the mail but it could be put in SPAM folder, so check for the message there as well.

EDIT 2:

And one more thing is that you should install sendmailconfig and then run it to configure it:

sudo sendmailconfig

Read more about configuring sendmail on Ubuntu: sendmail: how to configure sendmail on ubuntu?

Ilia Ross
  • 13,086
  • 11
  • 53
  • 88
  • I've installed sudo apt-get install sendmail-bin, but still getting the same error, the attributes are 777 allowed for all, I'am using PHPMailer, also I've tried it with mail() function both give the same error – yeah its me Jan 13 '14 at 19:32
  • Are you using PHPMailer? – Ilia Ross Jan 13 '14 at 19:34
  • 4
    -1 You **must** **not** `chmod 777` anything. These are not "proper" permissions for anything on a production system. – tripleee Jan 13 '14 at 19:59
  • @tripleee For your information my friend, I know that and the thing is that `sendmail` is `777` by default! (should be). Don't take my word for it, go ahead and run `ls -lsa /usr/sbin/sendmail` and in return you will see `lrwxrwxrwx.` – Ilia Ross Jan 13 '14 at 20:02
  • @tripleee, I have updated my answer. I personally don't think it should be 777, as it's overhead but this is the way it is. If you don't have it installed just donwload a package from http://pkgs.org and figure it out yourself. – Ilia Ross Jan 13 '14 at 20:33
  • I don't think it makes sense to install just `sendmail-bin`, and it might not work standalone at all. If you want Sendmail, install the `sendmail` package -- it will pull in `sendmail-bin`, but also some other dependencies. The set-up in multiple packages is for maintainability reasons (which I don't particularly subscribe to, but you can save some space by sharing architecture-independent files in `/usr/share` and having them in a separate package). Anyway, I will repeat my recommendation to prefer Postfix unless you have a legacy set-up which specifically requires the "real" Sendmail. – tripleee Jan 15 '14 at 13:27
  • And I will repeat again that overriding the perrmissions set by the packaging system requires you to know *exactly* what you are doing and why. I don't see any evidence here that this is the case. – tripleee Jan 15 '14 at 13:32
  • The symlinks maintained by `update-alternatives` will always be displayed as `lrwxrwxrwx` regardless of the permissions of their destination. `chmod 777` on anything in that chain is still fatally wrong, and will change the permissions of the *destination* of that symlink. – tripleee Dec 29 '20 at 05:29
  • I have no idea why I did that in the past. I agree, that you shouldn't modify a package. – Ilia Ross Dec 29 '20 at 08:21
1

The immediate problem appears to be that you did not have /usr/sbin/sendmail installed on your system. There are multiple MTAs which provide this, so there is no particular need to install the Sendmail suite; in fact, I would recommend against it, in favor of Postfix or some really simple MTA such as smtpd. Any package which Provides: sendmail should do.

The other problem which needs to be pointed out is the chmod 777 permission. You should absolutely not make anything on a production system world-writable. The correct permission for a PHP script is 755 or possibly 775 if you can trust the group. The httpd process certainly does not need to be able to write to the script -- indeed, should absolutely not be allowed to write anything to the script file.

tripleee
  • 175,061
  • 34
  • 275
  • 318
  • The best permission for binary executable should be 750 (7 for owner, 5 for group, 0 for anyone else) – PalDev Dec 27 '20 at 03:41
  • For a private script, 750 makes sense; but a system script obviously needs to be readable and executable by everyone. The bottom line, as always, is that you need to understand what the permissions mean. – tripleee Dec 27 '20 at 07:23
  • You want to understand permissions yes and *ownership* as well. If the system need to execute then you may want to change the ownership of the script, and not permissions. Look which user needs to run it (is it root / www-data / postfix etc) and change the ownership to fit with 750. 777 is really bad practice, it means that even guest users can execute it. – PalDev Dec 28 '20 at 20:37