@gregconway,
Your issue can be the result of a myriad of factors.
In the meantime, you have been testing and changing a lot, so this will not make any resolution of the issue(s) more easy.
In summary, you stated
a) in the first post:
Mail handler 'limit-out' said: REPLY:554:5.7.0 Your message could not be sent. The user is not allowed to send email. With outgoing mail control switched off they can send email just fine.
This was concerning outgoing mail restrictions.
For the sake of further resolution of the issue, leave the outgoing mail restriction disabled.
This implies that your actual issue is to be defined by:
With outgoing mail control switched on my non-plesk users created under SSH receive this error when trying to email out -
In this statement of yours, your problem is restricted to "
non-plesk users, including SSH users, cannot send mail"
Actually, this is logical behaviour in the default settings of Plesk:
1 - mail is allowed: by default, it is not a disabled function in php.ini,
2 - mail is send in a "normal" fashion: by default, mail is being send via the mail server (postfix/qmail), except when calling the PHP (internal) function mail() in a script,
3 - the mail() function uses a (Plesk) "wrapper" to send mail via the mail server,
and it must be clear by now that
- see point 2: plesk users are allowed to send mail by default,
- see point 3: the "allow scripts and users to use sendmail" switch activates the wrapper.
However, this does not imply that all calls to a mail() function will result in sending mail: authentication is still required AND proper mail configuration has to be in place.
I will return to the above.
b) in the second post:
Just to elaborate further.... root can send emails but other SSH users cannot. I have tried adding a
[email protected] mail account to the self-entitled "control" domain on each server (which I added a root@ user for long ago) but that hasn't solved it.
The root user can always call the mail() function, it is not required to add a specific domain with a
[email protected] account (i.e. mailbox).
However, in your case, the creation of the account/mailbox ascertains that mail is delivered by the mail server, i.e. mail is delivered without any issues.
Why does adding "
[email protected]" not have the similar result, i.e. a success in delivering mail?
Now I can continue what I have stopped to discuss in point a: there are two reasons for that, being
- calling a mail() function in a script will not result in authentication: the mail() function does not send as "
[email protected]", AND/OR
- the presence of an existing (non-Plesk) user forces the mail() function to use the /usr/sbin/sendmail or /usr/lib/sendmail binary.
In general, enabling the "allow scripts and users to use sendmail" switch would do the trick.
However, in your case, a (new and/or completely different) problem arises, as I will explain below.
c) in the third post:
I still get "Mail handler 'limit-out' said: REPLY:554:5.7.0 Your message could not be sent. The user ... is not allowed to send email."
Again, this is concerning message limit outage.
Now you (also) introduce something completely different: a potential greylisting problem.
We will ignore the alleged greylisting problem, since it all boils down to the issue, related to message limit outages.
And that is BAD, since it indicates that a lot of mail traffic has been passing your server, simply via the mail server itself.
That is normally an indication of a "hack and spam attack", mostly done with a call to mail() functions.
In short, at this moment in time, it should not be adviceable to enable the "allow scripts and users to use sendmail".
However, it can also be the case that your mail server is being overloaded with bounce messages, due message delivery failure.
For the sake of further testing and discussion: clean up the message queue, delete all messages (note that you have to filter out specific, relevant messages, do not delete them).
d) in the fourth post:
A further update on this... an end-user reported that they couldn't send emails from their webmail client. I logged in and tried to send an email - I received this error - SMTP Error: [451] 4.7.1 Service unavailable - try again later ....
This does not really alter anything, it certainly does not change the ISSUES on hand: your mail service is down, due to an overload.
e) in another post (lost count of the posts):
I guess this is what the "allow scripts and users to use sendmail" tag is for (or supposed to be for) but that's been enabled all the way along and doesn't seem to be doing what it should.
Yes, indeed, scripts are allowed to send mail, which causes the issue of your mail server overloading and not working properly.
Again, flush the queue.
f) in another post:
I've also tested the webmail user that was having issues and whilst he couldn't send email initially he could after a few tries. Switching outgoing mail control back on initially didn't help, and now he can send emails even with it switched on. I'm starting to wonder if this is greylisting-related but that's another story!! So is there any way to whitelist all SSH users in this fashion?
Indeed, it has nothing to do with grey listing, your mail server is simply overloaded, due to some elaborate hack OR your own doing (testing too much, augmented with other mails).
And no, you would not want to whitelist SSH users:
- only one SSH user should be present: a root uses (anything else would be unsafe)
- whitelisting the root user is completely not necessary (by default, the root user is allowed to send mails via scripts, no action has to be taken)
- whitelisting other SSH users is really "wrong" (your system will be very vulnerable, if other SSH users exist and/or if they are whitelisted)
In short, try to discard as many SSH users as you can.
g) and that is it, all relevant remarks from your posts are given.
It should be duly noted that you are looking for the wrong answer to the wrong question.
Just do the following:
- clean the complete mail queue,
- restart the mail server,
- check traffic: it is very likely that your mail server is being hacked and/or relaying (often malicious) mail traffic,
and that is it.
It can be the case that the problem (of not being able to send mail) re-occurs, but that will then be due to
A - a potential hack, hidden in some code somewhere, using the mail() function (to solve this: deactivate the "allow scripts and users to use sendmail" switch. If spikes in mail traffic still occur, than one of your accounts (mail, SSH and/or other types of accounts) is very likely to be hacked)
B - misconfiguration of the script actually calling the mail() function (note: this happens all the time, just have a look into the various error logs, to identify the script)
C - misconfiguration of mail server settings, for instance having "double accounts" (see point b).
In general, I would advice you to take actions in the order described above, from point A to C.
Regards.......
Facebook
Twitter
(
