nextcloud / nextcloud/activity

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

Open
#538 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug feature: email
Dominant language
JavaScript
Stars
145
Forks
72
Avg merge
6d 9h
Merged PRs (30d)
42

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.