• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

auto-reply in dovecot & horde based webmail not working properly

TomBoB

Regular Pleskian
Username:

TITLE


auto-reply in dovecot & horde based webmail not working properly

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk 18.0.50 #1, AlmaLinux 8.7 latest updates

PROBLEM DESCRIPTION

When auto-reply / vacation filter is turned on in webmail, the auto-reply mail is generated and sent in such a way that some receiving servers refuse the auto-reply mail. See details under additional info below.

STEPS TO REPRODUCE

set up email account and webmail. Choose either Dovecot or Horde. Set up an auto-reply / vacation response and have it active. Send a mail from a gmail (or yahoo) address to the account that has the auto-response active.

ACTUAL RESULT

No auto-reply mail is received on the gmail or yahoo account.

EXPECTED RESULT

Auto-reply is received.

ANY ADDITIONAL INFORMATION

- SPF, DMARC, DKIM all set up perfectly for the domain
- If auto-reply is set up in the domains control panel, it works flawless. So is limited to webmail only.
- We use PES on all server. May or may not play a role.
- Have tested it across three servers. All servers exhibit same behaviour.
Incoming Mails from other Plesk servers do get auto replies. Mails originating from a different domain on the same Plesk server also get an auto response. Mail from an outlook.com address get the auto-reply.
But incoming mails from gmail or yahoo for example do not get the auto-reply.

The attempted auto-reply to the yahoo email address produced an error:
23E0743443: to=<[email protected]>, relay=mta5.am0.yahoodns.net[67.195.228.109]:25, delay=3.1, delays=0.53/0.02/1.4/1.2, dsn=5.7.9, status=bounced (host mta5.am0.yahoodns.net[67.195.228.109] said: 554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes (in reply to end of DATA command))

As the auto reply when set up in the control panel works perfect, but the one in webmail does not (to certain servers) it appears/indicates that the one generated (and/or sent) from webmail does not use some or all of the security measures available and is thus blocked.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
This is not a bug. It is merely a behavior of the recipient server. Please check the section "What are 5XX (553 and 554) permanent errors?" on https://senders.yahooinc.com/smtp-error-codes/. It will not be possible to do code changes to emails to accomodate special requirements of GMail or Yahoo. Unless mails are formatted incorrectly, it is up to the recipient server to decide how to handle them. Mails sent are formatted correctly so there will not be anything that we can do about it.
 
Hi Peter, thanks, but I would tend to disagree. To me this is a config/programming issue on Plesks side.

1) Log into the plesk server. Go to a subscription. Pick an email account. Set up an auto-reply with whatever text. Works flawlessly. Anywhere. To any receiving mail server worldwide. [incl gmail]

Remove that auto-reply.
2) Log into webmail of above email account. Now set up an auto-reply with the exact same dates and text. This auto-reply does NOT get accepted by all receiving mail servers. [gmail accounts don't get it]
----
To put it another way: Same email account on the same Plesk server [same IP], sent to same gmail account. If the auto-reply is Plesk Control Panel generated, it works. If the auto-reply is Plesk webmail generated, it does not work.
----
Pure logic conclusion: Same server sending, same server receiving, same date, same text, only difference: how the mail was generated (and/or the way it was sent) [Control Panel vs Webmail].

Normally I'd look at the code and compare how the generation (and sending) of auto-replies from Control Panel and Webmail differ. But that's hidden away in Plesks encrypted coding, so no option of us Plesk users.

Anyway, my way of logic reasoning. Please still pass it briefly by the dev folks and see if they might agree with my reasoning above. Alternative is we have to tell all our clients they can't use webmail based out-of-office as it's not working reliably to all mail servers.
 
I have to respectfully decline the request ;). I agree that there is a different behavior between an auto-reply through the mail server directly or an auto-reply that is the result of a Webmail filter configuration. These two generate two different ways of mail responses. You can check it easily by using any other address as a test address and then examining the mail header (the invisible part, the source code mail header) of the auto-replies. Also watch what's happening in the maillog.

The thing is that Roundcube and Horde are third-party applications. Plesk will not re-program them. The best you could do is to post the issue to Roundcube developers and ask if they know why this is happening. But most likely it happens, because some extra headers are set.

It is also a known issue that when you send a mail from your GMail account to your auto-reply Plesk account, you will not be able to receive the response at GMail, because GMail is blocking it (for not so clear reason). But that is also something not the server or Plesk can handle, because the mail server (Postfix for example) just transports the content as it is submitted by Webmail.

If you have specific findings from headers or maybe Yahoo support or Roundcube, please share them.
 
Forgot to mention to make sure that your hostname is set in your Postfix configuration file. If "myhostname" is not set or set to a wrong domain name, this will trigger blocking of mails sent through Webmail applications at many destinations.
 
Thanks for the detailed reply, as always :) yes myhostname is set. :) Took us some years to get all the settings near-perfect, but I think we're there. Works smooth as butter currently :)

Will dig into the details including header as you suggest, and then take it from there.

Best regards,
Tom
 
Back
Top