nextcloud / nextcloud/activity
Unlimited mail send retries with non-existent / deleted mail address
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 145
- Forks
- 72
- Avg merge
- 6d 9h
- Merged PRs (30d)
- 42
Description
Steps to reproduce
- 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)
- 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the Activity cron job's failed-send handling and the activity_mq queue described in the report. Reproduce a send to a non-existent address and trace how repeated failures are queued. Done means failures are retried only a limited number of times, then logged and removed or suppressed from activity_mq.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100