nextcloud / activity

:zap: Activity app for Nextcloud
115 stars 65 forks source link

Unlimited mail send retries with non-existent / deleted mail address #538

Open alx-tuilmenau opened 3 years ago

alx-tuilmenau commented 3 years ago

Steps to reproduce

  1. Add an account with a non-existent mail address (here the mail address comes from an LDAP Source, but may also accour with deleted mail adresses on normal accounts; mail address is in our domain, see mailserver note below)
  2. Create some activity e.g. share something with this account

Here I have to add, nextcloud uses directly our domain mailserver via smtp without a local MTA. This mailserver will verify RCPT and return an error on non-existent RCPT mail addresses inside our domain directly (55x on RCPT) .

Expected behaviour

In the cronjob, after failing sending the mail, retry a limited number of times, e.g. 3. If it's still failing again, log a warning and do not try again sending mails / remove entries from mq.

Actual behaviour

Cronjob tries to send a new mail on every call (15 Minutes), filling up the mail server log with error messages. Notification is never removed from activity_mq.

Server configuration

Operating system: Debian 10 Web server: Apache / php_fpm Database: MariaDB PHP version: 7.3.22 Nextcloud version: (see Nextcloud admin page) 19.0.6 Where did you install Nextcloud from: Upgrade List of activated apps: Activity 2.12.1, LDAP 1.9.1

Are you using an external user-backend, if yes which one: LDAP

Client configuration

Browser: Firefox Operating system: Win 10

Logs

no error messages in Apache/Browser/Nextcloud logs. But mailserver log fills up with many tries to send to an non-existent mailadress.

microm3nn commented 3 years ago

It is exactly the same for me. Some solution?

alx-tuilmenau commented 3 years ago

As temporary workaround I added $deleteItemsForUsers[] = $user; in apps/activity/lib/MailQueueHandler.php sendEmails function after the logging of the error Messages. But this is ugly, because it will disable re-sending mails completely.

I propose to add a user config value for the number of failed mails and use this to limit retries. It should be increment on every failed mail and reset to 0 if a mail is successful sent (and the value is gerater 0). Maybe with an additional value with a timestamp of last try so the intervals on retrying the mails can be adjusted (1st retry 15min / 2nd 1 hr / 3rd 4 hr / last 24hr).