On Thu, Feb 5, 2026 at 2:21 PM Stephen J. Turnbull <[email protected]> wrote:
> Here's the promised followup, starting where I left off earlier. > > >> Here's the Postfix doc: > >> > >> permit_auth_destination > >> Permit the request when one of the following is true: > >> > >> - Postfix is a mail forwarder: the resolved RCPT TO domain > >> matches $relay_domains or a subdomain thereof, and the address > >> contains no sender-specified routing (user@elsewhere@domain), > >> - Postfix is the final destination: the resolved RCPT TO domain > >> matches $mydestination, $inet_interfaces, $proxy_interfaces, > >> $virtual_alias_domains, or $virtual_mailbox_domains, and the > >> address contains no sender-specified routing > >> (user@elsewhere@domain). > > > I did read the documentation before adding it, I definitely > > misunderstood what it meant, and after looking at the old > > documentation, it makes sense not to add it. > > > > Could you help me understand what the above means? > > The name "permit_auth_destination" means that when the domain part of > the recipient is *authorized*, Postfix should proceed to route the > mail to final delivery. It can still be rejected (for example, if the > "user" part doesn't exist at "domain"), but checking that the final > destination host is authorized is an easy and cheap first screen. > > The two bullet points *define* "authorized". Both contain the phrase > "and the address contains no sender-specified routing". This > condition is imposed because > (1) you can't be sure that the MTA at "domain" will relay to > "elsewhere" rather than "spyagency, so stripping off > "user@elsewhere" and checking if "elsewhere" is authorized isn't > reliable, and > (2) on the modern Internet there's no need for sender-specified > routing anyway. > Both bullet points start with "Postfix is ...", but more fully this > should be "Postfix is acting to ... this message". > > The first bullet point then is saying "when the domain matches > $relay_domains or a subdomain, go ahead and relay." In other words, > this Postfix is acting as the MX for the domains in $relay_domains. > > The second bullet point is more complex, but it basically amounts to > various ways of saying "the final destination is local", or more > formally, under administrative control of the Postfix administrator > (and that's the difference with relay_domains, which are cooperative > agreements with those domains, but not controlled by this Postfix's > administrator). To understand why each of those variables means > "local", I'll ask you to look first at the Postfix docs because I'm > getting tired ;-): https://www.postfix.org/postconf.5.html. > Thank you, this was helpful. > > > Yes, this host is dedicated to Mailman. > > See comments above each restriction: > > > These are listed in smtpd_relay_restrictions; > > /* local IP addresses */ > > permit_mynetworks > > /* explicitly authenticated *sender* by SASL */ > > permit_sasl_authenticated > > /* reject destinations not authorized by > > permit_auth_destinations */ > > reject_unauth_destination > > /* I think these two are redundant, messages rejected > > by them can't get past reject_unauth_destination */ > > reject_unknown_recipient_domain > > reject_non_fqdn_recipient > > /* This is complicated, but the main point is that the > > above criteria can be bypassed by aliases */ > > reject_unlisted_recipient > > Very helpful, thank you! > > I'll remove permit_sasl_authenticated, as my assumption no longer > > holds. That's why I disabled it earlier because I remembered it > > was never used for delivery, but then I remembered there was a > > conversation about the marketing alias so I assumed it was used for > > sending out emails. > > That sounds right to me based on our conversations, but if you change > your mind and decide you want to add more conditions, feel free to > consult then. > Thank you, I hope that doesn't happen. > > > I did set one for the mailman user, seems I'll have to remove it and > > disable saslauthd too. > > Yes, I think it's best to require that access to 'su mailman' be > restricted to root and/or sudo. > Yes, this is the case at the moment. I've deleted the user password for mailman. > > > Yes, this is where I'm headed as that's what I need. > > Good luck! > Thank you! I'll have to look at why the confirmation email gets bounced later, this is all I have time for. > From your second message: > > > After making the above changes I talked about, mail transfer seems > > to work as expected, > > Hurray! > > > although I noticed users signing up don't get their confirmation > > emails delivered for some reason, saw this in the logs; > > > > (1632818) > <[email protected]> > > delivery to [email protected] failed with code 550, b'5.1.1 > > <[email protected]>: Recipient address rejected: User unknown in > local > > recipient table' > > > > What would be the best way to ensure that these get delivered? > > I don't understand why this would not be delivered. My best guess > would be that you have "sugarlabs.org" in $mydomain (this is actually > Postfix's default), so that Postfix thinks lists.sugarlabs.org is a > mail gateway for the parent domain. What "mail gateway" means is that > this host has direct write access to mailboxes "at" that domain. This > could be because it's a local or network file system mounted on this > host, or it could be a network transport to an IMAP server, that kind > of thing. But "lists" isn't a gateway in that sense. > I've changed mydomain to lists.sugarlabs.org, and tried again, let's see if that works. > > > I think I went into this rabbit hole because of this particular > > issue above, and I thought something was wrong, mail was always > > sent to the mailman user and I thought that was odd, but now I know > > that's expected as that's the user that Mailman runs on. > > Yes, I think that what's happening is that "something went wrong" and > some error message was mailed back to <[email protected]>. > Thank you for all your help, I really appreciate it. > > Sincere regards, > > Steve > > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan > -- Ibiam Chihurumnaya [email protected] _______________________________________________ Mailman-users mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/[email protected]/message/S2XJGON6GEK6H3LPFHVALLJHJNI22GCX/ This message sent to [email protected]
