[pfx] Re: transport question
On Fri, Sep 13, 2024 at 01:31:46AM +, Marcus Park wrote:
> I currently have 3 nodes as postfix servers.
> One is the main server which accepts messages from clients via submission.
> The main server routes messages out via another postfix (a or b) by the
> setting of relay_host.
> For now I want to route messages by sender domains. So I was asking the info
> here.
>
Read:
http://www.postfix.org/ADDRESS_REWRITING_README.html#resolve
https://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
Then:
main.cf:
sender_dependent_default_transport_maps =
{ { @a.example = smtp:[postfix-a.example] }
{ @b.example = smtp:[postfix-b.example] } }
I am advising against use of sender_dependent_relayhost_maps, because of
its much lower priority, and because you typically do not want to
override the relayhost for your own "relay" domains, and only need the
nexthop overrides for outbound traffic to external domains.
That said, compare the docs for the two parameters, and make your own
conclusions if unexpectedly your needs dictate sender-dependent nexthop
selection even for you "relay" domains.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: transport question
Hi Victor, Sorry for my less info in last mail. I currently have 3 nodes as postfix servers. One is the main server which accepts messages from clients via submission. The main server routes messages out via another postfix (a or b) by the setting of relay_host. For now I want to route messages by sender domains. So I was asking the info here. Can you give further help? Thanks. September 13, 2024 at 9:04 AM, "Viktor Dukhovni via Postfix-users" wrote: > > On Fri, Sep 13, 2024 at 12:11:43AM +, Marcus Park via Postfix-users wrote: > > > > > I have two domains in my system, say they are a.com and b.com > > I want the sender (sasl user) in a.com to use postfix-a as outgoing mta. > > and b.com uses postfix-b as outgoing server. > > > > How can I implement this? you could kindly give a hint, for which I > > can research by myself. > > > This is impossible to answer, you've provided no information about the > mail flow prior to the required relaying via postfix-a and postfix-b. > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org >___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: transport question
On Fri, Sep 13, 2024 at 12:11:43AM +, Marcus Park via Postfix-users wrote: > I have two domains in my system, say they are a.com and b.com > I want the sender (sasl user) in a.com to use postfix-a as outgoing mta. > and b.com uses postfix-b as outgoing server. > > How can I implement this? you could kindly give a hint, for which I > can research by myself. This is impossible to answer, you've provided no information about the mail flow prior to the required relaying via postfix-a and postfix-b. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] transport question
Hello I have two domains in my system, say they are a.com and b.com I want the sender (sasl user) in a.com to use postfix-a as outgoing mta. and b.com uses postfix-b as outgoing server. How can I implement this? you could kindly give a hint, for which I can research by myself. Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
trešd., 2024. g. 7. aug., plkst. 03:18 — lietotājs Viktor Dukhovni via Postfix-users () rakstīja: > > On Tue, Aug 06, 2024 at 09:05:20PM +0300, Dāvis Mosāns via Postfix-users > wrote: > > > That's the issue, transport map I have: > > transport_maps = lmdb:/etc/postfix/transport > > with: > > * smtp:internal.example.org > > Wildcard transport overrides are best avoided. > > > It's used for both cases. > > Which is not what you want. > > > I want forward/relay all incoming mail for all domains not just few. > > Not *all* domains, rather just the domains for which you accept mail, > presumably in this case "relay_domains", for example, any bounces to > external senders should presumably go out to the appropriate responsible > external SMTP servers. > All, because one goal is to collect spam messages. There won't be any bounces since all mail is accepted. > > But even with this approach it doesn't work as in mail from > > submissions port is still forwarded which is not what I want. > > I tried: > > transport_maps = lmdb:/etc/postfix/transport > > relay_domains = $mydestination lmdb:/etc/postfix/relay > > relay_recipient_maps = > > relay_transport = relay > > Instead: > > relay_transport = relay:internal.example.org > Interestingly this works how I want. I thought "relay_transport = relay" with transport_maps would be same thing... > and a comprehensive table of valid recipients for > "relay_recipient_maps", because without recipient validation you're > going be a source of backscatter that will harm your IP reputation, and > annoy joe-job attack victims. > There won't be backscatter because all mail is accepted. I don't think this would affect IP reputation. I have it implemented in internal postfix instance with: virtual_alias_maps = pcre:/etc/postfix/virtual virtual_alias_domains = $virtual_alias_maps where virtual contains: /^valid_email\@example\.org$/ valid_em...@example.org /^.+\@example\.org$/ inva...@example.org /^(?!(example\.org)).+$/ s...@example.org This way I can collect all spam that is sent no matter address/domain etc ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
On Tue, Aug 06, 2024 at 09:05:20PM +0300, Dāvis Mosāns via Postfix-users wrote: > That's the issue, transport map I have: > transport_maps = lmdb:/etc/postfix/transport > with: > * smtp:internal.example.org Wildcard transport overrides are best avoided. > It's used for both cases. Which is not what you want. > I want forward/relay all incoming mail for all domains not just few. Not *all* domains, rather just the domains for which you accept mail, presumably in this case "relay_domains", for example, any bounces to external senders should presumably go out to the appropriate responsible external SMTP servers. > But even with this approach it doesn't work as in mail from > submissions port is still forwarded which is not what I want. > I tried: > transport_maps = lmdb:/etc/postfix/transport > relay_domains = $mydestination lmdb:/etc/postfix/relay > relay_recipient_maps = > relay_transport = relay Instead: relay_transport = relay:internal.example.org and a comprehensive table of valid recipients for "relay_recipient_maps", because without recipient validation you're going be a source of backscatter that will harm your IP reputation, and annoy joe-job attack victims. If you're unable to construct the table, you may need to resort to dynamic recipient verification: https://www.postfix.org/ADDRESS_VERIFICATION_README.html -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
Wietse Venema via Postfix-users: > If you must route mail for ARBITRARY DESTINATIONS depending on what > service it was received with, then in many cases you will need > separate Postfix instances. Sorry, make that: if you must route mail for any destination depending on what service it was received with. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
D?vis Mos?ns: > piektd., 2024. g. 2. aug., plkst. 02:46 ? lietot?js Wietse Venema > () rakst?ja: > > > > D?vis Mos?ns via Postfix-users: > > > ceturtd., 2024. g. 1. aug., plkst. 09:10 ? lietot?js Wietse Venema via > > > Postfix-users () rakst?ja: > > > > > > > > Davis Mosans via Postfix-users: > > > > > Hi, > > > > > > > > > > I'm trying to setup Postfix in a way that will forward/relay all mail > > > > > on SMTP port 25 but send out (don't forward) email when receiving on > > > > > submission port 465. > > > > > > > > You cant to receive email on port 465 and want to send that out to > > > > the internet? That requires that the SMTP clients have relay > > > > permission (permit_sasl_authenticated, reject). > > > > > > > > You want to receive email on port 25 from local systems, and forward > > > > their messages to the internet? That requires that local SMTP clients > > > > have relay permission (permit_mynetworks, reject_unauth_destination). > > > > > > > > You want to receive email on port 25 from the internet and want to > > > > forward messages for specific destinations? See Configuring Postfix > > > > as primary or backup MX host for a remote site", > > > > https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup > > > > > > > > You want to receive email on port 25 from anywhere on the internet > > > > and want to forward messages to anywhere on the internet? Don't do > > > > that. > > > > > > > > > > None of that is what I want. Also it's not about permissions, those work > > > fine. > > > What I want is forward incoming email on port 25 to internal email > > > server but at same time deliver outgoing email from port 465 and that > > > shouldn't be forwarded to internal server. > > > > You don't need two instances for that. One will do just fine. > > > > - Receive email on port 465 and to send that out to the internet. > > That is handled by the smtps or submissions example in master.cf. > > No transport map needed. Just remove the '#' from those lines. > > > That's the issue, transport map I have: > transport_maps = lmdb:/etc/postfix/transport > with: > * smtp:internal.example.org > > It's used for both cases. > > > - Receive email on port 25 from the internet and forward messages > > for specific destinations? That involves a transport map and > > relay_domains as described in > > https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup > > > > I want forward/relay all incoming mail for all domains not just few. > But even with this approach it doesn't work as in mail from > submissions port is still forwarded which is not what I want. > I tried: > transport_maps = lmdb:/etc/postfix/transport > relay_domains = $mydestination lmdb:/etc/postfix/relay > relay_recipient_maps = > relay_transport = relay > > and /etc/postfix/relay with: > * - > > and /etc/postfix/transport with: > * relay:internal.example.org If you must route mail for ARBITRARY DESTINATIONS depending on what service it was received with, then in many cases you will need separate Postfix instances. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
piektd., 2024. g. 2. aug., plkst. 02:46 — lietotājs Wietse Venema () rakstīja: > > D?vis Mos?ns via Postfix-users: > > ceturtd., 2024. g. 1. aug., plkst. 09:10 ? lietot?js Wietse Venema via > > Postfix-users () rakst?ja: > > > > > > Davis Mosans via Postfix-users: > > > > Hi, > > > > > > > > I'm trying to setup Postfix in a way that will forward/relay all mail > > > > on SMTP port 25 but send out (don't forward) email when receiving on > > > > submission port 465. > > > > > > You cant to receive email on port 465 and want to send that out to > > > the internet? That requires that the SMTP clients have relay > > > permission (permit_sasl_authenticated, reject). > > > > > > You want to receive email on port 25 from local systems, and forward > > > their messages to the internet? That requires that local SMTP clients > > > have relay permission (permit_mynetworks, reject_unauth_destination). > > > > > > You want to receive email on port 25 from the internet and want to > > > forward messages for specific destinations? See Configuring Postfix > > > as primary or backup MX host for a remote site", > > > https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup > > > > > > You want to receive email on port 25 from anywhere on the internet > > > and want to forward messages to anywhere on the internet? Don't do > > > that. > > > > > > > None of that is what I want. Also it's not about permissions, those work > > fine. > > What I want is forward incoming email on port 25 to internal email > > server but at same time deliver outgoing email from port 465 and that > > shouldn't be forwarded to internal server. > > You don't need two instances for that. One will do just fine. > > - Receive email on port 465 and to send that out to the internet. > That is handled by the smtps or submissions example in master.cf. > No transport map needed. Just remove the '#' from those lines. > That's the issue, transport map I have: transport_maps = lmdb:/etc/postfix/transport with: * smtp:internal.example.org It's used for both cases. > - Receive email on port 25 from the internet and forward messages > for specific destinations? That involves a transport map and > relay_domains as described in > https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup > I want forward/relay all incoming mail for all domains not just few. But even with this approach it doesn't work as in mail from submissions port is still forwarded which is not what I want. I tried: transport_maps = lmdb:/etc/postfix/transport relay_domains = $mydestination lmdb:/etc/postfix/relay relay_recipient_maps = relay_transport = relay and /etc/postfix/relay with: * - and /etc/postfix/transport with: * relay:internal.example.org To give an example: Someone sends me email using port 25 with address example.com then I want to forward it. Now when someone uses submissions port to send email to example.com I want to deliver it to actual example.com mail server but in this case it's still being forwarded to internal.example.org. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
D?vis Mos?ns via Postfix-users: > ceturtd., 2024. g. 1. aug., plkst. 09:10 ? lietot?js Wietse Venema via > Postfix-users () rakst?ja: > > > > Davis Mosans via Postfix-users: > > > Hi, > > > > > > I'm trying to setup Postfix in a way that will forward/relay all mail > > > on SMTP port 25 but send out (don't forward) email when receiving on > > > submission port 465. > > > > You cant to receive email on port 465 and want to send that out to > > the internet? That requires that the SMTP clients have relay > > permission (permit_sasl_authenticated, reject). > > > > You want to receive email on port 25 from local systems, and forward > > their messages to the internet? That requires that local SMTP clients > > have relay permission (permit_mynetworks, reject_unauth_destination). > > > > You want to receive email on port 25 from the internet and want to > > forward messages for specific destinations? See Configuring Postfix > > as primary or backup MX host for a remote site", > > https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup > > > > You want to receive email on port 25 from anywhere on the internet > > and want to forward messages to anywhere on the internet? Don't do > > that. > > > > None of that is what I want. Also it's not about permissions, those work fine. > What I want is forward incoming email on port 25 to internal email > server but at same time deliver outgoing email from port 465 and that > shouldn't be forwarded to internal server. You don't need two instances for that. One will do just fine. - Receive email on port 465 and to send that out to the internet. That is handled by the smtps or submissions example in master.cf. No transport map needed. Just remove the '#' from those lines. - Receive email on port 25 from the internet and forward messages for specific destinations? That involves a transport map and relay_domains as described in https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
ceturtd., 2024. g. 1. aug., plkst. 14:10 — lietotājs Viktor Dukhovni via Postfix-users () rakstīja: > > On Thu, Aug 01, 2024 at 12:54:16AM +0300, Dāvis Mosāns via Postfix-users > wrote: > > > and in master.cf I have: > > submissions inet n - n - - smtpd > >-o syslog_name=postfix/submissions > >-o smtpd_tls_wrappermode=yes > >-o smtpd_tls_security_level=encrypt > >-o smtpd_sasl_auth_enable=yes > >-o transport_maps=lmdb:/etc/postfix/submission_transport > > > > where submission_transport is empty file. > > This can't work, because the transport lookups that *matter* are > performed by qmgr(8) during delivery from the active queue, not smtpd(8) > while adding the message to the queue. There's only one shared qmgr(8), > so the transport(8) table is effectively global. > > If you want separate routing (transport table) of incoming and outgoing mail, > you need multiple Postfix instances. > > https://www.postfix.org/MULTI_INSTANCE_README.html > Nice! That works :) I created 2 instances where one master.cf has submissions inet n - n - - smtpd smtp unix - - n - - smtp without transport_maps and other has smtp inet n - n - - smtpd with transport_maps now it works exactly as I wanted. Also it turned out that I needed "smtp unix" otherwise it was failing with: postfix/qmgr[13862]: warning: connect to transport private/smtp: Connection refused Thanks! ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
ceturtd., 2024. g. 1. aug., plkst. 09:10 — lietotājs Wietse Venema via Postfix-users () rakstīja: > > Davis Mosans via Postfix-users: > > Hi, > > > > I'm trying to setup Postfix in a way that will forward/relay all mail > > on SMTP port 25 but send out (don't forward) email when receiving on > > submission port 465. > > You cant to receive email on port 465 and want to send that out to > the internet? That requires that the SMTP clients have relay > permission (permit_sasl_authenticated, reject). > > You want to receive email on port 25 from local systems, and forward > their messages to the internet? That requires that local SMTP clients > have relay permission (permit_mynetworks, reject_unauth_destination). > > You want to receive email on port 25 from the internet and want to > forward messages for specific destinations? See Configuring Postfix > as primary or backup MX host for a remote site", > https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup > > You want to receive email on port 25 from anywhere on the internet > and want to forward messages to anywhere on the internet? Don't do > that. > None of that is what I want. Also it's not about permissions, those work fine. What I want is forward incoming email on port 25 to internal email server but at same time deliver outgoing email from port 465 and that shouldn't be forwarded to internal server. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
On Thu, Aug 01, 2024 at 12:54:16AM +0300, Dāvis Mosāns via Postfix-users wrote: > and in master.cf I have: > submissions inet n - n - - smtpd >-o syslog_name=postfix/submissions >-o smtpd_tls_wrappermode=yes >-o smtpd_tls_security_level=encrypt >-o smtpd_sasl_auth_enable=yes >-o transport_maps=lmdb:/etc/postfix/submission_transport > > where submission_transport is empty file. This can't work, because the transport lookups that *matter* are performed by qmgr(8) during delivery from the active queue, not smtpd(8) while adding the message to the queue. There's only one shared qmgr(8), so the transport(8) table is effectively global. If you want separate routing (transport table) of incoming and outgoing mail, you need multiple Postfix instances. https://www.postfix.org/MULTI_INSTANCE_README.html -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Use different transport map for submission
Davis Mosans via Postfix-users: > Hi, > > I'm trying to setup Postfix in a way that will forward/relay all mail > on SMTP port 25 but send out (don't forward) email when receiving on > submission port 465. You cant to receive email on port 465 and want to send that out to the internet? That requires that the SMTP clients have relay permission (permit_sasl_authenticated, reject). You want to receive email on port 25 from local systems, and forward their messages to the internet? That requires that local SMTP clients have relay permission (permit_mynetworks, reject_unauth_destination). You want to receive email on port 25 from the internet and want to forward messages for specific destinations? See Configuring Postfix as primary or backup MX host for a remote site", https://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup You want to receive email on port 25 from anywhere on the internet and want to forward messages to anywhere on the internet? Don't do that. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Use different transport map for submission
Hi, I'm trying to setup Postfix in a way that will forward/relay all mail on SMTP port 25 but send out (don't forward) email when receiving on submission port 465. In main.cf I have: transport_maps = lmdb:/etc/postfix/transport and inside there I have * smtp:[internal.example.org]:2525 and in master.cf I have: submissions inet n - n - - smtpd -o syslog_name=postfix/submissions -o smtpd_tls_wrappermode=yes -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o transport_maps=lmdb:/etc/postfix/submission_transport where submission_transport is empty file. But when sent thru submission it still forwards those emails so it doesn't work. Any ideas how to configure setup like this? Thanks! Best regards, Dāvis ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: transport entries causing sender addresses to be rejected
On Mon, Jul 29, 2024 at 05:45:51PM +1000, Viktor Dukhovni via Postfix-users wrote: > On Mon, Jul 29, 2024 at 09:40:45AM +0200, Ralf Hildebrandt via Postfix-users > wrote: > > * Viktor Dukhovni via Postfix-users : > > > > > > Is this intentional or a side-effect? > > > > > > I'm guessing you have "smtpd_reject_unlisted_sender = yes"? > > > > Yes. > > > > > In that case, this'd be expected. > > > > OK! I was just wondering if I missed a reference somewhere in the > > docs, since I didn't really see this being mentioned in transport(5) > > Well, this isn't really about transport(5), but rather about the sender > resolving somehow to the "error" transport, which can also, e.g., happen > for unmatched localparts in virtual alias domains. An address that > resolves to the error transport, and is not rewritten by virtual > aliases, or similar,is presumptively invalid (unlisted). The right way to think about "smtpd_reject_unlisted_sender" is that it rejects any sender address that would be rejected if it were a recipient address. One situation in which recipients are rejected is when they're mapped to the error transport. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: transport entries causing sender addresses to be rejected
On Mon, Jul 29, 2024 at 09:40:45AM +0200, Ralf Hildebrandt via Postfix-users wrote: > * Viktor Dukhovni via Postfix-users : > > > > Is this intentional or a side-effect? > > > > I'm guessing you have "smtpd_reject_unlisted_sender = yes"? > > Yes. > > > In that case, this'd be expected. > > OK! I was just wondering if I missed a reference somewhere in the > docs, since I didn't really see this being mentioned in transport(5) Well, this isn't really about transport(5), but rather about the sender resolving somehow to the "error" transport, which can also, e.g., happen for unmatched localparts in virtual alias domains. An address that resolves to the error transport, and is not rewritten by virtual aliases, or similar,is presumptively invalid (unlisted). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] Re: transport entries causing sender addresses to be rejected
* Viktor Dukhovni via Postfix-users : > > Is this intentional or a side-effect? > > I'm guessing you have "smtpd_reject_unlisted_sender = yes"? Yes. > In that case, this'd be expected. OK! I was just wondering if I missed a reference somewhere in the docs, since I didn't really see this being mentioned in transport(5) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: transport entries causing sender addresses to be rejected
On Mon, Jul 29, 2024 at 09:28:51AM +0200, Ralf Hildebrandt via Postfix-users wrote: > Ever so often I'm using transport entries to bounce typo domains or > "noreply" addresses prior to the expiration after > $maximum_queue_lifetime. > > Something like: > noreplytoMMS.telekom.de error:5.1.2 Doesn't accept mail > > But I noticed that this also causes mails with the sender > domain/address being rejected when used as envelope sender. > > Is this intentional or a side-effect? I'm guessing you have "smtpd_reject_unlisted_sender = yes"? In that case, this'd be expected. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] transport entries causing sender addresses to be rejected
Hi! ever so often im using transport entries to bounce typo domains or "noreply" addresses prio to the expiration after $maximum_queue_lifetime. Something like: noreplytoMMS.telekom.de error:5.1.2 Doesn't accept mail But I noticed that this also causes mails with the sender domain/address being rejected when used as envelope sender. Is this intentional or a side-effect? -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration Invalidenstraße 120/121 | D-10115 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | https://www.charite.de ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
Matus UHLAR - fantomas via Postfix-users wrote in : |>* Bill Cole via Postfix-users: |>> Some systems are configured to "oversign" headers, essentially signing |>> the non-existence. | |On 24.07.24 02:11, Ralph Seichter via Postfix-users wrote: |>Shhh! We don't want to advertise that in this scenario, do we? ;-) |>Still, you are correct to point out that the DKIM spec allows for these |>kinds of shenanigans. | |in Debian/opendkim, only From: is oversigned, which is to prevent adding \ |fake |From: header which could confuse recipient and/or its MUA. | | |>> Any addition of headers that are oversigned will break a DKIM |>> signature. Some ill-advised systems oversign List-* headers on every |>> message. |> |>Ill-advised is putting it mildly. If one is messing with the headers |>which make mailing lists work, but allows their users to subscribe to |>mailing lists, one is more than a little cookoo. | |looking at RFC 6376 secion 5.4.1, it recommends signing these headers. | |However, together with comment above, it should be safe if you don't |oversign them - I don't expect List-* header to appears in any mail \ |sent to |the list, and their appearance can indicate error. "Oversigning maximum" seems built-in (possibly off-by-default) default, i think. (Also remembering a saying' of Scott Kitterman on some IETF list not too long ago, this year.) In the last version of my s-dkim-signa 0.6.2 (May 30th) i added even more (also mostly useless combinations like content-id: that normally not happen in the main header). It is just that normal user email should not seal headers that are necessarily placed by mailing-lists. Ie my own software has (thus) several built-in sets to choose from, with the special "+" variant to be used by mailing-lists only: #?0|kent:src$ /usr/lib/s-dkim-sign --header-seal-show @: author from subject date to cc resent-author resent-date resent-from resent-sender resent-to resent-cc resent-reply-to resent-message-id in-reply-to references *: author from subject date to cc resent-author resent-date resent-from resent-sender resent-to resent-cc resent-reply-to resent-message-id in-reply-to references mime-version content-type content-transfer-encoding content-disposition content-id content-description message-id mail-followup-to openpgp +: author from subject date to cc resent-author resent-date resent-from resent-sender resent-to resent-cc resent-reply-to resent-message-id in-reply-to references mime-version content-type content-transfer-encoding content-disposition content-id content-description message-id mail-followup-to openpgp reply-to list-id list-help list-subscribe list-unsubscribe list-post list-owner list-archive #?0|kent:src$ /usr/lib/s-dkim-sign --header-sign-show @: reply-to author from subject date to cc resent-author resent-date resent-from resent-sender resent-to resent-cc resent-reply-to resent-message-id in-reply-to references list-id list-help list-subscribe list-unsubscribe list-post list-owner list-archive *: reply-to author from subject date to cc resent-author resent-date resent-from resent-sender resent-to resent-cc resent-reply-to resent-message-id in-reply-to references list-id list-help list-subscribe list-unsubscribe list-post list-owner list-archive mime-version content-type content-transfer-encoding content-disposition content-id content-description message-id mail-followup-to openpgp Ie i personally use header-sign * header-seal * but for the mailing-lists i have a dedicated postfix master entry which uses "+": dkim-sign unix - n n - - spawn user=smtpd argv=/usr/libexec/s-dkim-sign -R /etc/postfix/dkim.rc dkim-sign-list unix - n n - - spawn user=smtpd argv=/usr/libexec/s-dkim-sign -R /etc/postfix/dkim.rc --header-seal=+ (ie via localhost:421 inet n - n - - smtpd -o syslog_name=lhlist -o smtpd_milters=unix:private/dkim-sign-list and mailman's DELIVERY_MODULE = 'SMTPDirect' SMTPHOST = 'localhost' # timbuktu SMTPPORT = 421) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only during dog days: | On the 81st anniversary of the Goebbel's Sportpalast speech | von der Leyen gave an overlong hypocritical inauguration one. | The brew's essence of our civilizing advancement seems o be: | Total war - shortest war -> Permanent war - everlasting war ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
* Bill Cole via Postfix-users: Some systems are configured to "oversign" headers, essentially signing the non-existence. On 24.07.24 02:11, Ralph Seichter via Postfix-users wrote: Shhh! We don't want to advertise that in this scenario, do we? ;-) Still, you are correct to point out that the DKIM spec allows for these kinds of shenanigans. in Debian/opendkim, only From: is oversigned, which is to prevent adding fake From: header which could confuse recipient and/or its MUA. Any addition of headers that are oversigned will break a DKIM signature. Some ill-advised systems oversign List-* headers on every message. Ill-advised is putting it mildly. If one is messing with the headers which make mailing lists work, but allows their users to subscribe to mailing lists, one is more than a little cookoo. looking at RFC 6376 secion 5.4.1, it recommends signing these headers. However, together with comment above, it should be safe if you don't oversign them - I don't expect List-* header to appears in any mail sent to the list, and their appearance can indicate error. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
* Bill Cole via Postfix-users: > Some systems are configured to "oversign" headers, essentially signing > the non-existence. Shhh! We don't want to advertise that in this scenario, do we? ;-) Still, you are correct to point out that the DKIM spec allows for these kinds of shenanigans. > Any addition of headers that are oversigned will break a DKIM > signature. Some ill-advised systems oversign List-* headers on every > message. Ill-advised is putting it mildly. If one is messing with the headers which make mailing lists work, but allows their users to subscribe to mailing lists, one is more than a little cookoo. -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
On 2024-07-22 at 18:58:41 UTC-0400 (Tue, 23 Jul 2024 00:58:41 +0200) Ralph Seichter via Postfix-users is rumored to have said: Adding *new* headers can't break existing DKIM signatures, because these headers cannot have been signed before. New in this case means header names (not values) which have not been present before. This is not always true. Some systems are configured to "oversign" headers, essentially signing the non-existence. Any addition of headers that are oversigned will break a DKIM signature. Some ill-advised systems oversign List-* headers on every message. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo@toad.social and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
Austin Witmer via Postfix-users: > On Jul 22, 2024, at 5:00?PM, Wietse Venema via Postfix-users > wrote: > > > > Austin Witmer via Postfix-users: > >>> You will need SPF, DKIM, and DMARC with 'p=reject'. If this is > >>> an interactive list, you will need to replace list member's From: > >>> headers with your mailing list address to satisfy DMARC. > >> > >> I believe I have SPF, DKIM and DMARC setup with p=reject. > >> > >> So the big list with 1500 members is not an interactive list and > >> probably will just have one sending (gmail) address. > > > > Your server is not gmail.com, so when you send BULK mail with a > > From: addr...@gmail.com from a non-gmail server, then that can > > be problematic. > > Would it be better in your opinion to setup a dedicated address > with a domain I own, on my server, for sending emails to a > non-interactive list this big so that the sending address is > "allowed" to send/relay mail through my server? That way I don't > have the appearance of sending email on behalf of a gmail account > from my server? I was assuming that your Postfix server has a proper hostname with reverse DNS that resolves to that hostname, and a domain name that is under your control. That has been a requirement for 20 years already. Then that would be an excellent choice for the From: domain, and for SPF, DKIM, and DMARC policies. > >> From what I was reading online, I thought "From munging" is not > >> necessary if I am not modifying the subject, body or existing email > >> headers. And thus the original senders DMARC won't be broken, > >> right? > > > > That may still work with low-volume PERSONAL mail, but the rules with > > BULK mail are different. > > Do you have any recommendations on how to accomplish this "From > munging" without using something like mailman? Perhaps a milter > of some kind? If there is only one authorized sender, then you could pipe the message through a script that replaces the authorized From: address with the desired one, before feeding the message into mlmmj. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
On Jul 22, 2024, at 5:00 PM, Wietse Venema via Postfix-users wrote: > > Austin Witmer via Postfix-users: >>> You will need SPF, DKIM, and DMARC with 'p=reject'. If this is >>> an interactive list, you will need to replace list member's From: >>> headers with your mailing list address to satisfy DMARC. >> >> I believe I have SPF, DKIM and DMARC setup with p=reject. >> >> So the big list with 1500 members is not an interactive list and >> probably will just have one sending (gmail) address. > > Your server is not gmail.com, so when you send BULK mail with a > From: addr...@gmail.com from a non-gmailk server, then that can > be problematic. Would it be better in your opinion to setup a dedicated address with a domain I own, on my server, for sending emails to a non-interactive list this big so that the sending address is “allowed” to send/relay mail through my server? That way I don't have the appearance of sending email on behalf of a gmail account from my server? > >> Will DMARC be broken if I only add the following headers to mailing >> list messages? >> >> X-Mailinglist: >> List-Id: >> List-Unsubscribe: >> List-Unsubscribe-Post: > > Unlikely. Note that the rules for BULK mail are defined by the > receiver. > >> From what I was reading online, I thought "From munging" is not >> necessary if I am not modifying the subject, body or existing email >> headers. And thus the original senders DMARC won't be broken, >> right? > > That may still work with low-volume PERSONAL mail, but the rules with > BULK mail are different. Do you have any recommendations on how to accomplish this “From munging” without using something like mailman? Perhaps a milter of some kind? > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
Austin Witmer via Postfix-users: > > You will need SPF, DKIM, and DMARC with 'p=reject'. If this is > > an interactive list, you will need to replace list member's From: > > headers with your mailing list address to satisfy DMARC. > > I believe I have SPF, DKIM and DMARC setup with p=reject. > > So the big list with 1500 members is not an interactive list and > probably will just have one sending (gmail) address. Your server is not gmail.com, so when you send BULK mail with a From: addr...@gmail.com from a non-gmailk server, then that can be problematic. > Will DMARC be broken if I only add the following headers to mailing > list messages? > > X-Mailinglist: > List-Id: > List-Unsubscribe: > List-Unsubscribe-Post: Unlikely. Note that the rules for BULK mail are defined by the receiver. > From what I was reading online, I thought "From munging" is not > necessary if I am not modifying the subject, body or existing email > headers. And thus the original senders DMARC won't be broken, > right? That may still work with low-volume PERSONAL mail, but the rules with BULK mail are different. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
* Austin Witmer via Postfix-users: > Will DMARC be broken if I only add the following headers to mailing > list messages? [...] Adding *new* headers can't break existing DKIM signatures, because these headers cannot have been signed before. New in this case means header names (not values) which have not been present before. > X-Mailinglist: > List-Id: > List-Unsubscribe: > List-Unsubscribe-Post: If, for example, a user sends any of his messages with X-Mailinglist: yes please! and also includes this header in his DKIM signature, you adding another header with the same name or replacing the value can break the existing signature. Headers with the 'X-' prefix are not standardised, so anybody can use them willy-nilly. Will they do that? Possibly. Remember that there are many weird people out there. ;-) -Ralph ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
On Jul 22, 2024, at 4:21 PM, Wietse Venema via Postfix-users wrote: > > Austin Witmer via Postfix-users: >> Hello all! >> >> I recently added mlmmj as a mailing list manager to my postfix server. >> >> My concern is that I don't overwhelm the big boys (yahoo, google, >> iCloud) and have them rate limit me because I am sending to too >> many addresses to quickly. >> >> Here are my transport settings for mlmmj. >> >> mlmmj_destination_concurrency_limit = 5 >> mlmmj_destination_concurrency_failed_cohort_limit = 10 >> mlmmj_destination_rate_delay = 1s >> mlmmj_destination_recipient_limit = 1 > > Caution: with mlmmj_destination_recipient_limit=1, the unit of > concurrency is the recipient address, not the domain name. Postfix > will deliver up to 5 recipients in parallel assuming that your SMTP > client process limit is 5 or more. > >> Are they sensible? Am I being overly cautious? Any suggestions for >> improvement? I have one mailing list I am setting up with over >> 1500 subscribers and so I want to get this right. > > You will need SPF, DKIM, and DMARC with 'p=reject'. If this is > an interactive list, you will need to replace list member's From: > headers with your mailing list address to satisfy DMARC. I believe I have SPF, DKIM and DMARC setup with p=reject. So the big list with 1500 members is not an interactive list and probably will just have one sending (gmail) address. Will DMARC be broken if I only add the following headers to mailing list messages? X-Mailinglist: List-Id: List-Unsubscribe: List-Unsubscribe-Post: From what I was reading online, I thought “From munging” is not necessary if I am not modifying the subject, body or existing email headers. And thus the original senders DMARC won’t be broken, right? Or is adding the headers I mentioned above modifying the message enough to break DMARC as well? > > You will need to start slow, and increase delivery rates in the course > of ~weeks. > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport settings for mailing list transport
Austin Witmer via Postfix-users: > Hello all! > > I recently added mlmmj as a mailing list manager to my postfix server. > > My concern is that I don't overwhelm the big boys (yahoo, google, > iCloud) and have them rate limit me because I am sending to too > many addresses to quickly. > > Here are my transport settings for mlmmj. > > mlmmj_destination_concurrency_limit = 5 > mlmmj_destination_concurrency_failed_cohort_limit = 10 > mlmmj_destination_rate_delay = 1s > mlmmj_destination_recipient_limit = 1 Caution: with mlmmj_destination_recipient_limit=1, the unit of concurrency is the recipient address, not the domain name. Postfix will deliver up to 5 recipients in parallel assuming that your SMTP client process limit is 5 or more. > Are they sensible? Am I being overly cautious? Any suggestions for > improvement? I have one mailing list I am setting up with over > 1500 subscribers and so I want to get this right. You will need SPF, DKIM, and DMARC with 'p=reject'. If this is an interactive list, you will need to replace list member's From: headers with your mailing list address to satisfy DMARC. You will need to start slow, and increase delivery rates in the course of ~weeks. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Transport settings for mailing list transport
Hello all! I recently added mlmmj as a mailing list manager to my postfix server. My concern is that I don’t overwhelm the big boys (yahoo, google, iCloud) and have them rate limit me because I am sending to too many addresses to quickly. Here are my transport settings for mlmmj. mlmmj_destination_concurrency_limit = 5 mlmmj_destination_concurrency_failed_cohort_limit = 10 mlmmj_destination_rate_delay = 1s mlmmj_destination_recipient_limit = 1 Are they sensible? Am I being overly cautious? Any suggestions for improvement? I have one mailing list I am setting up with over 1500 subscribers and so I want to get this right. Thanks! -- Austin ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
Jaroslaw Rafa via Postfix-users: > Dnia 21.05.2024 o godz. 22:27:04 Henri Schom?cker via Postfix-users pisze: > > > > So what we need to do is to limit the sending rate to all MX servers > > under protection-outlook-com. > > Postfix does not support this, Wietse probably could explain why. > You can select a transport by destination domain, but not by destination MX. > Probably what you need to do is to write an external program that interfaces > with Postfix via "socketmap" or "tcp" type lookup table, checks the MX for > the destination domain, and returns the name of the transport to be used. You could try to aggregate all deliveries for protection-outlook-com customers with a FILTER action.. check_recipient_mx_access hash:/etc/postfix/recipient_mx_access With recipient access actions like: protection-outlook-com filter smtp-protection-outlook-com And in master.cf have a dedicated SMTP client with that service name smtp-protection-outlook-com, and configure cocurrency limts and rate delays for that service name. I'm on vacation, so no time to workd out a complexrte example now. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
Dnia 21.05.2024 o godz. 22:27:04 Henri Schomäcker via Postfix-users pisze: > > So what we need to do is to limit the sending rate to all MX servers > under protection.outlook.com. Postfix does not support this, Wietse probably could explain why. You can select a transport by destination domain, but not by destination MX. Probably what you need to do is to write an external program that interfaces with Postfix via "socketmap" or "tcp" type lookup table, checks the MX for the destination domain, and returns the name of the transport to be used. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
On 5/21/24 13:27, Henri Schomäcker via Postfix-users wrote: So what we need to do is to limit the sending rate to all MX servers under protection.outlook.com. But it does not work with my configuration, all mails are still beeing sent directly one after another, and I can't find out why. So my question still remains: What's wrong with my config? Are back-to-back messages going to the same domain, or to different domains all hosted at the same MX? postfix's rate-limiting buckets are keyed either by the full destination email address (if *_destination_recipient_limit is 1) or by the domain part of the destination email address. There isn't a way to rate limit by the SMTP destination (however you define that). This has been discussed on this within the last year or so. I believe the conclusion at the time was that postfix doesn't have any easy way to do what you want. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
Hi nw, yes, it's an issue with protection.outlook.com Servers, but not with a blacklist. Ourcustomers are able to deliver about betweeen 700 and 1100 mails to recipient addresses which domains MX is under protection.outlook.com. And there seems to also be a configuration option for an incoming rate limit which seems to be 3600 mails/h like some admins of one customer told me. But that doesn't help at all because all domains which MX is under protection.outlook.com seem to have their own Outlook 365 Server configurations. So what we need to do is to limit the sending rate to all MX servers under protection.outlook.com. But it does not work with my configuration, all mails are still beeing sent directly one after another, and I can't find out why. So my question still remains: What's wrong with my config? Ah, and btw.: The missing p in slowersmtp in /etc/postfix/mx_transport_filter just got lost in copy & paste. So I still beg for help, many thanks in advance, regards Henri Am 20.05.24 um 00:00 schrieb Northwind via Postfix-users: This is most likely the issue of outlook, not yours. AFAIK outlook has the policy of IP blacklist. Maybe your IP happens to hit it. regards. After a few hundred mails to different addresses who's domains use a protection.outlook.com MX, the receiving servers respond with "...451 4.7.500 Server busy. Please try again later..." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
This is most likely the issue of outlook, not yours. AFAIK outlook has the policy of IP blacklist. Maybe your IP happens to hit it. regards. After a few hundred mails to different addresses who's domains use a protection.outlook.com MX, the receiving servers respond with "...451 4.7.500 Server busy. Please try again later..." ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Selection of a custom smtp-transport based on recipient addresse's MX with check_recipient_mx_access doesn't work
Hi together, our customers have big problems sending bulk E-Mails to their signed members who's domains use a ...protection.outlook.com MX. After a few hundred mails to different addresses who's domains use a protection.outlook.com MX, the receiving servers respond with "...451 4.7.500 Server busy. Please try again later..." So our idea was to configure some additional custom smtp-transports which could then be chosen by filtering by the MX to be used for the receiving addresse's domains. So I configured the three smtp-transports slowersmtp, slowsmtp and veryslowersmtp in main.cf and master.cf. Then I thought I could use... smtpd_recipient_restrictions = check_recipient_mx_access pcre:/etc/postfix/mx_transport_filter And in mx_transport_filter I could filter by outlook.com and all other to choose the assigned smtp-transport. But when I test it with... sendmail -t < ./testmail.txt ... a few times fast one after another and use tail -f on the maillog file, I must watch the e-mails all delivered directly one after another without the delay of 60sec, configured for the veryslowsmtp. I must be having some missconfiguration or did not really understand how it works or should work. In my desperation I also tried to search the web (all major search engines) or even ask Perplexity, ChatGTP, Gemini or CoPilot, but they all gave me all kinds of answers. I tried a lot of them but none worked. Could please someone help me solve this problem and tell me what I am doing wrong or what should be changed? Here are the relevant parts of my configuration # postconf | grep smtp_host_lookup smtp_host_lookup = dns # postconf | grep disable_dns_lookups disable_dns_lookups = no main.cf ... smtpd_recipient_restrictions = check_recipient_mx_access pcre:/etc/postfix/mx_transport_filter slowersmtp_initial_destination_concurrency = 2 slowersmtp_destination_concurrency_limit = 1 slowersmtp_destination_recipient_limit = 2 slowersmtp_destination_rate_delay = 2s slowersmtp_destination_concurrency_failed_cohort_limit = 10 slowsmtp_initial_destination_concurrency = 2 slowsmtp_destination_concurrency_limit = 1 slowsmtp_destination_recipient_limit = 2 slowsmtp_destination_rate_delay = 10s slowsmtp_destination_concurrency_failed_cohort_limit = 20 veryslowsmtp_initial_destination_concurrency = 2 veryslowsmtp_destination_concurrency_limit = 1 veryslowsmtp_destination_recipient_limit = 2 veryslowsmtp_destination_rate_delay = 60s veryslowsmtp_destination_concurrency_failed_cohort_limit = 10 ... master.cf ... slowersmtp unix- - n - - smtp slowsmtp unix - - n - - smtp veryslowsmtp unix - - n - - smtp /etc/postfix/mx_transport_filter: /\.outlook\.com$/veryslowsmtp /.*/slowersmt Many thanks in advance, regards Henri ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dynamic transport?
On Wed, 13 Mar 2024 at 17:00, Viktor Dukhovni via Postfix-users wrote: > > http://www.postfix.org/SMTPD_POLICY_README.html > Thank you Victor. "The policy server replies with any action that is allowed in a Postfix SMTPD access(5) table." is exactly what I needed. > Or deferring, with 4XX, if submission is from an MTA that can queue for > a later retry. In my case, some of the senders are applications pointing directly at the relay. > Unclear how this avoids active queue congestion. > > > (condition2) smtp:[othernode] This provides me with a mechanism for distributing the traffic across multiple relay instances (and applying warm-up). > > (condition1) customtransport: This is not directly related to the capacity issue. But it does simplify the process of distributing configuration across a cluster. Colin -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM d s+:+ a+ C+++(---)$ UL+++ P+(--) L+++ E--- W+++ N++ w-- PS++(+++()) t+ 5+ X R- tv-- b++ DI++ D e+++ h --END GEEK CODE BLOCK-- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Dynamic transport?
On Wed, Mar 13, 2024 at 04:29:19PM +, Colin McKinnon via Postfix-users wrote: > In my previous question [1] Viktor Dukhovni suggested > > > you could use a policy service to impose rate limits per SASL login, or > > sender address > > as a means of preventing active queue congestion. http://www.postfix.org/SMTPD_POLICY_README.html > This took me down a bit of a rabbit hole looking at SMTP Access Policy > delegation and tcp_tables. You don't need "tcp_tables" here, the protocol for policy services is described in: http://www.postfix.org/SMTPD_POLICY_README.html#protocol There are multiple examples of existing policy services. > However I have not managed to find much > (ANY???!!!) information on what the server responses should look like. See the protocol definition linked above. > Although I don't yet know exactly what they look like, I have only seen > mention of accepting or rejecting emails at submission using SMTP Access > Policy delegation. Or deferring, with 4XX, if submission is from an MTA that can queue for a later retry. > I really want to be able to generate, on a per message basis, the > behaviours that I currently have statically defined in a transport map. > These are: > > (condition1) customtransport: Unclear how this avoids active queue congestion. > (condition2) smtp:[othernode] Or this. If a much larger queue size limit and much larger delivery agent limit don't solve the problem, you need backpressure to reduce the input rate, which tweaking output parameters will not achieve, unless somehow you get much better latency for some destinations (which is fine to do of course). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Dynamic transport?
Hi, In my previous question [1] Viktor Dukhovni suggested > you could use a policy service to impose rate limits per SASL login, or sender address as a means of preventing active queue congestion. This took me down a bit of a rabbit hole looking at SMTP Access Policy delegation and tcp_tables. However I have not managed to find much (ANY???!!!) information on what the server responses should look like. Although I don't yet know exactly what they look like, I have only seen mention of accepting or rejecting emails at submission using SMTP Access Policy delegation. I really want to be able to generate, on a per message basis, the behaviours that I currently have statically defined in a transport map. These are: (condition1) customtransport: (condition2) smtp:[othernode] Is this possible with either mechanism? What would the specific responses be? There is also a secondary issue: I'm trying to do load balancing here, but the load balancing would be non-deterministic. I don't want the messages to bounce around between nodes. While I could handle that based on the helo_from= in SMTP Access Policy delegation, I don't believe this information is available in tcp_tables. Assuming that the custom transport is possible via tcp_table but NOT SMTP Access Policy delegation, how can I ensure that a message only gets bumped to a peer once? TIA Colin [1] https://www.mail-archive.com/postfix-users@postfix.org/msg101676.html -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM d s+:+ a+ C+++(---)$ UL+++ P+(--) L+++ E--- W+++ N++ w-- PS++(+++()) t+ 5+ X R- tv-- b++ DI++ D e+++ h --END GEEK CODE BLOCK-- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
On Wed, Nov 08, 2023 at 12:41:55PM +0100, Norbert Schmidt via Postfix-users wrote: > Am I right, at the current moment this cannot be done within Postfix but > would have to be done in the DNS system, right? Your local resolver (e.g. unbound) could "assume ownership" of *.mail.protection.outlook.com, and respond with a wildcard "A" record that redirects the mail flow to another Postfix instance, that is dedicated to delivery to Microsoft, across all their .mail.protection.outlook.com domains, (and some various). Naturally, that Postfix instance would have to be talking to a differently configured resolver, so one of: - Running on a different machine - Running in a different VM container on the same machine - Running in a different chroot jail, with a custom /etc/resolv.conf. As Wietse mentioned, we don't currently have any actions other than "IGNORE" implemented in "smtp_dns_reply_filter". So overriding the A/ records of *.mail.protection.outlook.com, etc. in Postfix, which would be a more natural approach, is not an option at present. -- VIktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
Norbert Schmidt via Postfix-users: > Am 07.11.2023 um 17:26 schrieb Wietse Venema via Postfix-users: > > Viktor Dukhovni via Postfix-users: > >> On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users > >> wrote: > >> > >>> Another option would be to use the DNS resolver (Bind, unbound, etc) > >>> support to manipulate zone lookups. > >> But the OP wants a dedicated transport (for concurrency control and > >> scheduling), not a change of destination IP, though in a multi-stage MTA > >> setup that IP could point at a dedicated Postfix instance. > > I know that, but it was not obvious to me that the OP needs to > > support high volume. > > Actually, I do not need a high volume support. We only want to make sure > to get our mails delivered to customers who are on M$ infrastructure. > > Just changing the IP returned by DNS to a different mail exchange > provider will not help, as authentication is needed to route mail > through their infrastructure. To setup a dedicated Postfix instance > would be an option. It could take care of the authentication when > contacting the service. > > Am I right, at the current moment this cannot be done within Postfix but > would have to be done in the DNS system, right? It could be cobbled together with - An SMTP client in master.cf with the name 'outlook-com' and with a low process limit. - A transport_map based on Postfix built-in tcp_table(5) or socketmap(5), that takes a query with a recipient address or domain, that looks up MX records, and that returns "outlook-com:" when a domain has an MX name that ends in .mail.protection.outlook.com etc. But these lookups happen in time-critical code that blocks while waiting for a response, so it would drag down mail delivery performance. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
Am 07.11.2023 um 17:26 schrieb Wietse Venema via Postfix-users: Viktor Dukhovni via Postfix-users: On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users wrote: Another option would be to use the DNS resolver (Bind, unbound, etc) support to manipulate zone lookups. But the OP wants a dedicated transport (for concurrency control and scheduling), not a change of destination IP, though in a multi-stage MTA setup that IP could point at a dedicated Postfix instance. I know that, but it was not obvious to me that the OP needs to support high volume. Actually, I do not need a high volume support. We only want to make sure to get our mails delivered to customers who are on M$ infrastructure. Just changing the IP returned by DNS to a different mail exchange provider will not help, as authentication is needed to route mail through their infrastructure. To setup a dedicated Postfix instance would be an option. It could take care of the authentication when contacting the service. Am I right, at the current moment this cannot be done within Postfix but would have to be done in the DNS system, right? Thanks Norbert ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
Viktor Dukhovni via Postfix-users: > On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users > wrote: > > > Another option would be to use the DNS resolver (Bind, unbound, etc) > > support to manipulate zone lookups. > > But the OP wants a dedicated transport (for concurrency control and > scheduling), not a change of destination IP, though in a multi-stage MTA > setup that IP could point at a dedicated Postfix instance. I know that, but it was not obvious to me that the OP needs to support high volume. It's easy enough to respect an individual provider's concurrency limits by mapping their customer subdomains to a dedicated transport with a limited number of delivery agent processes. That approach may not scale to a large number of providers, but that does not appear to be the problem at hand. This mapping would be done after transport_map lookups, and before the queue manager assigns a recipient to a delivery transport. A crude implementation would try to map all recipients; a smarter implementation would know what deliveries require MX lookups. Postfix deliveries that may be redirectred to a provider-specific transport based on MX namne: smtp (i.e. $default_transport) MX name to to transport map: # MX name pattern Postfix transport .mail.protection.outlook.comoutlook-com .google.com google-com master.cf: outlook-com .. .. .. .. .. 10 smtp google-com .. .. .. .. .. 10 smtp Recipient domains inside [] would not be subject to MX transport aggregation. This code path would have to be non-blocking so that the queue manager is not slowed down by DNS latency. Some short-lived caching would help. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
>> Another option would be to use the DNS resolver (Bind, unbound, etc) >> support to manipulate zone lookups. > > But the OP wants a dedicated transport (for concurrency control and > scheduling), not a change of destination IP, though in a multi-stage MTA > setup that IP could point at a dedicated Postfix instance. The OP mentioned mailjet(.com?) which is a service provider. It sounds like all emails to domains hosted via *.outlook.com should be routed via mailjet. That way concurrency control/scheduling is handed off to them. Another solution would be to implement a small daemon that is queried via tcp_table. It could check a destination mx name via dns and if it matches *.protection.outlook.com returns a mailjet server as nexthop. https://www.postfix.org/tcp_table.5.html Best regards Gerald ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
On Tue, Nov 07, 2023 at 08:14:04AM -0500, Wietse Venema via Postfix-users wrote: > Another option would be to use the DNS resolver (Bind, unbound, etc) > support to manipulate zone lookups. But the OP wants a dedicated transport (for concurrency control and scheduling), not a change of destination IP, though in a multi-stage MTA setup that IP could point at a dedicated Postfix instance. We don't have a mechanism to schedule by MX host (IP). And there are at least conceptual difficulties when the lists of IPs for various domains overlap, but don't coincide. Is the destination the same or not? Which IP address will be actually used for the delivery? ... This is a non-trivial problem. The best thing to do when sending at volume is to negotiate sufficiently high concurrency caps with the high volume receiving systems. The Postfix queue manager simply does not have enough information to consolidate and schedule deliveries by MX IP. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
Norbert Schmidt via Postfix-users: > Hello, > > as many people we do have problems delivering mail through the Microsoft > MX'es which are used by a lot of company domains. All these domains use MX > records with *.protection.outlook.com or *.prod.outlook.com. > > I am looking for a way to send mail to domains that have such a mx record > through a different transport (for instance through the mailjet service) but > send all other mail the "normal" way. > > As I do not know in advance that a domain is using a M$-MX host, I cannot > put all these domains into the transport table by hand. > > I tried to use a regular expression "/^.*\s+prod\.outlook\.com\.$/" in a > file and then let smtp_generic_maps use it with "smtp_generic_maps = > pcre:/etc/postfix/outlook_mx_patterns" > > My plan was to us it as a filter in transport. > > The problem is, smtp_generic_maps does not accept reglar expressions. Of course it does support regexp: and pcre: tables, but you need to replace a destination MX or A recored, not the recipient address. This could be a use case for https://www.postfix.org/postconf.5.html#smtp_dns_reply_filter but that feature currently has no REPLACE operation. Another option would be to use the DNS resolver (Bind, unbound, etc) support to manipulate zone lookups. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Redirecting mail with an mx record containing *.protection.outlook.com or *.prod.outlook.com to a different transport
Hello, as many people we do have problems delivering mail through the Microsoft MX'es which are used by a lot of company domains. All these domains use MX records with *.protection.outlook.com or *.prod.outlook.com. I am looking for a way to send mail to domains that have such a mx record through a different transport (for instance through the mailjet service) but send all other mail the "normal" way. As I do not know in advance that a domain is using a M$-MX host, I cannot put all these domains into the transport table by hand. I tried to use a regular expression "/^.*\s+prod\.outlook\.com\.$/" in a file and then let smtp_generic_maps use it with "smtp_generic_maps = pcre:/etc/postfix/outlook_mx_patterns" My plan was to us it as a filter in transport. The problem is, smtp_generic_maps does not accept reglar expressions. Any ideas? Best regards Norbert Schmidt ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
Hello,
You will find bellow parts of my script that create a virtual alias map from on
premise AD. You’ll have to work on transforming the output yourself
(/usr/local/bin/get_exchg_aliases.awk in my script).
And you’ll have to tune AD_FILTRE to suit your needs.
EXCHG_OUTPUT="${TRAVAIL}/exchange.ldap"
EXCHG_ALIASES="${TRAVAIL}/exchange.virtual_alias"
AD_BINDNAME=""
AD_BINDPW=""
AD_BASE="OU=,DC=,DC=,DC=***"
AD_FILTRE="(|(samaccountType=268435457)(samaccountType=805306368))"
AD_SEARCH="proxyaddresses"
AD_HOST="ldaps://..***"
../..
/usr/local/bin/ldapsearch -v -xLLL -D ${AD_BINDNAME} -w ${AD_BINDPW} -b
${AD_BASE} -H ${AD_HOST} ${AD_FILTRE} ${AD_SEARCH} > ${EXCHG_OUTPUT}
OUT=$?
if [ $OUT != 0 ]; then
echo >&2 "Error: Get Aliases from AD failed (${OUT}) - (${SCRIPT_NAME})"
exit $OTHER_ERR
fi
mv ${EXCHG_ALIASES} ${EXCHG_ALIASES}.old
/usr/local/bin/get_exchg_aliases.awk ${EXCHG_OUTPUT} | sort > ${EXCHG_ALIASES}
But really if you can use a direct bind and query your Azure AD like Wietse and
Victor recommend, it’s probably best.
patpro
October 26, 2023 11:58 PM, "Joey J via Postfix-users"
mailto:postfix-users@postfix.org?to=%22Joey%20J%20via%20Postfix-users%22%20)>
wrote:
Hello All,
I'm trying to see if someone has a good app to connect to an exchange or O365
server either via LDAP or AD to grab all of the legitimate email accounts,
forwarding accounts and Groups in order to build a transport_recipients file
this way reject all invalid email prior to forwarding it to any destination.
Im thinking there would be something open source out there, just not able to
find it.
-- Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
On Thu, Oct 26, 2023 at 07:46:40PM -0400, Joey J via Postfix-users wrote: > My only concern is if there is as an example a recipient that has literally > 2K email addresses with LDAP/AD, which associates with how much inbound > mail wont that slow down delivery a good amount, and potentially create a > lot of overhead? I don't see that the number addresses under which a user is known matters at all. You ask for exactly one of those addreses as a lookup key, and the result returns one address (mail), that is the primary address of the user. Perhaps you meant a group with 2k members? That can slow things down slightly (you could even need to tune the virtual alias expansion limit), and it is precisely large groups (that were typically internally "moderated" to stop unapproved junk hitting large internal lists), for which "terminal_result_attribute" was created. Such groups are not expanded (provided they have a terminal result attribute that "trumps" the multi-valued, special_result_attribute "member" field. Postfix has rather battle-hardened LDAP support, it was after all used to support ultimately around 80k users for a decade or so. If you have a complex environment, this takes some planning, but all the pieces are in place. Read LDAP_README multiple times with care, take notes and plan your deployment. -- VIktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
My only concern is if there is as an example a recipient that has literally
2K email addresses with LDAP/AD, which associates with how much inbound
mail wont that slow down delivery a good amount, and potentially create a
lot of overhead?
On Thu, Oct 26, 2023 at 7:42 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
> On Thu, Oct 26, 2023 at 07:11:23PM -0400, Joey J via Postfix-users wrote:
>
> > To confirm, I'm creating the list of valid emails to accept and then
> > forward and if not in that list reject.
>
> No, my advice is to replace the "list" with live LDAP queries to AD,
> on demand during each SMTP transaction. There is no "list".
>
> > My question would be, will postfix send off a process to query every so
> > often in order to build the multiple lists, or as each mail is about to
> be
> > delivered?
>
> Live LDAP queries, during the SMTP transaction. The internal domain
> behind Postfix would then be listed in "relay_domains". Your
> "relay_recipient_maps" must then be a non-empty setting, pointing at
> a mostly empty local table:
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> relay_recipient_maps = ${indexed}nonad-rcpts
>
> nonad-rcpts:
> postmaster@acme.example
> ...
>
> The virtual_alias_maps table is always also considered a valid source of
> recipient addresses across all address classes, but if you simply set
> "relay_recipient_maps" (the list of tables, not the table content)
> empty, then validation of relay recipients would IIRC be entirely disabled.
>
> In real production networks with AD that I used to support, I'd actualy
> use "virtual_alias_domains" not "relay_domains", but this required:
>
> - The internal Active Directory domain be different from the public
> mail domain. For example:
>
> - Public mail domain: acme.example
> - Internal AD domain: exchange.acme.example
>
> - The users' proxy addresses include at least both:
>
> - smtp:user@acme.example
> - smtp:u...@exchange.acme.example
>
> - The users' "mail" attribute be set to their public address
> for use a "canonical_maps" table in outgoing mail.
>
> - The user's LDAP objects also have another (like "mail")
> *single-valued* attribute, say "maildrop" or whatever name you choose,
> that holds their internal mail address:
>
> - maildrop: u...@exchange.acme.example
>
> You'd then use that attribute as the "result_attribute" for
> LDAP, instead of "mail".
>
> The LDAP driver also has non-trivial support for managing
> "mail groups", see the description in LDAP_README of
>
> - special_result_attribute
> - leaf_result_attribute
> - terminal_result_attribute
>
> There's perhaps a bunch to learn here, the more advanced settings were
> used to support a largish corporate user base of ~80k users with
> multiple internal AD domains, and even some cloud-hosted users on the
> backend.
>
> --
> Viktor.
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
--
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
On Thu, Oct 26, 2023 at 07:11:23PM -0400, Joey J via Postfix-users wrote:
> To confirm, I'm creating the list of valid emails to accept and then
> forward and if not in that list reject.
No, my advice is to replace the "list" with live LDAP queries to AD,
on demand during each SMTP transaction. There is no "list".
> My question would be, will postfix send off a process to query every so
> often in order to build the multiple lists, or as each mail is about to be
> delivered?
Live LDAP queries, during the SMTP transaction. The internal domain
behind Postfix would then be listed in "relay_domains". Your
"relay_recipient_maps" must then be a non-empty setting, pointing at
a mostly empty local table:
main.cf:
indexed = ${default_database_type}:${config_directory}/
relay_recipient_maps = ${indexed}nonad-rcpts
nonad-rcpts:
postmaster@acme.example
...
The virtual_alias_maps table is always also considered a valid source of
recipient addresses across all address classes, but if you simply set
"relay_recipient_maps" (the list of tables, not the table content)
empty, then validation of relay recipients would IIRC be entirely disabled.
In real production networks with AD that I used to support, I'd actualy
use "virtual_alias_domains" not "relay_domains", but this required:
- The internal Active Directory domain be different from the public
mail domain. For example:
- Public mail domain: acme.example
- Internal AD domain: exchange.acme.example
- The users' proxy addresses include at least both:
- smtp:user@acme.example
- smtp:u...@exchange.acme.example
- The users' "mail" attribute be set to their public address
for use a "canonical_maps" table in outgoing mail.
- The user's LDAP objects also have another (like "mail")
*single-valued* attribute, say "maildrop" or whatever name you choose,
that holds their internal mail address:
- maildrop: u...@exchange.acme.example
You'd then use that attribute as the "result_attribute" for
LDAP, instead of "mail".
The LDAP driver also has non-trivial support for managing
"mail groups", see the description in LDAP_README of
- special_result_attribute
- leaf_result_attribute
- terminal_result_attribute
There's perhaps a bunch to learn here, the more advanced settings were
used to support a largish corporate user base of ~80k users with
multiple internal AD domains, and even some cloud-hosted users on the
backend.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
Thanks Viktor.
To confirm, I'm creating the list of valid emails to accept and then
forward and if not in that list reject.
My question would be, will postfix send off a process to query every so
often in order to build the multiple lists, or as each mail is about to be
delivered?
On Thu, Oct 26, 2023 at 7:02 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
> On Thu, Oct 26, 2023 at 06:32:53PM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > > I'm trying to see if someone has a good app to connect to an exchange
> or
> > > O365 server either via LDAP or AD to grab all of the legitimate email
> > > accounts, forwarding accounts and Groups in order to build a
> > > transport_recipients file this way reject all invalid email prior to
> > > forwarding it to any destination.
> > >
> > > Im thinking there would be something open source out there, just not
> able
> > > to find it.
> >
> > I'm not familiar with AD, but on the Postfix side can use
> > reject_unverified_recipient to query a destination server if it
> > would accept mail for a recipient. Postfix maintains a cache
> > for positive and negative reject_unverified_recipient results.
>
> Why not just query AD via LDAP? Use the below as a basis for a
> "virtual_alias_maps" tables (not transport!):
>
> main.cf:
> ldap = proxy:ldap:${config_directory}/
> virtual_alias_maps = ${ldap}valias.cf
>
> query = proxyAddresses=smtp:%s
> valias.cf:
> query = proxyAddresses=smtp:%s
> result_attribute = mail
> version = 3
> scope = sub
> server_host = ...
> search_base = ...
> bind_dn = ...
> bind_pw = ...
> bind = yes
>
> This scales much better than per-user transport looks via LDAP, and
> avoids the need to extract tables, risk stale data, ...
>
> See ldap_table(5) and LDAP_README for more details.
>
> --
> Viktor.
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org
>
--
Thanks!
Joey
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
On Thu, Oct 26, 2023 at 06:32:53PM -0400, Wietse Venema via Postfix-users wrote:
> > I'm trying to see if someone has a good app to connect to an exchange or
> > O365 server either via LDAP or AD to grab all of the legitimate email
> > accounts, forwarding accounts and Groups in order to build a
> > transport_recipients file this way reject all invalid email prior to
> > forwarding it to any destination.
> >
> > Im thinking there would be something open source out there, just not able
> > to find it.
>
> I'm not familiar with AD, but on the Postfix side can use
> reject_unverified_recipient to query a destination server if it
> would accept mail for a recipient. Postfix maintains a cache
> for positive and negative reject_unverified_recipient results.
Why not just query AD via LDAP? Use the below as a basis for a
"virtual_alias_maps" tables (not transport!):
main.cf:
ldap = proxy:ldap:${config_directory}/
virtual_alias_maps = ${ldap}valias.cf
query = proxyAddresses=smtp:%s
valias.cf:
query = proxyAddresses=smtp:%s
result_attribute = mail
version = 3
scope = sub
server_host = ...
search_base = ...
bind_dn = ...
bind_pw = ...
bind = yes
This scales much better than per-user transport looks via LDAP, and
avoids the need to extract tables, risk stale data, ...
See ldap_table(5) and LDAP_README for more details.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
Thanks for the response Wietse, I have tried this but many servers won't correctly allow the verification (its turned off) we have even added rules to allow our IP's get the verification, but we end up delivering the message only to then have it rejected which defeats the purpose. Based on the experience I have had so far, I believe the best most reliable method is to get the information from the source. On Thu, Oct 26, 2023 at 6:33 PM Wietse Venema via Postfix-users < postfix-users@postfix.org> wrote: > Joey J via Postfix-users: > > Hello All, > > > > I'm trying to see if someone has a good app to connect to an exchange or > > O365 server either via LDAP or AD to grab all of the legitimate email > > accounts, forwarding accounts and Groups in order to build a > > transport_recipients file this way reject all invalid email prior to > > forwarding it to any destination. > > > > Im thinking there would be something open source out there, just not able > > to find it. > > I'm not familiar with AD, but on the Postfix side can use > reject_unverified_recipient to query a destination server if it > would accept mail for a recipient. Postfix maintains a cache > for positive and negative reject_unverified_recipient results. > > https://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient > > Wietse > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > -- Thanks! Joey ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Recommended APP to build approved transport recipients from Exhange / AD / LDAP
Joey J via Postfix-users: > Hello All, > > I'm trying to see if someone has a good app to connect to an exchange or > O365 server either via LDAP or AD to grab all of the legitimate email > accounts, forwarding accounts and Groups in order to build a > transport_recipients file this way reject all invalid email prior to > forwarding it to any destination. > > Im thinking there would be something open source out there, just not able > to find it. I'm not familiar with AD, but on the Postfix side can use reject_unverified_recipient to query a destination server if it would accept mail for a recipient. Postfix maintains a cache for positive and negative reject_unverified_recipient results. https://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Recommended APP to build approved transport recipients from Exhange / AD / LDAP
Hello All, I'm trying to see if someone has a good app to connect to an exchange or O365 server either via LDAP or AD to grab all of the legitimate email accounts, forwarding accounts and Groups in order to build a transport_recipients file this way reject all invalid email prior to forwarding it to any destination. Im thinking there would be something open source out there, just not able to find it. -- Thanks! Joey ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: user based transport
On 12.10.23 00:56, wesley--- via Postfix-users wrote: How can I setup username based transport? for incoming messages, such as use...@foo.com will be delivered to host a. use...@foo.com will be delivered to host b. transport_maps support username@domain notation: http://www.postfix.org/transport.5.html -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The only substitute for good manners is fast reflexes. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] user based transport
Hello, How can I setup username based transport? for incoming messages, such as use...@foo.com will be delivered to host a. use...@foo.com will be delivered to host b. Thanks. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Transport according to MX record
On Thu, Oct 12, 2023 at 02:02:55AM +0200, Daniel Ryšlink via Postfix-users wrote: > It's generally very useful to set up a specific transport for "sensitive" > domains like gmail.com with specific policy (throttling outgoing message > rate, etc). > > However, since more and more hosted domains use mail services for their > domains, it would be useful to be able to select apropriate transport not > according to domain or recipient e-mail, but according to the IPs address of > the server specified by the MX record of the domain. > > Could it be achieved via Postfix configuration somehow? The transport table > format does not seem to support this. Sadly, no. Transport selection and scheduling happens in the queue manager, which does not know which MX hosts an SMTP delivery might later resolver to. And even if it were MX-aware, what to when: - Some MX host IP addresses are associated with one transport choice and some with another? - The actual MX hosts that are up and going to be used are not the highest priority ones? - The IP addresses that have not saturated their concurrency are not the ones the SMTP delivery agent ultimately chooses when delivery happens. - ... Adding Postfix support for IP-based concurrency limits across separate nexthop domains would require a radical redesign of the queue manager and/or SMTP delivery agents. So not likely any time soon. Once a particular IP address is selected, the delivery would have to go back into some sort of queue, freeing up the delivery agent that performed the MX and address lookups, and that secondary queue would have to implement concurrency limits by IP and pass the envelope back for actual delivery. Something along the lines a 2-stage SMTP delivery agent, with a handoff to a second-stage queue along the way. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Transport according to MX record
Hello, It's generally very useful to set up a specific transport for "sensitive" domains like gmail.com with specific policy (throttling outgoing message rate, etc). However, since more and more hosted domains use mail services for their domains, it would be useful to be able to select apropriate transport not according to domain or recipient e-mail, but according to the IPs address of the server specified by the MX record of the domain. Could it be achieved via Postfix configuration somehow? The transport table format does not seem to support this. Thank you in advance for any useful info, and apologies for any potential flaws of this inquiry. -- Best Regards, Daniel Ryšlink ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Andrew Athan via Postfix-users: > Thanks Viktor: > > > welcome to the internet > > Yeah :) I've been here for 30 years. > > > unlikely to be productive > > I simply want to help others avoid my points of confusion, in the belief I > am not a uniquirely incapable or unintelligent reader. > > I will say this: Irrespective of how well you understand postfix (as an > expert) the docs have clearly resulted in a lot of confusion not only in > me, but in others, as evidenced by erroneous alternative content that comes > up when searching this topic and/or similar questions asked by others in > other forums. Unfortunately, some documentation had not been updated after new features were added. ADDRESS_REWRITING_README was lagging behind postconf(5) which did not help. I added a new table that summarizes all the features that can affect the determination of message delivery transport and next-hop destination, including their precedence order. https://www.postfix.org/ADDRESS_REWRITING_README.html#resolve I also updated descriptions of individual configuration parameters. There, I think I should add pointers to the new table. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Matus UHLAR - fantomas via Postfix-users writes: > (...) > for envelope from, simple access map should be enough: > http://www.postfix.org/access.5.html > > and use DISCARD Ok. Thanks for the heads-up, Matus! Sincerely, Byung-Hee -- ^고맙습니다 _地平天成_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Thanks Viktor:
> welcome to the internet
Yeah :) I've been here for 30 years.
> unlikely to be productive
I simply want to help others avoid my points of confusion, in the belief I
am not a uniquirely incapable or unintelligent reader.
I will say this: Irrespective of how well you understand postfix (as an
expert) the docs have clearly resulted in a lot of confusion not only in
me, but in others, as evidenced by erroneous alternative content that comes
up when searching this topic and/or similar questions asked by others in
other forums.
Unfortunately, precisely because the "welcome to the internet," it's often
a good idea to disambiguate demonstrated points of confusion and/or
counteract easily found internet misinformation about the project, directly
in the project docs.
> @
In your original response you were probably narrowly thinking about a
specific transport(5) map when you responded @ was not included in search,
but here unless I misunderstand you, you verify that there are some tables
where @domain.com is searched. In other words, you seem to agree the
components that have statements such as "The tables are searched by the
envelope sender address and @domain" do the table search differently than
described in transport(5).
Unfortunately, the doc for those components point readers to the
transport(5) doc but only mention the @domain item in passing, leaving
readers wondering about the semantics of that statement, given the examples
in transport(5) go counter to the statement. "@domain" could have been
written that way to highlight that "domain" refers to the part after the @
sign.
I suggest transport(5) include a small note in the table of search
examples/precedence to show examples relevant to the search order and for
those components that include the @ sign, or that their docs point to a
similar table specific to how search is performed for those components.
> [ DUNNO is access(5) not transport(5) ] [] indicate paraphrasing
The docs for sender_dependent_default_transport_maps seem to contradict
you.
They state "lookup result of DUNNO terminates the search without overriding
the global default_transport parameter setting." so either you are mistaken
or I am again misunderstanding either you or the docs.
> [no scans]
That makes sense for table formats that have indeterminate keys such as
pcre, but the objection IMHO makes less sense relative to *results* in
those tables. If an access(5) verb appears in a transport(5) result that
seems detectable. That being said, it turned out "discard", though not a
verb, *is* a valid transport that seems to be defined in default
distributions of postfix, and operates like my proposed "blackhole"
transport ... so that muddies the waters. Perhaps postfix should disallow
transport names that match verbs for that reason. I think transport names
are completely arbitrary, so doing that could avoid confusion.
Finally, to prevent long or expensive startup any proposed "config sanity
scans" could be limited by a timer or by a "total items scanned" counter.
and be either selected or squelched by command line arg. Then, if the scan
terminates early, it could generate a separate warning about "config sanity
scan terminated early due to table size."
Thanks again for your prior responses. I think I now understand things well
enough to make progress.
No need to respond unless you'd like to chat about this further.
On Sat, Apr 22, 2023 at 8:58 PM Viktor Dukhovni via Postfix-users <
postfix-users@postfix.org> wrote:
> On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote:
>
> > If I understand it well enough I'll write and submit a doc PR.
>
> This is unlikely to be productive.
>
> > If I put all this together what I think I'm hearing is that transport_map
> > overrides everything
>
> The transport(5) table has the highest priority for the components of
> the (transport, nexthop) pair that it specifies. All the other sources
> are fallback sources when either or both of the transport or nexthop are
> not specified in transport(5).
>
> > So does sender_dependent_relayhost_maps contain mappings from keys to
> > transport:nexthop values or to nexthop values?
>
> A "relayhost" is a host (i.e. a nexthop) so clearly not a transport
> ("smtp", "lmtp", "local", ...).
>
> > I think what's generally missing in the transport(5) man page and any
> docs
> > I've read so far, is a description of the concept that what postfix is
> > trying to do is to get to a fully resolved transport:nexthop PAIR.
>
> https://www.postfix.org/transport.5.html
>
> RESULT FORMAT
> The lookup result is of the form transport:nexthop. The
> transport
&
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
On 23.04.23 13:43, Byung-Hee HWANG via Postfix-users wrote: Andrew Athan via Postfix-users writes: (...) My goal is to silently discard all inbound mail from a certain domain. Or actually, I may wish to redirect all of that mail either to a flat file (similar to the proposed blackhole transport) or (...) Go with easy way. See header_checks. `man 5 header_checks` ;;; This [1] is real server conf files from my mail server. [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 for envelope from, simple access map should be enough: http://www.postfix.org/access.5.html and use DISCARD -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Andrew Athan via Postfix-users writes: > (...) > My goal is to silently discard all inbound mail from a certain > domain. Or actually, I may wish to redirect all of that mail either to > a flat file (similar to the proposed blackhole transport) or (...) Go with easy way. See header_checks. `man 5 header_checks` ;;; This [1] is real server conf files from my mail server. [1] https://gitlab.com/soyeomul/Gnus/-/raw/master/DKIM/smtp-conf.yw-0919 Sincerely, -- ^고맙습니다 _地平天成_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
On Sat, Apr 22, 2023 at 07:58:25PM -0700, Andrew Athan wrote:
> If I understand it well enough I'll write and submit a doc PR.
This is unlikely to be productive.
> If I put all this together what I think I'm hearing is that transport_map
> overrides everything
The transport(5) table has the highest priority for the components of
the (transport, nexthop) pair that it specifies. All the other sources
are fallback sources when either or both of the transport or nexthop are
not specified in transport(5).
> So does sender_dependent_relayhost_maps contain mappings from keys to
> transport:nexthop values or to nexthop values?
A "relayhost" is a host (i.e. a nexthop) so clearly not a transport
("smtp", "lmtp", "local", ...).
> I think what's generally missing in the transport(5) man page and any docs
> I've read so far, is a description of the concept that what postfix is
> trying to do is to get to a fully resolved transport:nexthop PAIR.
https://www.postfix.org/transport.5.html
RESULT FORMAT
The lookup result is of the form transport:nexthop. The transport
field specifies a mail delivery transport such as smtp or local. The
nexthop field specifies where and how to deliver mail.
The transport field specifies the name of a mail delivery transport
(the first name of a mail delivery service entry in the Postfix mas-
ter.cf file).
The nexthop field usually specifies one recipient domain or hostname.
In the case of the Postfix SMTP/LMTP client, the nexthop field may con-
tain a list of nexthop destinations separated by comma or whitespace
(Postfix 3.5 and later).
...
> Some of the settings can specify only the transport or both the
> transport:nexthop or only the nexthop. As soon as it's fully resolved
> or hit DUNNO, the search stop.
No. "DUNNO" is an access(5) verb, but is NOT applicable in the case of
transport(5) lookups (it does apply in the sender-dependent table to
support creating NOP exceptions to broad rules). Access control !=
routing.
> Do I have that right?
Not quite. See above.
> I'm still left unsure as to whether there are differences in how the sender
> dependent tables are searched vs the non-sender dependent tables; however,
Barring minor oversights, each Postfix table-based feature documents the
lookup keys searched and the result format.
https://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
A sender-dependent override for the global relayhost parameter
setting. The tables are searched by the envelope sender address and
@domain.
This is slightly different from transport(5) where domains are matched
without a leading "@", as documented.
> I think the only reason for my confusion is that there is now
> misinformation out there that comes up whenever people google these topics.
Search engines index "relevant" information, that appears to be popular,
but accuracy isn't necessarily part of the equation. Welcome to the
Internet.
> My guess is that if you want to match all relayed mail from bad_domain.com
> even if you put that rule into one of the sender dependent maps, the key is
> bad_domain.com or .bad_domain.com and never @bad_domain.com.
The lookup key formats for the various mumble_maps parameters are as
documented. Consult the https://www.postfix.org documentation.
> > > the sender_transport_maps contains:
> > > @filtered_domain.com DISCARD
>
> Ok. So this did not result in an error not only because my transport_map
> caused no further search to be done, but also because DISCARD or discard
> would just be interpreted as a "nexthop name" when encountered in that map.
You said "sender_dependent_transport_maps",
https://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
A sender-dependent override for the global default_transport
parameter setting. The tables are searched by the envelope sender
address and @domain. A lookup result of DUNNO terminates the search
without overriding the global default_transport parameter setting.
This information is overruled with the transport(5) table.
> While not technically an error, again, a startup sweep of these maps could
> at least issue warnings for common misconfigurations like this one.
Postfix doesn't "sweep" maps. They could be large, or could be regexp
based, ... Map lookups are performed on demand, one key at a time.
> That being said, I suppose there could be a "blackhole" transport that
> sends everything to /dev/null, and then (assuming the sender specific maps
> can override any already resolved transport), the map could contain an .
> bad_domain.com => blackhole:fooba
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
Oh, sorry, one last (lol) thing ... since it doesn't seem like "@" is ever part of searches do you think it might be wise to change the docs so that instead of saying " sender-dependent override for the global relayhost parameter setting. The tables are searched by the envelope sender address and @domain" they say "The tables are searched by the envelope sender address (i.e. full user@domain), as well as the domain part alone." It's not clear what distinction is being made by the original text, otherwise ... and the original text seems to imply the @ is included, whereas the docs at transport(5) contradict that implication, leaving users having to battle with google disinformation. On Sat, Apr 22, 2023 at 6:45 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Sat, Apr 22, 2023 at 05:56:12PM -0700, Andrew Athan via Postfix-users > wrote: > > > "This information is overruled with... the transport(5) table." > > In other words, "transport_maps", a logical dictionary built from > a list of component tables (some of which may also be composite). > > > But "sender_dependent_relayhost_maps" indicates that it can be overruled > by > > "sender_dependent_default_transport_maps" > > Bottom line "relayhost" and its sender-dependent versions provide a > non-default nexthop to override the recipient domain, but may in turn be > preëmpted by any explicit nexthop in the transport(5) map, whether > global, or sender-dependent. > > > > so there is apparently some relationship between relay_transport and > > default_transport or at least between the sender_dependent files > > amongst themselves? > > All that's going on is that "bare" transports get their nexthop from > either the recipient domain, or some sort of relayhost override, while > complete "transport:nexthop" pairs do not. > > > The transport(5) docs contain examples that indicate domains are searched > > without the @ sign, but in other places and in examples I find online it > > appears the @ sign is included in the sender_dependent...* searches??!! > > The transport(5) table supports per-recipient lookups (user@domain) or > just per-domain lookups (I don't recommend reliance on per-recipient > transport tables except perhaps for a small set of "special" users, the > majority of transport decisions should be domain-wide). > > > relay_domains = domain1.com domain2.com domain3.com > > Postfix will inbound mail for these domains from any sender. > > > transport_maps = hash:/etc/postfix/transport > > This trumps all other transport choices, and also nexthop choices when > specified. > > > sender_dependent_relayhost_maps = hash:/etc/postfix/sender_transport_maps > > This overrides the nexthop for remote delivery, whenever the > transport(5) table does not. > > > the /etc/postfix/transport map contains entries for each of the > domain1.com > > > domain1.com smtp:[domain1.mail.handler.com]:2000 > > domain2.com smtp:[domain2.mail.handler.com]:2020 > > These specify a nexthop, so not affected by relayhost, sender-dependent > or otherwise. > > > the sender_transport_maps contains: > > @filtered_domain.com DISCARD > > "DISCARD" is access(5) verb, not a transport. And should be used with > "check_sender_access" in one of "smtpd_mumble_restrictions" lists. > > Recipient and sender Domains are looked up in access(5) tables without a > leading "@". > > -- > Viktor. > ___ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org > ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
I hope the message quoting/formatting in my response works as expected. If not let me know and I will rely less on gmail's formatter. > > "This information is overruled with... the transport(5) table." > > In other words, "transport_maps", a logical dictionary built from > a list of component tables (some of which may also be composite). > Sure. I tried to understand it that way. However, there are at least two problems: (1) Let's look at this definition "relay_transport: The default mail delivery transport and next-hop destination for remote delivery to domains listed with $relay_domains. In order of decreasing precedence, the nexthop destination is taken from $relay_transport, $sender_dependent_relayhost_maps, $relayhost, or from the recipient domain. This information can be overruled with the transport(5) table." If a user reads that and then goes to read transport(5) it is not at all obvious that the sentence "This information can be overruled with the transport(5) table" means "The relay_transport is overruled by the mappings specified in $transport_maps" (2) transport(5) seems to list tables that override tables listed in relay_transport, but those overriding tables are not listed in relay_transport. So what is the precedence relationship in that case? In other words, I was scratching my head thinking "is this bad english referencing the general concepts in transport(5) or should I be trying to find the specific tables listed there that this could be in reference to" or what? If I understand it well enough I'll write and submit a doc PR. > But "sender_dependent_relayhost_maps" indicates that it can be overruled > by > > "sender_dependent_default_transport_maps" > > Bottom line "relayhost" and its sender-dependent versions provide a > non-default nexthop to override the recipient domain, but may in turn be > preëmpted by any explicit nexthop in the transport(5) map, whether > global, or sender-dependent. > If I put all this together what I think I'm hearing is that transport_map overrides everything but if nothing matches there, or it's not specified, then some of those other settings may trigger. E.g., if I have a transport_map defined, but the destination domain doesn't match anything in it, then if this is a message that's being relayed, postfix will look at the sender dependent map etc... > > so there is apparently some relationship between relay_transport and > > default_transport or at least between the sender_dependent files > > amongst themselves? > > All that's going on is that "bare" transports get their nexthop from > either the recipient domain, or some sort of relayhost override, while > complete "transport:nexthop" pairs do not. > So does sender_dependent_relayhost_maps contain mappings from keys to transport:nexthop values or to nexthop values? I think what's generally missing in the transport(5) man page and any docs I've read so far, is a description of the concept that what postfix is trying to do is to get to a fully resolved transport:nexthop PAIR. Some of the settings can specify only the transport or both the transport:nexthop or only the nexthop. As soon as it's fully resolved or hit DUNNO, the search stop. Do I have that right? > The transport(5) docs contain examples that indicate domains are searched > > without the @ sign, but in other places and in examples I find online it > > appears the @ sign is included in the sender_dependent...* searches??!! > > The transport(5) table supports per-recipient lookups (user@domain) or > just per-domain lookups (I don't recommend reliance on per-recipient > transport tables except perhaps for a small set of "special" users, the > majority of transport decisions should be domain-wide). > I'm still left unsure as to whether there are differences in how the sender dependent tables are searched vs the non-sender dependent tables; however, I think the only reason for my confusion is that there is now misinformation out there that comes up whenever people google these topics. My guess is that if you want to match all relayed mail from bad_domain.com even if you put that rule into one of the sender dependent maps, the key is bad_domain.com or .bad_domain.com and never @bad_domain.com. The counterexample could be included in the man page/docs given the possible confusion. E.g. "@somedomain.com will never match anything. Leave the @ out." If that's true, a check for such keys during startup could issue warnings. [my examples and your explanations] > Thank you, I understood. > the sender_transport_maps contains: > > @filtered_domain.com DISCARD > Ok. So this did not result in an error not only becau
[pfx] Re: Regarding transport maps (sender_dependent_relayhost_maps not working)
On Sat, Apr 22, 2023 at 05:56:12PM -0700, Andrew Athan via Postfix-users wrote: > "This information is overruled with... the transport(5) table." In other words, "transport_maps", a logical dictionary built from a list of component tables (some of which may also be composite). > But "sender_dependent_relayhost_maps" indicates that it can be overruled by > "sender_dependent_default_transport_maps" Bottom line "relayhost" and its sender-dependent versions provide a non-default nexthop to override the recipient domain, but may in turn be preëmpted by any explicit nexthop in the transport(5) map, whether global, or sender-dependent. > so there is apparently some relationship between relay_transport and > default_transport or at least between the sender_dependent files > amongst themselves? All that's going on is that "bare" transports get their nexthop from either the recipient domain, or some sort of relayhost override, while complete "transport:nexthop" pairs do not. > The transport(5) docs contain examples that indicate domains are searched > without the @ sign, but in other places and in examples I find online it > appears the @ sign is included in the sender_dependent...* searches??!! The transport(5) table supports per-recipient lookups (user@domain) or just per-domain lookups (I don't recommend reliance on per-recipient transport tables except perhaps for a small set of "special" users, the majority of transport decisions should be domain-wide). > relay_domains = domain1.com domain2.com domain3.com Postfix will inbound mail for these domains from any sender. > transport_maps = hash:/etc/postfix/transport This trumps all other transport choices, and also nexthop choices when specified. > sender_dependent_relayhost_maps = hash:/etc/postfix/sender_transport_maps This overrides the nexthop for remote delivery, whenever the transport(5) table does not. > the /etc/postfix/transport map contains entries for each of the domain1.com > domain1.com smtp:[domain1.mail.handler.com]:2000 > domain2.com smtp:[domain2.mail.handler.com]:2020 These specify a nexthop, so not affected by relayhost, sender-dependent or otherwise. > the sender_transport_maps contains: > @filtered_domain.com DISCARD "DISCARD" is access(5) verb, not a transport. And should be used with "check_sender_access" in one of "smtpd_mumble_restrictions" lists. Recipient and sender Domains are looked up in access(5) tables without a leading "@". -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Regarding transport maps (sender_dependent_relayhost_maps not working)
I have read and re-read the documentation regarding transport(5) here: https://www.postfix.org/transport.5.html First, the docs for things like say "sender_dependent_relayhost_maps" say: "This information is overruled with... the transport(5) table." but what the heck is "the transport(5) table"? Looking at the transport(5) docs there is not a single table!!? Then, in transport(5) the doc for "relay_transport" says "This is the default for remote delivery to domains listed with relay_domains. In order of decreasing precedence, the nexthop destination is taken from relay_transport, sender_dependent_relayhost_maps, relayhost, or from the recipient domain." But "sender_dependent_relayhost_maps" indicates that it can be overruled by "sender_dependent_default_transport_maps" so there is apparently some relationship between relay_transport and default_transport or at least between the sender_dependent files amongst themselves? The transport(5) docs contain examples that indicate domains are searched without the @ sign, but in other places and in examples I find online it appears the @ sign is included in the sender_dependent...* searches??!! Ultimately, I cannot get postfix to honor "discard" filters I've created. My setup involves an inbound mail relay running postfix that relays via smtp to the domains it accepts for. relay_domains = domain1.com domain2.com domain3.com transport_maps = hash:/etc/postfix/transport sender_dependent_relayhost_maps = hash:/etc/postfix/sender_transport_maps the /etc/postfix/transport map contains entries for each of the domain1.com etc.: domain1.com smtp:[domain1.mail.handler.com]:2000 domain2.com smtp:[domain2.mail.handler.com]:2020 etc... the sender_transport_maps contains: @filtered_domain.com DISCARD I of course update the .db files with postmap and postfix start/stop between changes. However, mail from users at @filtered_domain.com still gets through! I've tried with and without the @. I've tried setting sender_dependent_default_transport_maps instead. I've tried everything I can think of. There seems to be no easy way to test this except to send examples via some other working domain and during the time I'm running tests all mail for that other domain might end up blocked. If there's an easier way to test whether mail from a certain domain will successfully get blocked that'd be great. I have DKIM and other filters enabled so it's not straight-forward to spoof MAIL FROM. Or maybe it is and I don't know the trick... help :) Thanks in advance. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)
liquid cooled: > Thanks for the quick response, > > 2) $ postconf -n | grep ldap > transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/ > mailtransport.cf In that case, Postfix will always want to look up user@domain, domain, and parent domains, because that is how transport maps are intended to be used. BTW ldap (and sql) tables have high lookup latencies, best to avoid those, or configure them as a Postfix memcache backend. > The thing is I do not have my local domains defined anywhere... basically > if I point an MX to this mailserver and create an LDAP entry containing a > valid mail address I will be able to receive mail for that domain. > Maybe this is the problem here? To configure Postfix for receiving email, please see https://www.postfx.org/ADDRESS_CLASS_README.html For basic UNIX-style system accounts: https://www.postfix.org/BASIC_CONFIGURATION_README.html Wietse
Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)
I got it now found the "domain" setting in https://www.postfix.org/ldap_table.5.html Thanks you very much Wietse! And thanks for your time! Am Fr., 3. März 2023 um 15:44 Uhr schrieb liquid cooled : > Thanks for the quick response, > > 2) $ postconf -n | grep ldap > transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/ > mailtransport.cf > > 1) by "those domains" you are talking about the sender domains? Because > these domains are unknown to my mailsystem as these are mails from external > mailservers. > If you mean my own local domains do you think i should add to the ldap > query something like this? "query_filter = > (&(|(mail=%s)(mailalternateaddress=%s)(domain=%d))" > The thing is I do not have my local domains defined anywhere... basically > if I point an MX to this mailserver and create an LDAP entry containing a > valid mail address I will be able to receive mail for that domain. > Maybe this is the problem here? > > Am Fr., 3. März 2023 um 14:04 Uhr schrieb Wietse Venema < > wie...@porcupine.org>: > >> liquid cooled: >> > Hello, >> > >> > I found out that my postfix does a lot of useless (LDAP) requests (in my >> > opinion) when transport maps are enabled and in place. >> > I use transport maps to map incoming mails to different destination >> hosts, >> > based on destination mail address. >> > So there should be no lookup at all for sender address or local or >> domain >> > part. >> >> 1) Add a "domain = " setting to look up only complete email >> addresses in those domains. >> >> 2) You forgot to show parameter settings (output from the command >> "postconf -n | grep ldap") that shows WHAT Postfix is using the >> table for. >> >> Wietse >> >
Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)
Thanks for the quick response, 2) $ postconf -n | grep ldap transport_maps = hash:/etc/postfix/lookup/transport, ldap:/etc/postfix/ mailtransport.cf 1) by "those domains" you are talking about the sender domains? Because these domains are unknown to my mailsystem as these are mails from external mailservers. If you mean my own local domains do you think i should add to the ldap query something like this? "query_filter = (&(|(mail=%s)(mailalternateaddress=%s)(domain=%d))" The thing is I do not have my local domains defined anywhere... basically if I point an MX to this mailserver and create an LDAP entry containing a valid mail address I will be able to receive mail for that domain. Maybe this is the problem here? Am Fr., 3. März 2023 um 14:04 Uhr schrieb Wietse Venema < wie...@porcupine.org>: > liquid cooled: > > Hello, > > > > I found out that my postfix does a lot of useless (LDAP) requests (in my > > opinion) when transport maps are enabled and in place. > > I use transport maps to map incoming mails to different destination > hosts, > > based on destination mail address. > > So there should be no lookup at all for sender address or local or domain > > part. > > 1) Add a "domain = " setting to look up only complete email > addresses in those domains. > > 2) You forgot to show parameter settings (output from the command > "postconf -n | grep ldap") that shows WHAT Postfix is using the > table for. > > Wietse >
Re: Transport maps - lookups happen for recipient but also for sender (which is not necessary)
liquid cooled: > Hello, > > I found out that my postfix does a lot of useless (LDAP) requests (in my > opinion) when transport maps are enabled and in place. > I use transport maps to map incoming mails to different destination hosts, > based on destination mail address. > So there should be no lookup at all for sender address or local or domain > part. 1) Add a "domain = " setting to look up only complete email addresses in those domains. 2) You forgot to show parameter settings (output from the command "postconf -n | grep ldap") that shows WHAT Postfix is using the table for. Wietse
Transport maps - lookups happen for recipient but also for sender (which is not necessary)
Hello, I found out that my postfix does a lot of useless (LDAP) requests (in my opinion) when transport maps are enabled and in place. I use transport maps to map incoming mails to different destination hosts, based on destination mail address. So there should be no lookup at all for sender address or local or domain part. But I can see a lot of those requests happening on my LDAP instantly after the "mail from:<>" command in smtp session. But I don't see any reason why this should be happening... How can I disable those lookups for sender addresses (that obviously don't exist on my mail system). Any help or idea or lead in a direction is very appreciated, thanks in advance! My ldap query looks like this ( transport_maps =ldap:transport.cf ): server_host = ldaps://x:636 version = 3 search_base = ou=mail-users,o=xx,c=xxx query_filter = (|(mail=%s)(mailalternateaddress=%s)) result_attribute = mailTransport debuglevel = 1 bind = no The log that is produced in debug mode: https://pastebin.com/V8RPcXa0
Re: backop-transport maps
W dniu 24.01.2023 o 13:03, Wietse Venema pisze: natan: W dniu 24.01.2023 o?12:05, Wietse Venema pisze: natan: Hi For test i runnig gallera claster + haproxy haproxy: . listen galera-test bind 10.10.10.10:3307 balance leastconn mode tcp option tcplog option tcpka option httpchk server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2 fall 2 server sql2 10.10.10.12:3306 check port 9200 inter 12000 rise 2 fall 2 server sql3 10.10.10.13:3306 check port 9200 inter 12000 rise 2 fall 2 server sql4 10.10.10.14:3306 check port 9200 inter 12000 rise 2 fall 2 works fine (galera+haproxy+keepalive) but ... I had a problem once like scenario: And that problem is now solved with the load balancer? No Old (exists) process cann connect to mysql - newer connections didn't have this problem and in logs i get many: warning: proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf lookup error for "u...@domain.lt" You have proxy:mysql lookup errors AFTER ADDING a load balancer for the myaql server? From the beginning of such a solution machine1 machine2 machine3,4,5,6 [postfix]--[-haproxy--galera]---sqlX I'm thinking about it but it doesn't make sense: 1)postfix+haproxy local In haproxy local (in this same machine where is postfix) - server EXTERNAL 10.10.10.1:3306 check port 9200 inter 12000 rise 2 fall 2 - server local 127.0.0.1:3307 check backup Wietse Wietse --
Re: backop-transport maps
natan: > W dniu 24.01.2023 o?12:05, Wietse Venema pisze: > > natan: > >> Hi > >> For test i runnig gallera claster + haproxy > >> > >> haproxy: > >> . > >> listen galera-test > >> bind 10.10.10.10:3307 > >> balance leastconn > >> mode tcp > >> option tcplog > >> option tcpka > >> option httpchk > >> > >> server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2 fall 2 > >> server sql2 10.10.10.12:3306 check port 9200 inter 12000 rise 2 fall 2 > >> server sql3 10.10.10.13:3306 check port 9200 inter 12000 rise 2 fall 2 > >> server sql4 10.10.10.14:3306 check port 9200 inter 12000 rise 2 fall 2 > >> > >> works fine (galera+haproxy+keepalive) > >> > >> but ... > >> I had a problem once like scenario: > > And that problem is now solved with the load balancer? > No > Old (exists) process cann connect to mysql - newer connections didn't > have this problem and in logs i get many: > warning: proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf lookup > error for "u...@domain.lt" You have proxy:mysql lookup errors AFTER ADDING a load balancer for the myaql server? Wietse Wietse
Re: backop-transport maps
W dniu 24.01.2023 o 12:05, Wietse Venema pisze: natan: Hi For test i runnig gallera claster + haproxy haproxy: . listen galera-test bind 10.10.10.10:3307 balance leastconn mode tcp option tcplog option tcpka option httpchk server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2 fall 2 server sql2 10.10.10.12:3306 check port 9200 inter 12000 rise 2 fall 2 server sql3 10.10.10.13:3306 check port 9200 inter 12000 rise 2 fall 2 server sql4 10.10.10.14:3306 check port 9200 inter 12000 rise 2 fall 2 works fine (galera+haproxy+keepalive) but ... I had a problem once like scenario: And that problem is now solved with the load balancer? No Old (exists) process cann connect to mysql - newer connections didn't have this problem and in logs i get many: warning: proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf lookup error for "u...@domain.lt" like postfix not close thats connections - this is probbaly when I use proxy:mysql/etc/postfix/maps ? Of course, if I restart postfix, the problem will not occur maybe I must tunning some timeouts/cache on postfix ? Wietse --
Re: backop-transport maps
natan: > Hi > For test i runnig gallera claster + haproxy > > haproxy: > . > listen galera-test > bind 10.10.10.10:3307 > balance leastconn > mode tcp > option tcplog > option tcpka > option httpchk > > server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2 fall 2 > server sql2 10.10.10.12:3306 check port 9200 inter 12000 rise 2 fall 2 > server sql3 10.10.10.13:3306 check port 9200 inter 12000 rise 2 fall 2 > server sql4 10.10.10.14:3306 check port 9200 inter 12000 rise 2 fall 2 > > works fine (galera+haproxy+keepalive) > > but ... > I had a problem once like scenario: And that problem is now solved with the load balancer? Wietse
Re: backop-transport maps
Hi For test i runnig gallera claster + haproxy haproxy: . listen galera-test bind 10.10.10.10:3307 balance leastconn mode tcp option tcplog option tcpka option httpchk server sql1 10.10.10.11:3306 check port 9200 inter 12000 rise 2 fall 2 server sql2 10.10.10.12:3306 check port 9200 inter 12000 rise 2 fall 2 server sql3 10.10.10.13:3306 check port 9200 inter 12000 rise 2 fall 2 server sql4 10.10.10.14:3306 check port 9200 inter 12000 rise 2 fall 2 works fine (galera+haproxy+keepalive) but ... I had a problem once like scenario: 1)There was a problem with the network connection to the database sql2 2)Haproxy flagged "serwer sql2" as error and not letting new traffic to node sql2 3)Some connections were hanging from postfix to haproxy -> sql2 like haproxy dont sent RST 4)old process cann connect to mysql - newer connections didn't have this problem and in logs i get many: warning: proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf lookup error for "u...@domain.lt" 5)problem with sql2 wax fixed 6)some old process still can't connect to mysql - newer connections didn't have this problem As if postfix wouldn't reconnect itself - after some times all works fine And I would like to eliminate it and I dont have idea where i must find "problem" I use everywhere proxy:mysql:/etc/postfix/mysql_maps. W dniu 20.01.2023 o 18:43, Wietse Venema pisze: natan: W dniu 20.01.2023 o?15:04, Wietse Venema pisze: natan: Hi I try to run "backup" transport maps like: smtpd_sender_login_maps = #first-main database proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf #second-backup proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf Both databases are the same because they are synchronized (cluser gallera) but the first is in other machines and second in local (database ~150MB) I am thinking of such a solution as if there was a problem with the connection to the main database. does this solution make sense? Postfix does not know that the two databases are identical, and therefore it must assume that the databases can return different results. When databases can produce different results, skipping a database can produce an incorrect result. For correctness reasons, Postfix must stop when a database fails to produce a result, and it must not skip to the next database. Right. That would make a double query like 1)cannot find user in first go to second Yes. The first database produces a reply (not found). 2)cannot connect first go to second No. Here the dtabase produces no reply, and Postfix cannot know that the two databases are identical, therefore it must not skip the non-responding database. That is the difference with a load balancer. A load balancer knows that its backends provide an indentical service. If you need fast fail over from one database mirror to another, use a load balancer. I don't think that it would be a good idea to build a database load balancer into Postfix. Wietse --
Re: relay transport ignore
Thanks i will try
relay_domains = domainname
Il 20/01/2023 23:20, raf ha scritto:
On Fri, Jan 20, 2023 at 03:25:39PM +0100, Matteo Cazzador
wrote:
Hi, this is the postconf -n (i'm using virtualmin with virtual domain)
*# postconf*
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
compatibility_level = 2
header_checks = pcre:/etc/postfix/header_checks.pcre
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
message_size_limit = 3072
milter_default_action = accept
milter_protocol = 3
mydestination = $myhostname, virtualmin.domain.it , localhost
myhostname = virtualmin.domain.it
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters =
unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
Not relevant, but: The above line performs greylisting on
locally originating mail. I don't think that's usually done.
Greylisting is usually for mail that arrives over the network.
That's handled by the smtpd_milters below.
readme_directory = no
recipient_delimiter = +
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_loglevel = 0
smtp_tls_mandatory_ciphers = medium
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_milters =
unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
smtpd_recipient_restrictions = check_recipient_access
regexp:/etc/postfix/pcre_reject, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination, check_policy_service,
inet:127.0.0.1:10023 check_policy_service inet:127.0.0.1:10023
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = check_sender_access
regexp:/etc/postfix/pcre_reject, permit_sasl_authenticated
smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_medium_cipherlist =
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHA
CHA20_POLY1305_SHA256
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
*# Transport (*/etc/postfix/transport*)
*
"domainname" relay:[oldhost IP] (i try smtp:[] too)
domainname is the domain i refer.
Thanks
If the double quote characters are really in the
transport file, remove them.
But I think the real problem is that you haven't
specified anywhere what domains the server will accept
for relaying. By default, the server will accept mail
for itself (i.e., $mydestination).
If you want it to accept mail for any other domains, you
need to specify them in one of these parameters:
relay_domains
virtual_alias_domains
virtual_mailbox_domains
See the postconf(5) manual entry for details. I suspect
that adding this might help:
relay_domains = domainname
with "domainname" replaced by the actual domain.
You can remove it when you later change the postfix
configuration on the second server to handle domainname
as a virtual domain (unless I've misunderstood your
intentions).
I'd recommend reading:
https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.postfix.org%2FVIRTUAL_README.html&e=9cf8f224&h=91bf8d67&f=y&p=y
https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.postfix.org%2FADDRESS_CLASS_README.html&e=9cf8f224&h=a7043703&f=y&p=y
https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.postfix.org%2FSMTPD_ACCESS_README.html&e=9cf8f224&h=b3821e62&f=y&p=y
cheers,
raf
Il 17/01/2023 03:02, raf ha scritto:
On Fri, Jan 13, 2023 at 02:25:06PM +0100, Matteo Cazzador
wrote:
Hi, i
Re: relay transport ignore
On Fri, Jan 20, 2023 at 03:25:39PM +0100, Matteo Cazzador
wrote:
> Hi, this is the postconf -n (i'm using virtualmin with virtual domain)
>
> *# postconf*
>
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> allow_percent_hack = no
> append_dot_mydomain = no
> biff = no
> broken_sasl_auth_clients = yes
> compatibility_level = 2
> header_checks = pcre:/etc/postfix/header_checks.pcre
> home_mailbox = Maildir/
> inet_interfaces = all
> inet_protocols = all
> mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
> mailbox_size_limit = 0
> message_size_limit = 3072
> milter_default_action = accept
> milter_protocol = 3
> mydestination = $myhostname, virtualmin.domain.it , localhost
> myhostname = virtualmin.domain.it
> mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
> myorigin = /etc/mailname
> non_smtpd_milters =
> unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
Not relevant, but: The above line performs greylisting on
locally originating mail. I don't think that's usually done.
Greylisting is usually for mail that arrives over the network.
That's handled by the smtpd_milters below.
> readme_directory = no
> recipient_delimiter = +
> sender_bcc_maps = hash:/etc/postfix/bcc
> sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay
> smtp_dns_support_level = dnssec
> smtp_host_lookup = dns
> smtp_tls_loglevel = 0
> smtp_tls_mandatory_ciphers = medium
> smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_use_tls = yes
> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
> smtpd_milters =
> unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
> smtpd_recipient_restrictions = check_recipient_access
> regexp:/etc/postfix/pcre_reject, permit_mynetworks,
> permit_sasl_authenticated, reject_unauth_destination, check_policy_service,
> inet:127.0.0.1:10023 check_policy_service inet:127.0.0.1:10023
> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
> defer_unauth_destination
> smtpd_sasl_auth_enable = yes
> smtpd_sender_restrictions = check_sender_access
> regexp:/etc/postfix/pcre_reject, permit_sasl_authenticated
> smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
> smtpd_tls_auth_only = no
> smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
> smtpd_tls_key_file = /etc/postfix/postfix.key.pem
> smtpd_tls_mandatory_ciphers = medium
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
> smtpd_tls_received_header = yes
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = yes
> tls_medium_cipherlist =
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHA
> CHA20_POLY1305_SHA256
> tls_preempt_cipherlist = yes
> tls_random_source = dev:/dev/urandom
> tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
> transport_maps = hash:/etc/postfix/transport
> virtual_alias_maps = hash:/etc/postfix/virtual
>
> *# Transport (*/etc/postfix/transport*)
> *
>
> "domainname" relay:[oldhost IP] (i try smtp:[] too)
>
>
> domainname is the domain i refer.
>
> Thanks
If the double quote characters are really in the
transport file, remove them.
But I think the real problem is that you haven't
specified anywhere what domains the server will accept
for relaying. By default, the server will accept mail
for itself (i.e., $mydestination).
If you want it to accept mail for any other domains, you
need to specify them in one of these parameters:
relay_domains
virtual_alias_domains
virtual_mailbox_domains
See the postconf(5) manual entry for details. I suspect
that adding this might help:
relay_domains = domainname
with "domainname" replaced by the actual domain.
You can remove it when you later change the postfix
configuration on the second server to handle domainname
as a virtual domain (unless I've misunderstood your
intentions).
I'd recommend reading:
http://www.postfix.org/VIRTUAL_README.html
http://www.postfix.org/ADDRESS_CLASS_README.html
http://www.postfix.org/SMTPD_ACCESS_README.html
cheers,
raf
> Il 17/01/2023 03:02, raf ha scritto:
> > On Fri, Jan 13, 2023 at 02:25:0
Re: backop-transport maps
natan: > W dniu 20.01.2023 o?15:04, Wietse Venema pisze: > > natan: > >> Hi > >> I try to run "backup" transport maps like: > >> > >> smtpd_sender_login_maps = > >> #first-main database > >> proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf > >> #second-backup > >> proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf > >> > >> Both databases are the same because they are synchronized (cluser > >> gallera) but the first is in other machines and second in local > >> (database ~150MB) > >> > >> I am thinking of such a solution as if there was a problem with the > >> connection to the main database. > >> > >> does this solution make sense? > > Postfix does not know that the two databases are identical, and > > therefore it must assume that the databases can return different > > results. When databases can produce different results, skipping > > a database can produce an incorrect result. > > > > For correctness reasons, Postfix must stop when a database fails > > to produce a result, and it must not skip to the next database. > Right. That would make a double query like > 1)cannot find user in first go to second Yes. The first database produces a reply (not found). > 2)cannot connect first go to second No. Here the dtabase produces no reply, and Postfix cannot know that the two databases are identical, therefore it must not skip the non-responding database. That is the difference with a load balancer. A load balancer knows that its backends provide an indentical service. If you need fast fail over from one database mirror to another, use a load balancer. I don't think that it would be a good idea to build a database load balancer into Postfix. Wietse
Re: backop-transport maps
W dniu 20.01.2023 o 15:04, Wietse Venema pisze: natan: Hi I try to run "backup" transport maps like: smtpd_sender_login_maps = #first-main database proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf #second-backup proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf Both databases are the same because they are synchronized (cluser gallera) but the first is in other machines and second in local (database ~150MB) I am thinking of such a solution as if there was a problem with the connection to the main database. does this solution make sense? Postfix does not know that the two databases are identical, and therefore it must assume that the databases can return different results. When databases can produce different results, skipping a database can produce an incorrect result. For correctness reasons, Postfix must stop when a database fails to produce a result, and it must not skip to the next database. Right. That would make a double query like 1)cannot find user in first go to second 2)cannot connect first go to second If found in first database go back This would all be fine if the base was synchronized (mysql galera watches over it) but sometimes double query. Or maby use localhaproxy ? Yes, if you have haproxy tests that validate the database response, i.e. the database produces the expected answer for a specific query. Merely making a TCP connection is not sufficient. Thinking about server galera01 10.10.10.10:3306 server galera02 127.0.0.1:3306 backup and special check database Wietse Why I ask. Because I had a problem once like scenario: 1)There was a problem with the network connection to the database (problem with switch) 2)Postfix cannot connect to mysql - It is obvious 3)problem with switch was fixed (1m) 4)some old process cann connect to mysql - newer connections didn't have this problem As if postfix wouldn't reconnect itself - after some times all works fine And I would like to eliminate it I use everywhere proxy:mysql:/etc/postfix/mysql_maps. --
Re: relay transport ignore
Hi, this is the postconf -n (i'm using virtualmin with virtual domain)
*# postconf*
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
compatibility_level = 2
header_checks = pcre:/etc/postfix/header_checks.pcre
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
message_size_limit = 3072
milter_default_action = accept
milter_protocol = 3
mydestination = $myhostname, virtualmin.domain.it , localhost
myhostname = virtualmin.domain.it
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
non_smtpd_milters =
unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
readme_directory = no
recipient_delimiter = +
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_relay
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtp_tls_loglevel = 0
smtp_tls_mandatory_ciphers = medium
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_milters =
unix:/var/run/milter-greylist/milter-greylist.sock,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
smtpd_recipient_restrictions = check_recipient_access
regexp:/etc/postfix/pcre_reject, permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination,
check_policy_service, inet:127.0.0.1:10023 check_policy_service
inet:127.0.0.1:10023
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sender_restrictions = check_sender_access
regexp:/etc/postfix/pcre_reject, permit_sasl_authenticated
smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_medium_cipherlist =
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHA
CHA20_POLY1305_SHA256
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
tls_server_sni_maps = hash:/etc/postfix/vmail_ssl.map
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
*# Transport (*/etc/postfix/transport*)
*
"domainname" relay:[oldhost IP] (i try smtp:[] too)
domainname is the domain i refer.
Thanks
Il 17/01/2023 03:02, raf ha scritto:
On Fri, Jan 13, 2023 at 02:25:06PM +0100, Matteo Cazzador
wrote:
Hi, i 've question, i need to migrate a virtual domain from 2 server (with
postfix).
On the new server i define mail users and domain but it'isnt in production
now dns record defined.
On the same new soerver i've other virtual domain.
I want that , for a few days, if one user of other domain hosted on the same
new server send an email to the new migrate domain it will be relayed to the
orld server and not locally delivered.
I try with transport without success.
Can someone plese help me?
Thanks
Perhaps it would be best to show what you tried by sending the
output of "postconf -n" and your transport table on the new host.
Someone might be able to see what's wrong with it.
cheers,
raf
--
Messaggio analizzato da Libraesva ESG.
Seguire il link qui sotto per segnalarlo come spam:
https://mailgateway-4.netlite.it/action/B045F2602B5.ADF68/learn-spam
Seguire il link qui sotto per mettere in blacklist il mittente:
https://mailgateway-4.netlite.it/action/B045F2602B5.ADF68/blacklist
--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
Le informazioni contenute in questa e-mail e nei files eventualmente
allegati sono destinate unicamente ai destinatari della stessa
e sono da considerarsi strettamente riservate.
E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere
il contenuto della presente senza il preventivo consenso, ai sensi
dell'articolo 616 c.p. e della Legge n. 196/2003.
Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo
immediatamente all'indirizzo mittente, nonché di cancellarne i
Re: backop-transport maps
natan: > Hi > I try to run "backup" transport maps like: > > smtpd_sender_login_maps = > #first-main database > proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf > #second-backup > proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf > > Both databases are the same because they are synchronized (cluser > gallera) but the first is in other machines and second in local > (database ~150MB) > > I am thinking of such a solution as if there was a problem with the > connection to the main database. > > does this solution make sense? Postfix does not know that the two databases are identical, and therefore it must assume that the databases can return different results. When databases can produce different results, skipping a database can produce an incorrect result. For correctness reasons, Postfix must stop when a database fails to produce a result, and it must not skip to the next database. > Or maby use localhaproxy ? Yes, if you have haproxy tests that validate the database response, i.e. the database produces the expected answer for a specific query. Merely making a TCP connection is not sufficient. Wietse
backop-transport maps
Hi I try to run "backup" transport maps like: smtpd_sender_login_maps = #first-main database proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf #second-backup proxy:mysql:/etc/postfix/mysql_sender_login_maps-backup.cf Both databases are the same because they are synchronized (cluser gallera) but the first is in other machines and second in local (database ~150MB) I am thinking of such a solution as if there was a problem with the connection to the main database. does this solution make sense? Or maby use localhaproxy ? --
Re: mail queued by transport
Sean Hennessey: > Is there a way to see the transport that queued mail is using? > > I just created a new transport and pointed a domain to it. The > server also had mail for that domain queued up under the old > transport. > > Is there any way I can find out what transport the mail is using? No. Transports are associated with recipients, not meessages, and that asociation is made only during delivery. Wietse
mail queued by transport
Is there a way to see the transport that queued mail is using? I just created a new transport and pointed a domain to it. The server also had mail for that domain queued up under the old transport. Is there any way I can find out what transport the mail is using? I didn't see transport in the field list when I ran a json dump of the queue.
Re: relay transport ignore
On Fri, Jan 13, 2023 at 02:25:06PM +0100, Matteo Cazzador wrote: > Hi, i 've question, i need to migrate a virtual domain from 2 server (with > postfix). > > On the new server i define mail users and domain but it'isnt in production > now dns record defined. > > On the same new soerver i've other virtual domain. > > I want that , for a few days, if one user of other domain hosted on the same > new server send an email to the new migrate domain it will be relayed to the > orld server and not locally delivered. > > I try with transport without success. > > Can someone plese help me? > > Thanks Perhaps it would be best to show what you tried by sending the output of "postconf -n" and your transport table on the new host. Someone might be able to see what's wrong with it. cheers, raf
Re: make transport decisions based on headers not envelope
On Fri, Jan 13, 2023 at 05:36:16AM +, Sean Hennessey wrote: > I was using the sender_dependent_default_transport_maps to pick off > what I thought was going to be the interesting from domain. The good > news is that this mail is coming from customer applications. It's not > coming from regular user mail clients. So I can guarantee there is > going to be a single from header. The recipients are also never local. > This machine is a pure relay. > > Looks like it's time to learn me some milter. Can you recommend any > good places to start on walking me through building one. I've got a > programming background, so coding doesn't scare me. I found the Python "Milter" module quite easy to use. FWIW, you don't strictly need milters if all you is something equivalent to a regex match on the "From:" header, header_checks can do that, BUT: * With a milter you get an address parser, not just regular expressions, so that: From: "" parses correctly. * With a milter you can add logic to deal with missing headers, multiple addresses, ... and perhaps also inspect the client IP address or SASL id, ... So do use a milter, but do it right. A crude regex check doesn't count. -- Viktor.
relay transport ignore
Hi, i 've question, i need to migrate a virtual domain from 2 server (with postfix). On the new server i define mail users and domain but it'isnt in production now dns record defined. On the same new soerver i've other virtual domain. I want that , for a few days, if one user of other domain hosted on the same new server send an email to the new migrate domain it will be relayed to the orld server and not locally delivered. I try with transport without success. Can someone plese help me? Thanks -- Rispetta l'ambiente: se non ti è necessario, non stampare questa mail. Le informazioni contenute in questa e-mail e nei files eventualmente allegati sono destinate unicamente ai destinatari della stessa e sono da considerarsi strettamente riservate. E' proibito copiare, salvare, utilizzare, inoltrare a terzi e diffondere il contenuto della presente senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 196/2003. Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto senza procedere ad ulteriore o differente trattamento. ** Ing. Matteo Cazzador NetLite snc di Cazzador Gagliardi Corso Vittorio Emanuele II, 188 37069 Villafranca di Verona VR Tel 0454856656 Fax 0454856655 Email: mat...@netlite.it Web: http://www.netlite.it ** smime.p7s Description: Firma crittografica S/MIME
Re: make transport decisions based on headers not envelope
Sean Hennessey: > I was using the sender_dependent_default_transport_maps to pick > off what I thought was going to be the interesting from domain. > The good news is that this mail is coming from customer applications. > It's not coming from regular user mail clients. So I can guarantee > there is going to be a single from header. The recipients are also > never local. This machine is a pure relay. > > Looks like it's time to learn me some milter. Can you recommend > any good places to start on walking me through building one. I've > got a programming background, so coding doesn't scare me. > > Thanks again. There are language bindings for C, Perl, Python, Rust, ..., and even PHP. So there will likely be one that you wuold be comfortable with. These implement something similar to the Sendmail reference API: http://www.elandsys.com/resources/sendmail/libmilter/api.html Wietse
Re: make transport decisions based on headers not envelope
I was using the sender_dependent_default_transport_maps to pick off what I thought was going to be the interesting from domain. The good news is that this mail is coming from customer applications. It's not coming from regular user mail clients. So I can guarantee there is going to be a single from header. The recipients are also never local. This machine is a pure relay. Looks like it's time to learn me some milter. Can you recommend any good places to start on walking me through building one. I've got a programming background, so coding doesn't scare me. Thanks again. From: owner-postfix-us...@postfix.org on behalf of Viktor Dukhovni Sent: Thursday, January 12, 2023 11:48 PM To: postfix-users@postfix.org Subject: Re: make transport decisions based on headers not envelope On Fri, Jan 13, 2023 at 03:22:41AM +, Sean Hennessey wrote: > I'm back to the experts for some question. I'm trying to help dig some > folks out of hole. Is there anyway possible to make a decision on > where to send mail based on a friendly from header instead of the > envelope from? NO! That way lies madness and endless mail loops. Or, more precisely, absolutely not when deciding which way to route the *recipients* of the message. > It turns out that their system using an envelope from that's the same > for everyone, and just uses the customer specific from in the From: > header. That's probably the better thing to be doing, but it just > burnt me because the system I'm most recently working on matches > aligns the envelope from and the header from. Presumably, this is a case of trying to use: sender_dependendent_default_transport_maps this could in principle be based on the "From:" header without risking loops, however there's no such feature in Postfix, and there are various potential complications: - What happens when there's both a "Sender:" and a "From:" header? - What happens when "Resent-From:" is present? - What happens in the unusual case where there are multiple "From:" addresses (allowed by RFC822, with "Sender:" required). - What happens when there is no "From:" header? (And Postfix adds "Apparently-From: "). - ... So, provided the accepted recipients are *NEVER EVER* local or any other address class, you'd want to use a milter to prepend a header that indicates the exit transport, and then use milter_header_checks to specify a "FILTER" action that forces all recipients to that transport. This is a bit ugly, but puts the ball in your court (all the messy details are in your milter, whatever you decide goes). Don't forget, the precondition, there must never be any recipients in any address class other than "default" or else routing will be wrong. -- Viktor.
Re: make transport decisions based on headers not envelope
On Fri, Jan 13, 2023 at 03:22:41AM +, Sean Hennessey wrote: > I'm back to the experts for some question. I'm trying to help dig some > folks out of hole. Is there anyway possible to make a decision on > where to send mail based on a friendly from header instead of the > envelope from? NO! That way lies madness and endless mail loops. Or, more precisely, absolutely not when deciding which way to route the *recipients* of the message. > It turns out that their system using an envelope from that's the same > for everyone, and just uses the customer specific from in the From: > header. That's probably the better thing to be doing, but it just > burnt me because the system I'm most recently working on matches > aligns the envelope from and the header from. Presumably, this is a case of trying to use: sender_dependendent_default_transport_maps this could in principle be based on the "From:" header without risking loops, however there's no such feature in Postfix, and there are various potential complications: - What happens when there's both a "Sender:" and a "From:" header? - What happens when "Resent-From:" is present? - What happens in the unusual case where there are multiple "From:" addresses (allowed by RFC822, with "Sender:" required). - What happens when there is no "From:" header? (And Postfix adds "Apparently-From: "). - ... So, provided the accepted recipients are *NEVER EVER* local or any other address class, you'd want to use a milter to prepend a header that indicates the exit transport, and then use milter_header_checks to specify a "FILTER" action that forces all recipients to that transport. This is a bit ugly, but puts the ball in your court (all the messy details are in your milter, whatever you decide goes). Don't forget, the precondition, there must never be any recipients in any address class other than "default" or else routing will be wrong. -- Viktor.
make transport decisions based on headers not envelope
I'm back to the experts for some question. I'm trying to help dig some folks out of hole. Is there anyway possible to make a decision on where to send mail based on a friendly from header instead of the envelope from? I just got done building up a multi-instance postfix set up that was supposed to divert mail from a certain domain to instance I had that applied some heavy throttling for a few to domains. It turns out that their system using an envelope from that's the same for everyone, and just uses the customer specific from in the From: header. That's probably the better thing to be doing, but it just burnt me because the system I'm most recently working on matches aligns the envelope from and the header from. Thanks in advance for any suggestions.
Re: Gmail specific transport
Viktor Dukhovni:
> On Thu, Jun 16, 2022 at 07:35:20PM -0400, Wietse Venema wrote:
>
> > Bob Proulx:
> > > Is there a transport mapping equivalent to match against the MX host
> > > instead of against the the recipient address? That's really what is
> > > desired here. I didn't think such a feature existed yet.
> >
> > it would require a Postfix lookup table that returns MX hosts for
> > a domain,
> >
> > pipemap:{domain-to-mx, inline:{ {.google.com = slow:} }
> >
> > plus some safeguard to avoid doing this for local deliveries.
>
> Transport resolution does remote DNS lookups will be a prohibitive
> performance bottleneck on systems delivering a steady non-trivial stream
> of mail. The queue manager is not multi-threaded, and each recipient
> domain can/will incur some delay.
We'd obviously have to make some lookups asynchronous.
But the core problem is harder: using a key-value protocol to
generate transport:nexthop from DNS lookup results.
Wietse
Re: Gmail specific transport
Viktor Dukhovni wrote: > Transport resolutiont that does remote DNS lookups will be a prohibitive > performance bottleneck on systems delivering a steady non-trivial stream > of mail. The queue manager is not multi-threaded, and each recipient > domain can/will incur some delay. Yes. That would slow things down. Not worth it. > I would not recommend doing this until (some nebulous day) the queue > manager can perform asynchronous transport resolution for multiple > recipients in parallel. I'll look forward to it at some nebulous day in the future. It isn't really a problem now since it is really only @gmail.com addresses specifically that run into this problem. Because of the prevalence of exactly that one address to be a problem. And that is handled by the scheme as described. So no burdensome problem to solve at this moment. Thanks for the help! :-) Bob
Re: Gmail specific transport
On Thu, Jun 16, 2022 at 07:35:20PM -0400, Wietse Venema wrote:
> Bob Proulx:
> > Is there a transport mapping equivalent to match against the MX host
> > instead of against the the recipient address? That's really what is
> > desired here. I didn't think such a feature existed yet.
>
> it would require a Postfix lookup table that returns MX hosts for
> a domain,
>
> pipemap:{domain-to-mx, inline:{ {.google.com = slow:} }
>
> plus some safeguard to avoid doing this for local deliveries.
Transport resolutiont that does remote DNS lookups will be a prohibitive
performance bottleneck on systems delivering a steady non-trivial stream
of mail. The queue manager is not multi-threaded, and each recipient
domain can/will incur some delay.
I would not recommend doing this until (some nebulous day) the queue
manager can perform asynchronous transport resolution for multiple
recipients in parallel.
--
Viktor.
