I’m setting up a server that will deal with a mix of transactional and user e-mails. The user side of things I have no problem with, but the transactional e-mails are an issue.
I have multiple servers, call them A, B, C and D. Mail will only be sent from these servers with a FROM address of no-reply@DOMAIN, but each server needs its own unique login/account/mailbox rather than use a shared account and password.
I can’t see anything in the documentation which describes exactly this scenario, so I’d be grateful if somebody could let me know what is the best practice (easiest, most flexible, most maintainable) way of implementing this?
Many thanks,
N.
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
This gives me exactly the pieces I need. Let me confirm how to give multiple accounts the same associated email address (aliases) to satisfy mustMatchSender.
I’m not quite sure if that’s the start of an answer or if that’s meant to be the answer. If it is the answer, then I can’t add the same alias to multiple accounts - tried that! If it’s the start of an answer, then…
It’s not the full answer. When the bot outputs a statement saying it ‘needs to confirm / think about something’, the post times out and truncates early.
The developer is very good at answering questions in bulk every few days.
I have a temporary solution for this which is to use just one no-reply@… account and set up multiple app passwords for each user. That gives one mailbox with multiple independent authorisations and exactly what I need. The only problem with that is I have to log in as the no-reply user every time I need a new app password.
Aliases are unique per principal, so you are right that you cannot hang the same one off four accounts. What you want is a group: create a Group principal whose email address is no-reply@yourdomain, then add A, B, C and D as members. Each keeps its own login and password.
Members inherit the group’s addresses for sender authorization, so all four can use MAIL FROM: no-reply@yourdomain with no shared mailbox and no app-password juggling. Worth knowing about the side effect: mail addressed to no-reply@yourdomain lands in the group’s inbox, which members see as a shared folder over IMAP and JMAP, which is usually handy for catching bounces. Group principals cannot log in themselves.