A bounce in one organization suppresses the recipient for every organization
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by reading services/email/msa/models.py, especially SuppressionQuerySet.is_suppressed, then trace the only writer in services/email/msa/tasks.py at record_bounce. Determine the intended organization scope, expiry, and owner-visible behavior for cross-organization bounces; done means those decisions are recorded and covered by the relevant behavior tests.
Written by the indexing model from the issue text.
Description
A bounce in one organization suppresses the recipient for every organization. One tenant can block a shared recipient address for all tenants for 30 days.
SuppressionQuerySet.is_suppressed treats a bounce entry from any organization as suppressing for 30 days, regardless of which organization is sending:
models.Q(org=org)
| models.Q(reason=self.model.Reason.BOUNCE, created_at__gte=bounce_cutoff)
A single permanent 5xx for a shared recipient address therefore blocks that address relay-wide for every other tenant. Examples of such a 5xx are a policy refusal, a spam block, or a full mailbox at the receiving host. The block also hits tenants that have a healthy relationship with the recipient. The suppression entry carries no indication of which tenant produced it. There is no owner-visible reason beyond the word "bounce".
Evidence:
services/email/msa/models.py:SuppressionQuerySet.is_suppressedservices/email/msa/tasks.py:record_bounce, the only writer of bounce entries
Decisions to make:
- Must a cross-organization bounce suppress at all?
- Must it expire faster than an organization's own bounce?
- How does an organization learn that a recipient it never mailed is suppressed for it?
Found during the sandbox-credentials change (#259). This fault is older than that change.
- Dominant language
- Python
- Stars
- 4
- Forks
- 0
- Avg merge
- 2h 40m
- Merged PRs (30d)
- 163
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- No contributing 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.
More from codingjoe/relay
-
enhancement real sec
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
codingjoe/relay#410 · 1 comment ·
Maintainers usually reply within 1 day
-
bug side quest
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
bug side quest
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
bug side quest
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
side quest test
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
Similar issues
-
Link Checker ReportOpenautomated issue linkchecker report
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
QuantEcon/lecture-python.myst#1098 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
podly-pure-podcasts/podly_pure_podcasts#279 ·
Maintainers usually reply within 1 day
-
template-proposal
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
OpenShot/openshot-qt#6230 ·
Maintainers usually reply within 1 day