Concerns: pushword/newsletter
Until now a bounce was only recorded when the transport refused the mail during the send itself. The common case is the other one: the relay accepts the message, the remote server refuses it a minute later, and the failure comes back as a separate mail to the envelope sender, which is a different address from the From: a reader sees. Nothing read it, so a dead address stayed subscribed and every campaign retried it, which is how a sending reputation is spent.
pw:newsletter:bounces reads the mailbox those failures land in. Nothing changes for a site that does not configure one.
Point the envelope at a mailbox nobody reads by hand, and say where it lives:
# config/packages/mailer.yaml
framework:
mailer:
envelope:
sender: bounce@example.com
# config/packages/pushword.yaml
newsletter:
bounce_maildir: /home/user/mail/example.com/bounce
Then read it from cron, next to the tick:
0,15,30,45 * * * * cd /path/to/app && bin/console pw:newsletter:bounces -q
Start with --dry-run, which says what it would drop without touching the database or the mailbox.
On a shared host this needs nothing else: a bounce is a file, delivered next to every other mailbox, so there is no IMAP extension to compile, no webhook to expose and no credentials to store. A mailbox that only exists on a remote IMAP server is out of scope.
Three things worth knowing before pointing it at a live mailbox:
Status: 5.x.x). A 4.x.x is a mailbox that was full an hour ago, and dropping a reader over one loses an address the next retry reaches,cur/ with the seen flag, including the mail that was not a bounce at all. The same mailbox collects the delivery failures of every other mail the app sends, and those are counted and reported without anybody being touched.The envelope sender is global to the app, so check the domain before setting it: SPF authenticates the envelope, and DMARC wants it aligned with the From: domain. A bounce address on the same domain keeps that alignment; one on another domain leaves it resting on DKIM alone.