[pfx] multi smtp servers question
Hello list, We have 3 smtp servers for sending messages. When mail in one server has delivery issue, how can we setup it to use another more servers for second/third delivery? Thanks Corey ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] domain based vhosts
Hello list, another more question, does postfix support domain based vhosts? such as different vhost has different policies, routes, milters etc. Thanks Corey ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] multi smtp servers question
* Corey Hickman via Postfix-users : > Hello list, > > We have 3 smtp servers for sending messages. When mail in one server has > delivery issue, how can we setup it to use another more servers for > second/third delivery? You could use smtp_fallback_relay -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 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: domain based vhosts
Corey Hickman via Postfix-users: > Hello list, > > another more question, does postfix support domain based vhosts? > such as different vhost has different policies, routes, milters etc. For near-complete isolation of queues, policies, and so on, https://www.postfix.org/MULTI_INSTANCE_README.html comes to mind. Domains still share fate when a shared host crashes or loses networking). Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
Sean Gallagher via Postfix-users: > how is "inet_interfaces = all" different to "inet_interfaces = " (i.e. > blank)? One says that Postfix will provide network service on all IP addresses, the other does not, and all this is subject to overrides in master.cf. Neither constrains the SMTP client source IP address. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: multi smtp servers question
Corey Hickman via Postfix-users skrev den 2023-05-04 14:18: We have 3 smtp servers for sending messages. When mail in one server has delivery issue, how can we setup it to use another more servers for second/third delivery? retroisk answer, when postfix maillist was on cloud9, it had 3 ipv4, 3 ipv6, and i have newver seen mails that was remotely tempfailed used another ip in cloud9, why this ? answer to my own question is greylist back to you, what do you like to get ? problem is that when mails is in one queue, it have to stay there until delivered, if you move it forward to another of your servers its delivered, and can give backscatter back to original senders with can also be forged senders, if not carefull setup maybe https://gitlab.com/fumail/pfqd can be used to let all see where there is minimal queue files, and other pickup services can use this info to not send new mails to a fully loaded server ? room for implemention for postfix developpers ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: [ext] multi smtp servers question
Ralf Hildebrandt via Postfix-users skrev den 2023-05-04 14:41: * Corey Hickman via Postfix-users : Hello list, We have 3 smtp servers for sending messages. When mail in one server has delivery issue, how can we setup it to use another more servers for second/third delivery? You could use smtp_fallback_relay this will work for mx with one ipv4, one ipv6, but fails if mx have more ips, think greylistning forever cloud9 newer did that ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: multi smtp servers question
Benny Pedersen via Postfix-users: > [OT] answer, when postfix maillist was on cloud9, it had 3 ipv4, 3 > ipv6, and i have newver seen mails that was remotely tempfailed used > another ip in cloud9, why this ? Because each host had its own mail queue. Only the majordomo related files were shared, not the message flow. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: multi smtp servers question
Wietse Venema via Postfix-users skrev den 2023-05-04 15:28: Benny Pedersen via Postfix-users: [OT] answer, when postfix maillist was on cloud9, it had 3 ipv4, 3 ipv6, and i have newver seen mails that was remotely tempfailed used another ip in cloud9, why this ? Because each host had its own mail queue. Only the majordomo related files were shared, not the message flow. OP asked how to make this problem of move queue files to another server if first failed, with pfqd fail state can be many things, but if postfix have no support for move queue files its not going to solve anything, only thing that can be solved with pfqd is to cluster spread load and fail states ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: multi smtp servers question
Benny Pedersen via Postfix-users: > Wietse Venema via Postfix-users skrev den 2023-05-04 15:28: > > Benny Pedersen via Postfix-users: > >> [OT] answer, when postfix maillist was on cloud9, it had 3 ipv4, 3 > >> ipv6, and i have newver seen mails that was remotely tempfailed used > >> another ip in cloud9, why this ? > > > > Because each host had its own mail queue. Only the majordomo > > related files were shared, not the message flow. > > OP asked how to make this problem of move queue files to another server > if first failed, with pfqd fail state can be many things, but if postfix > have no support for move queue files its not going to solve anything, > only thing that can be solved with pfqd is to cluster spread load and > fail states I see little benefit in swapping messages between equal-configuration MTA instances with IP addresses that are in a similar range and that have similar reputations. smtp_fallback_relay is meant to avoid clogging up a fast-path configuration (short timeouts, no retries, etc.) by handing off problematic deliveries to a slow-path configuration that uses a different delivery strategy. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: domain based vhosts
On 2023-05-04 at 08:21:31 UTC-0400 (Thu, 04 May 2023 14:21:31 +0200) Corey Hickman via Postfix-users is rumored to have said: Hello list, another more question, does postfix support domain based vhosts? It depends on what you mean by that... There is no mechanism in SMTP for a server to determine what host and/or domain names a client has used to choose where to make the connection. HTTP has the Host header and very little flexibility until that header is available, where an analogous header for email would be unavailable until the DATA phase, after at least one recipient has been explicitly accepted. such as different vhost has different policies, routes, milters etc. See the MULTI_INSTANCE_README file in the Postfix documentation for what Postfix *does* support in regards to having multiple instances running on a single machine. Note that instances are differentiated by IP address and TCP port number. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo 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: inet_interfaces documentation
It was more a rhetorical question in the context of documentation improvement. Specifically, the documentation doesn't actually say what [blank] means. I think something like the following would be an improvement.. Specify "all" to receive mail on all network interfaces (default), "loopback-only" to receive mail on loopback network interfaces only (Postfix version 2.2 and later) or leave blank to disable the reception of email (i.e. outgoing service only). By contrast, leaving smtp_bind_address blank does NOT disable outgoing emails. The meaning of blank is NOT obvious to the uninitiated. On 4/05/2023 11:10 pm, Wietse Venema via Postfix-users wrote: Sean Gallagher via Postfix-users: how is "inet_interfaces = all" different to "inet_interfaces = " (i.e. blank)? One says that Postfix will provide network service on all IP addresses, the other does not, and all this is subject to overrides in master.cf. Neither constrains the SMTP client source IP address. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
On Fri, May 05, 2023 at 07:01:03AM +1000, Sean Gallagher via Postfix-users wrote: > Specify "all" to receive mail on all network interfaces (default), > "loopback-only" to receive mail on loopback network interfaces only > (Postfix version 2.2 and later) or leave blank to disable the reception > of email (i.e. outgoing service only). Actually, mail can still be received when the master.cf entry specifies an explicit address:port. There is just no implicit wildcard listen address (or is a configuration error reported?). I don't know what actually happens when "inet_interfaces" is explicitly blank. To actually disable inet services, use the "master_service_disable" parameter. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
Sean Gallagher via Postfix-users: > It was more a rhetorical question in the context of documentation > improvement. Specifically, the documentation doesn't actually say what > [blank] means. I think something like the following would be an > improvement.. > > Specify "all" to receive mail on all network interfaces (default), > "loopback-only" to receive mail on loopback network interfaces only > (Postfix version 2.2 and later) or leave blank to disable the reception > of email (i.e. outgoing service only). > > By contrast, leaving smtp_bind_address blank does NOT disable outgoing > emails. The meaning of blank is NOT obvious to the uninitiated. An empty inet_interfaces means that there is no constraint for the SMTP client source IP address. I am adding some text for that. 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)
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] Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
On 5/05/23 11:33, Wietse Venema via Postfix-users wrote: An empty inet_interfaces means that there is no constraint for the SMTP client source IP address. I am adding some text for that. I think the question is, what effect does it have on the server listening address. This is from inet_listen.c: /* .IP addr /* The communication endpoint to listen on. The syntax is "host:port". /* Host and port may be specified in symbolic form or numerically. /* A null host field means listen on all network interfaces. So I would assume from that setting inet_interfaces to empty has the same effect as setting it to all (it will listen on all interfaces)? Peter ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
On Fri, May 05, 2023 at 02:08:29PM +1200, Peter via Postfix-users wrote: > On 5/05/23 11:33, Wietse Venema via Postfix-users wrote: > > An empty inet_interfaces means that there is no constraint for the > > SMTP client source IP address. I am adding some text for that. > > I think the question is, what effect does it have on the server > listening address. This is from inet_listen.c: > > /* .IP addr > /* The communication endpoint to listen on. The syntax is "host:port". > /* Host and port may be specified in symbolic form or numerically. > /* A null host field means listen on all network interfaces. > > So I would assume from that setting inet_interfaces to empty has the > same effect as setting it to all (it will listen on all interfaces)? No, it does not. Rather, it leaves zero listener addresses enabled, which only works if all "inet" services are disabled or all use explicit IP endpoints: May 05 03:43:45 amnesiac postfix/postfix-script[2812173]: starting the Postfix mail system May 05 03:43:45 amnesiac postfix/master[2812175]: fatal: /etc/postfix/master.cf: line 12: no valid IP address found: smtp May 05 03:43:47 amnesiac postfix/postfix-script[2812176]: fatal: mail system startup failed This is rarely what you want. I'd be inclined to require that the "inet_interfaces" parameter be non-empty (though it could still be effectively empty as a list by setting it to be a mixture of spaces and at least one comma). This is roughly what I expected, but did had not yet checked. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
This is rarely what you want. I'd be inclined to require that the "inet_interfaces" parameter be non-empty (though it could still be effectively empty as a list by setting it to be a mixture of spaces and at least one comma). You need to be careful what "empty" means. If inet_interfaces has only IPv4 addresses and inet_protocols includes "ipv6", then it is effectively "empty" from the ipv6 point of view, but it is clearly not "empty" -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
On Fri, May 05, 2023 at 01:57:19PM +1000, Sean Gallagher via Postfix-users wrote: > > This is rarely what you want. I'd be inclined to require that the > > "inet_interfaces" parameter be non-empty (though it could still be > > effectively empty as a list by setting it to be a mixture of spaces and > > at least one comma). > > You need to be careful what "empty" means. If inet_interfaces has only > IPv4 addresses and inet_protocols includes "ipv6", then it is > effectively "empty" from the ipv6 point of view, but it is clearly not > "empty" That's a non-issue. With that, Postfix will only listen on IPv4 as specified, when the "inet" endpoint only specifies the port. In other words: - The *primary* purpose of "inet_interfaces" is to specify the listen IP address for services with no explicit hostname or ip address specified. - A secondary, convenience function, is that the same addresses, when exactly one non-loopback, per address family, are also used as the default bind address for the associated family. An empty setting is fine for outbound connections (no fixed address), but not so good for inbound services unless you really mean to always use explicit hostname/ip prefixes for all "inet" services and want "postfix start" to fail if any are lax. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
That's a non-issue. With that, Postfix will only listen on IPv4 as specified, when the "inet" endpoint only specifies the port. That makes sense, and is exactly what I would expect, but it still needs to be documented. But it does raise another question in my mind. Many places in the documentation state that the "Local" domain class consists of $mydomain, $inet_interfaces and $proxy_interfaces. presumably any listen address specified in master.cf would also be in the "Local" domain - but I have never heard or even considered this until today. Something else that needs to be documented somewhere.. -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: inet_interfaces documentation
On Fri, May 05, 2023 at 02:34:53PM +1000, Sean Gallagher via Postfix-users wrote: > That makes sense, and is exactly what I would expect, but it still needs > to be documented. > > But it does raise another question in my mind. Many places in the > documentation state that the "Local" domain class consists of $mydomain, > $inet_interfaces and $proxy_interfaces. Correct, when the recipient is an address literal user@[ip]. > Presumably any listen address specified in master.cf would also be in > the "Local" domain. Actually, no, that's not the case, sorting of recipients into address classes should not (and does not) depend on the message entry point. This classification is performed by trivial-rewrite(8), which is not aware of or sensitive to the list endpoints of various master.cf services, its decisions are based on inet_interfaces and proxy_interfaces alone (one could have custom overrides of these for the trivial-rewrite service in master.cf, if feeling sufficiently masochistic, but really, don't). Complex configuratoins with multiple views of what's local and what's not are best handled via multiple-instances, where each instance listens on and considers local exactly the address in inet_interfaces, and there are no explicit host/address-specific entries in master.cf. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
