How to properly implement mailing lists? #3612
|
Hi all, I'm building out a mailing list feature for my Haraka-based service, and I'm looking for some advice on how to do it properly. Is there a way to tell Haraka that an email address expands to multiple others, or is that something I would manage in my own plugins? I have a rcpt hook that checks that the recipient exists and the sender isn't blocked and all that, but afaict, once I return OK in that, there will only be one call to my queue plugin. Is it a good idea to send a note over to my queue plugin with the expanded list of addresses and just run through the list delivering email to each recipient, or is there a way to have my queue hook called multiple times for one mail transaction? Thank you, |
Replies: 1 comment 1 reply
|
The queue hook is message/transaction oriented, not “once per expanded recipient.” A transaction may already contain several For simple aliases, use recipient expansion before queueing. Haraka now lists A mailing list is a larger job than aliasing. The queue/list layer should persist the accepted message once, resolve and snapshot the membership, then enqueue outbound deliveries in controlled batches (or one envelope per member when you need per-recipient bounce tracking). Keep expanded recipients in the SMTP envelope, not in visible That layer also needs to own:
So your proposed queue-plugin note can work, but pass a stable list/message identifier rather than a large mutable recipient array between hooks. Re-read membership at acceptance time, store the resulting delivery plan transactionally, return success only after that plan is durable, and let background workers deliver it. For a full public list, using a dedicated list manager behind Haraka is usually safer; for small internal aliases, the aliases plugin plus normal outbound delivery is enough. |
The queue hook is message/transaction oriented, not “once per expanded recipient.” A transaction may already contain several
RCPT TOvalues, and the queue plugin receives that transaction once after DATA. I would not try to manufacture repeated queue-hook calls.For simple aliases, use recipient expansion before queueing. Haraka now lists
haraka-plugin-aliasesas the dedicated alias plugin. That is the appropriate model whenteam@example.comis only a convenience address that maps to a small set of mailboxes.A mailing list is a larger job than aliasing. The queue/list layer should persist the accepted message once, resolve and snapshot the membership, then enqueue outbound deliveries in …