0

I have been playing with this issue that was discovered initially when people were unable to use the vacation feature in roundcube, it would provide a 554 5.7.1 *@gmail.com: Relay access denied 554 5.0.0 Service unavailable <<< 421 4.7.0 mx1-us1.ppe-hosted.com Error: too many errors

This mail server is used in conjunction with proof point. And I can verify that all the aliases and whatnot are setup correctly. All the accounts I tested can send external mail just fine from a client like Thunderbird.

However, if they set the vacation/out of office setting, it provides the above relay access denied. And whenever I try to test within command line, I am now also getting the same relay access denied.

No major changes have been made to this server for some time. I only changed an ssl certificate several months ago and that's it.

Here are also some of the errors from the roundcube logs:

[02-Jun-2022 08:40:26 America/Toronto] PHP Warning:  ssh2_sftp(): Unable to startup SFTP subsystem: Timeout waiting for response from SFTP subsystem in /var/www/html/roundcube/plugins/vacation/lib/sshftp.class.php on line 43 
[02-Jun-2022 08:40:30 America/Toronto] PHP Warning:  ssh2_sftp(): Unable to startup SFTP subsystem: Timeout waiting for response from SFTP subsystem in /var/www/html/roundcube/plugins/vacation/lib/sshftp.class.php on line 43
[02-Jun-2022 08:40:30 America/Toronto] PHP Warning:  ssh2_sftp_realpath() expects parameter 1 to be resource, boolean given in /var/www/html/roundcube/plugins/vacation/lib/sshftp.class.php on line 169
[02-Jun-2022 08:40:30 America/Toronto] PHP Warning:  file_put_contents(ssh2.sftp:///.forward): failed to open stream: operation failed in /var/www/html/roundcube/plugins/vacation/lib/sshftp.class.php on line 171
[02-Jun-2022 08:40:30 -0400]: <ojnnavsp> PHP Error: Vacation plugin: Cannot upload /.forward. Check permissions and/or server configuration in /var/www/html/roundcube/plugins/vacation/lib/sshftp.class.php on line 0 (POST /?_task=settings&_action=plugin.vacation-save)

1 Answers1

0

I ended up solving this issue when in proof point I figured out that our mail server was attempting use a slightly different domain. Ex: mail.example.com was our main, but it was trying mail3.example.com instead. Such a small thing, but making sure these had functional accounts and proper MX records actually solved it.