Aws Ses Monitor Bundle Laravel Package

Getting Started

• Treat this as a legacy Symfony + SwiftMailer bundle. First check its composer.json constraints and README: it is only a direct fit if your application still uses SwiftMailer. On Symfony Mailer/Symfony 6+, expect to write an adapter rather than use the built-in SwiftMailer filter.
• Install with Composer:

  composer require serendipity_hq/aws-ses-monitor-bundle
  

• Enable the bundle class named in the README in config/bundles.php or your legacy AppKernel.
• Look first at:
  • README.md for config keys, command names, routes, and SwiftMailer setup.
  • DependencyInjection/Configuration.php for the real configuration tree.
  • Command/ for the SES/SNS setup command.
  • Controller/ and Resources/config/ for the SNS endpoint and service wiring.
  • Tests/fixtures for expected SNS payload shapes.
• Configure AWS region/credentials, SNS topic ARNs, and the SwiftMailer filter in your Symfony config. Prefer environment variables over committed credentials.
• Run the setup command to create/configure SNS topics and SES notifications. Find it with:

  bin/console list | grep -i ses
  

  Run it in a sandbox AWS account first; it may create topics, subscriptions, and SES notification settings.
• Expose and subscribe the SNS endpoint:

  bin/console debug:router | grep -i sns
  

  Subscribe the SNS topic to that HTTPS endpoint and confirm the subscription. The endpoint must be publicly reachable with valid TLS.
• First practical use case: stop sending password resets, receipts, and other transactional mail to addresses that hard-bounced or complained.

Implementation Patterns

• Route all outbound mail through the monitored mailer. The SwiftMailer filter only protects messages sent through the Mailer it is attached to. If you have multiple mailers or custom transports, enable the filter everywhere or centralize sending.
• Pre-filter recipient lists for bulk mail. Treat the bundle as a last line of defense. Before a campaign, query the suppression store and remove hard-bounced/complained addresses; then let the SwiftMailer filter catch mistakes.
• If using Symfony Mailer, write an adapter. Add a MessageEvent listener or transport decorator that checks the bundle’s suppression repository before send. Do not depend on SwiftMailer events in a modern stack.
• Keep the SNS controller thin. If the bundle ships an HTTP SNS endpoint, let it validate/parse and delegate to handlers. If you prefer SQS, run a worker that passes the same SNS envelope into the bundle’s handler service.
• Make notification handling idempotent. Store SNS MessageId and ignore duplicates. SNS delivery is at-least-once, and retries are normal.
• Separate environments. Use different SNS topics, subscriptions, and suppression stores for dev/staging/prod. Never let a staging bounce suppress a production customer.
• Use least-privilege IAM. The app needs SNS subscribe/confirm and any SES read permissions the bundle requires. SES itself needs permission to publish to the SNS topic. Let the setup command create policies where appropriate, then review them.
• Test with SES mailbox simulator addresses. Send to [email protected], [email protected], and delivery simulator addresses to generate real events without harming real recipients.
• Log and alert on notification type. Capture bounce type, complaint feedback type, normalized email, and SNS message ID. Alert on complaint-rate spikes and hard-bounce increases.

Gotchas and Tips

• SwiftMailer is the biggest adoption blocker. SwiftMailer is deprecated/removed in modern Symfony. The bundle’s built-in filter is not useful for Symfony Mailer apps without an adapter. Pin the version and isolate the dependency behind your own suppression interface.
• SNS payloads are doubly encoded. The SNS envelope has Type, MessageId, etc.; the Message field is a JSON string containing the SES notification. Parse the envelope, then parse Message.
• Handle subscription confirmation. SNS sends SubscriptionConfirmation before notifications. The endpoint must confirm it, and production signature validation should not be disabled.
• Do not suppress on every bounce. SES bounce notifications include bounceType (Permanent, Transient, Undetermined). Suppress permanent/undetermined hard bounces; do not permanently suppress transient bounces. Always suppress complaints.
• Delivery notifications are noisy. They are high-volume and usually unnecessary for suppression. Enable them only if you have a concrete delivery-tracking use case.
• Normalize email addresses. Lowercase, trim, and decide how to handle plus aliases and per-tenant scoping. Otherwise the same person can bypass suppression with address casing differences.
• Suppression is not real-time prevention. A message already queued can still go out before a complaint is processed. Re-check suppression before releasing queued/bulk mail.
• The setup command can overwrite SES notification settings. Review its effect on existing identity/configuration-set notification topics and SNS topic policies before running in production.
• SES notifications are region- and identity-scoped. Confirm the bundle configures the same region, verified identity, and configuration set you actually send from.
• If the bundle ships Doctrine entities, run migrations. Check Resources/config/doctrine and the README. If it uses cache or another store, verify persistence and clearing behavior.
• Clear Symfony’s config cache after changing env/config. Use bin/console debug:config <bundle-alias> to confirm keys are actually recognized.
• Low maintenance risk. With few stars and no dependents, wrap suppression checks behind your own service/repository. That lets you replace the bundle later without touching every mail call site.