Re: how to setup storage for two different MX in different locations
Thanks Bill for the kind suggestion. regards Bill Cole wrote: On 19 Nov 2019, at 1:04, Merrick wrote: Hello, We plan to setup two postfix as MX servers. One is in west location, such as CA state. Another is in east location, such as NYC. The usefulness of such an architecture in modern times is marginal. If the "4th nine" (or maybe 5th) is worth doubling your hard costs and possibly doing worse to your support costs, go for it. As an example, one 2-node mail cluster I manage has had a bit less than 2 hours of downtime per node in the past year, all of it for scheduled updates, so the whole system has never been unavailable but if it was a single node it would only have been out for 2 hours of our own choosing: 99.977% available even without a "planned downtime" exemption. The second node takes us to 100% but at a significant cost of technical and human resources. The question is, how to make storage shared by two MX servers? The messages should be stored in one place, such as webmail/IMAP could read all messages directly from this location. This is not something Postfix would handle. When acting as a MX server, Postfix accepts messages and (except in cases of extreme load or malfunction) passes them in sub-second time to Something Else that manages the storage of and access to delivered mail. Sometimes that's just files on disk that can be accessed by traditional mail tools (mail/mailx, mutt, etc.) or by IMAP /POP/webmail servers. Sometimes it is an independent delivery agent that is handed messages over LMTP or a pipe or more arcane mechanisms (see master.cf's often-commented lines for delivery mechanisms Postfix can do.) What you are looking for is either an independent IMAP server OR synchronized IMAP servers. Typically webmail accesses delivered mail via IMAP. https://wiki.dovecot.org/Replication explains one way to synch 2 or more IMAP servers, using Dovecot. Cyrus IMAP also has a mechanism for it. If you are committed to truly singular storage, a single IMAP server apart from the MX servers would suffice, but I don't think that's a sensible architecture because it makes the solitary IMAP server a single point of failure. Replication allows each node to stand on its own if the other(s) fail, and avoids the problems of treating distant storage as local. It is also possible to use a commercial mail clustering solution, such as CommuniGate Pro. I hear Microsoft has some sort of supposed multi-node mail system as well... One might expect a commercial solution to be a simpler tool to support but one might be surprised.
Re: relay based on sender and destination
On Tue, Nov 19, 2019 at 10:24:30AM +0100, Angel L. Mateo wrote: > * Mail from @internal1.com and to @external1.com to be relayed through > relay.provider.com If internal1.com is just one of your internal domains, and the policy should apply to just some of your internal users, then this is a policy that is difficult to address with current Postfix transport resolution architecture. About the best one can do is route such mail through two Postfix instances, the first separates out mail from just that domain sending it to a second dedicated instance, where the transport for the destination is the custom value you want. If there's just one internal domain, then you'd simply route all internal mail out via a different Postfix MTA than the one used for inbound mail. If none of these work for you. You could try Exim. While it has had a run of security issues lately, and I personally dislike it for a variety of reasons, ... it has some built-in customization features not found in Postfix and probably can express the type of conditions you describe in its "router" selection logic. -- Viktor.
Re: may we suggest ICANN not run that many new tlds?
Demand is demand…it doesn’t matter from where it originates…. > On Nov 19, 2019, at 12:59 PM, Charles Sprickman wrote: > > >> On Nov 19, 2019, at 3:28 PM, Antonio Leding wrote: >> >> But I predict it will fall on deaf ears… >> >> Suggesting this is tantamount to suggesting the PSTN not increase the # of >> area codes or NXX numbers. Things like this are created as the demand >> grows…and due to the complete metamorphosis of the Internet over the last >> last 20 years, demand has definitely increased by at least a couple of >> orders of magnitude… > > I think that’s the wrong analogy. In my web development work, I’ve never had > a client say, “hey, to protect my brand, I’d really like to buy 400 > variations of my domain!”. > > The demand here is all from registrars hoping to sell the same “domain” 50 > times, it’s not coming from domain owners. > > C > >> >> >> >>> On Nov 19, 2019, at 12:23 PM, A. Schulze wrote: >>> >>> >>> >>> Am 19.11.19 um 10:58 schrieb Merrick: may we suggest ICANN not open a new TLD anymore? >>> yes, you can: https://www.icann.org/public-comments >> >
Re: may we suggest ICANN not run that many new tlds?
> On Nov 19, 2019, at 3:28 PM, Antonio Leding wrote: > > But I predict it will fall on deaf ears… > > Suggesting this is tantamount to suggesting the PSTN not increase the # of > area codes or NXX numbers. Things like this are created as the demand > grows…and due to the complete metamorphosis of the Internet over the last > last 20 years, demand has definitely increased by at least a couple of orders > of magnitude… I think that’s the wrong analogy. In my web development work, I’ve never had a client say, “hey, to protect my brand, I’d really like to buy 400 variations of my domain!”. The demand here is all from registrars hoping to sell the same “domain” 50 times, it’s not coming from domain owners. C > > > >> On Nov 19, 2019, at 12:23 PM, A. Schulze wrote: >> >> >> >> Am 19.11.19 um 10:58 schrieb Merrick: >>> may we suggest ICANN not open a new TLD anymore? >> yes, you can: https://www.icann.org/public-comments >
Re: may we suggest ICANN not run that many new tlds?
But I predict it will fall on deaf ears… Suggesting this is tantamount to suggesting the PSTN not increase the # of area codes or NXX numbers. Things like this are created as the demand grows…and due to the complete metamorphosis of the Internet over the last last 20 years, demand has definitely increased by at least a couple of orders of magnitude… > On Nov 19, 2019, at 12:23 PM, A. Schulze wrote: > > > > Am 19.11.19 um 10:58 schrieb Merrick: >> may we suggest ICANN not open a new TLD anymore? > yes, you can: https://www.icann.org/public-comments
Re: milter_default_action=accept not honored
Hi, In http://opendkim.org/opendkim.conf.5.html there are several error conditions defined, with the default actions for them, for instance "On-SignatureError", "On-KeyNotFound". Ar least some conditions default to tempfail. Configure the milter correctly and you should be fine. Kind regards, Tom On 19-11-19 20:45, Viktor Dukhovni wrote: On Tue, Nov 19, 2019 at 11:39:03AM -0800, Jeremiah Rothschild wrote: It seems the tempfail is from the milter, not from Postfix. Postfix is not in a position to know that the milter is not working as it should, the milter is responding "normally". That's too bad. I'm surely oversimplifying things but I figured the milter would do something like pass a non-zero exit along, which postfix could then use to make a decision on the status. Postfix isn't executing the milter as a subprocess, they communicate over a socket. If the milter returns a 4XX verdict, that's normal milter behaviour. If the milter drops the connection, times out, ... that's a milter failure, and *then* the Postfix milter_default_action kicks in. Your best bet is to invest effort in keeping your milter working properly, optimizing what happens when it is not working is likely the lesser option.
Re: may we suggest ICANN not run that many new tlds?
Am 19.11.19 um 10:58 schrieb Merrick: > may we suggest ICANN not open a new TLD anymore? yes, you can: https://www.icann.org/public-comments
Re: relay based on sender and destination
On 19.11.19 10:24, Angel L. Mateo wrote: I have a mail server relaying for different domains and using a transport map to deliver local domains. Now I need the following: * Mail from @internal1.com and to @external1.com to be relayed through relay.provider.com do you mean, random spam from any IP and fake @internal1.com sender? it's rarely useful to relay based on sender domain... * the rest of mails, to be deliver or relayed according to transport_maps I have found the sender_dependent_relayhost_maps but with this I can only check the sender but not the destination. -- 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. 99 percent of lawyers give the rest a bad name.
Re: Client host rejected
On Mon, 18 Nov 2019 17:23:43 +0100 Matus UHLAR - fantomas wrote: seems something is wrong with your (or maybe their) reverse DNS resolution... On Mon, 18 Nov 2019, siefke_lis...@web.de wrote: This is what I had: [siefke@sisi-dell ~]$ nslookup 195.128.103.214 214.103.128.195.in-addr.arpaname = netcup.silviosiefke.com. On 18.11.19 21:08, Bernardo Reino wrote: The question is whether your resolver can reverse-resolve the IP address where the message was coming from, i.e. 81.91.160.182, and not your own (of your mail server). $ dig -x 81.91.160.182 office.denic.de.3600IN A 81.91.160.182 $ dig office.denic.de office.denic.de.3508IN A 81.91.160.182 and this is, why Silvio (the OP) should not remove important content from mail replied. I have posted exactly these ;-) https://marc.info/?l=postfix-users&m=157409426700743&w=2 On 19.11.19 20:13, siefke_lis...@web.de wrote: I use unbound. I have stop unbound an use the dns direct with resolv.conf. cat /etc/resolv.conf nameserver 46.182.19.48 nameserver 80.241.218.68 nameserver 2a03:b0c0:0:1010::e9a:3001 nameserver 127.0.0.1 search silviosiefke.com 1. unbound aka 127.0.0.1 should be the first server in resolv.conf, not the last one. I think some resolvers don't use more than 3 servers. 2. what are those other IPs? Are they recursive servers provided by your ISP? Nov 19 19:58:20 netcup.silviosiefke.com postfix/smtpd[11593]: NOQUEUE: reject: RCPT from unknown[212.227.15.4]: 450 4.7.25 Client host rejected: cannot find your hostname, [212.227.15.4]; from= to= proto=ESMTP helo= dig-x 212.227.15.4 4.15.227.212.in-addr.arpa. 14109 IN PTR mout.web.de. dig mout.web.de ... mout.web.de.1800IN A 212.227.15.4 ... Self with direct dns contact it will not work. There is a big mistake. On Tue, 19 Nov 2019 14:20:43 -0500 Viktor Dukhovni wrote: Why did you stop unbound? Presumably it provides the recursive service on 127.0.0.1, which is listed below... On 19.11.19 20:38, siefke_lis...@web.de wrote: It work not. That's why so a line direct to nameserver and it work also not. sure? "dig -x 212.227.15.4 @127.0.0.1" should show (with running unbound, of course) > Nov 19 19:58:20 netcup.silviosiefke.com postfix/smtpd[11593]: NOQUEUE: > reject: RCPT from unknown[212.227.15.4]: 450 4.7.25 Client host rejected: > cannot find your hostname, [212.227.15.4]; from= > to= proto=ESMTP helo= Is smtpd(8) chrooted? It may be using a different set of nameservers. Yes sure I change nothing in master.cf only auth stuff. So maybe this was it. "maybe" is not enough. if your system uses chorooted smtpd, the /etc/resolv.conf within that chroot should contain proper Nov 19 20:34:13 netcup.silviosiefke.com postfix/lmtp[16735]: 5180881406: to=, relay=netcup.silviosiefke.com[private/dovecot-lmtp], delay=1, delays=0.91/0.02/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 J/VlD7VD1F1gQQAAJFpQ3g Saved) this is lmtp client, not smtp server, completely unrelated. So one question I have. Why I must change this on this server, but my master mail server running Debian need this change not. perhaps your master mail server running debian has different configuration. -- 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 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
Re: Client host rejected
On Tue, Nov 19, 2019 at 08:38:53PM +0100, siefke_lis...@web.de wrote: > > Why did you stop unbound? Presumably it provides the recursive > > service on 127.0.0.1, which is listed below... > > It work not. Then figure out how to make it work. That should be your one and only nameserver. > > > Nov 19 19:58:20 netcup.silviosiefke.com postfix/smtpd[11593]: NOQUEUE: > > > reject: RCPT from unknown[212.227.15.4]: 450 4.7.25 Client host rejected: > > > cannot find your hostname, [212.227.15.4]; from= > > > to= proto=ESMTP helo= > > > > Is smtpd(8) chrooted? It may be using a different set of nameservers. > > Yes sure I change nothing in master.cf only auth stuff. So maybe this was it. There's no "maybe", check. With a sufficiently recent version of Postfix you can use: $ postconf -F smtp/inet/chroot or $ postconf -Mf smtp/inet otherwise, read master.cf. Then if chrooted (explicitly, or by default), check the resolv.conf file in the chroot jail. Running: # postfix check may report whether some files in the chroot differ from those outside. > Nov 19 20:34:13 netcup.silviosiefke.com postfix/lmtp[16735]: 5180881406: > to=, > relay=netcup.silviosiefke.com[private/dovecot-lmtp], delay=1, > delays=0.91/0.02/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 >J/VlD7VD1F1gQQAAJFpQ3g Saved) Not at all clear why logging from the LMTP delivery agent is relevant. -- Viktor.
Re: milter_default_action=accept not honored
On Tue, Nov 19, 2019 at 11:39:03AM -0800, Jeremiah Rothschild wrote: > > It seems the tempfail is from the milter, not from Postfix. Postfix > > is not in a position to know that the milter is not working as it > > should, the milter is responding "normally". > > That's too bad. I'm surely oversimplifying things but I figured the milter > would do something like pass a non-zero exit along, which postfix could then > use to make a decision on the status. Postfix isn't executing the milter as a subprocess, they communicate over a socket. If the milter returns a 4XX verdict, that's normal milter behaviour. If the milter drops the connection, times out, ... that's a milter failure, and *then* the Postfix milter_default_action kicks in. Your best bet is to invest effort in keeping your milter working properly, optimizing what happens when it is not working is likely the lesser option. -- Viktor.
Re: milter_default_action=accept not honored
On Tue, Nov 19, 2019 at 02:28:34PM -0500, Viktor Dukhovni wrote: > On Tue, Nov 19, 2019 at 11:10:38AM -0800, Jeremiah Rothschild wrote: > > > Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is > > configured with an OpenDKIM milter like so, which works fine under normal > > circumstances: > > > > smtpd_milters = inet:127.0.0.1:8891 > > non_smtpd_milters = $smtpd_milters > > milter_default_action = accept > > The documentation says: > > milter_default_action (default: tempfail) > > The default action when a Milter (mail filter) application is > unavailable or mis-configured. > > and so not when the milter is "working", but returning 4XX > verdicts (are those a problem with the milter, or the milter > e.g. graylisting messages, ...?). Ah, I see. I interpreted that differently. Thanks for clarifying. > > However, when file permissions on the OpenDKIM key pair are wrong, resulting > > in a failed signing, this happens and the message goes back into the queue: > > > > Nov 14 00:00:27 food opendkim[2135]: can't load key from > > /etc/opendkim/keys/private: Permission denied > > Nov 14 00:00:28 food postfix/cleanup[26603]: 4C9D13000A1: milter-reject: > > END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try > > again later; from= to= > > > > This looks like a "tempfail" action to me. Why isn't "accept" being honored? > > It seems the tempfail is from the milter, not from Postfix. Postfix > is not in a position to know that the milter is not working as it > should, the milter is responding "normally". That's too bad. I'm surely oversimplifying things but I figured the milter would do something like pass a non-zero exit along, which postfix could then use to make a decision on the status. Sounds like I'll have to come up with a different solution. Thanks for the help, Viktor, truly appreciated! > -- > Viktor.
Re: Client host rejected
On Tue, 19 Nov 2019 14:20:43 -0500 Viktor Dukhovni wrote: > Why did you stop unbound? Presumably it provides the recursive > service on 127.0.0.1, which is listed below... It work not. That's why so a line direct to nameserver and it work also not. > > Nov 19 19:58:20 netcup.silviosiefke.com postfix/smtpd[11593]: NOQUEUE: > > reject: RCPT from unknown[212.227.15.4]: 450 4.7.25 Client host rejected: > > cannot find your hostname, [212.227.15.4]; from= > > to= proto=ESMTP helo= > > Is smtpd(8) chrooted? It may be using a different set of nameservers. Yes sure I change nothing in master.cf only auth stuff. So maybe this was it. Nov 19 20:34:13 netcup.silviosiefke.com postfix/lmtp[16735]: 5180881406: to=, relay=netcup.silviosiefke.com[private/dovecot-lmtp], delay=1, delays=0.91/0.02/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 J/VlD7VD1F1gQQAAJFpQ3g Saved) So one question I have. Why I must change this on this server, but my master mail server running Debian need this change not. Thank you & Nice day Silvio
Re: milter_default_action=accept not honored
On Tue, Nov 19, 2019 at 11:10:38AM -0800, Jeremiah Rothschild wrote: > Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is > configured with an OpenDKIM milter like so, which works fine under normal > circumstances: > > smtpd_milters = inet:127.0.0.1:8891 > non_smtpd_milters = $smtpd_milters > milter_default_action = accept The documentation says: milter_default_action (default: tempfail) The default action when a Milter (mail filter) application is unavailable or mis-configured. and so not when the milter is "working", but returning 4XX verdicts (are those a problem with the milter, or the milter e.g. graylisting messages, ...?). > However, when file permissions on the OpenDKIM key pair are wrong, resulting > in a failed signing, this happens and the message goes back into the queue: > > Nov 14 00:00:27 food opendkim[2135]: can't load key from > /etc/opendkim/keys/private: Permission denied > Nov 14 00:00:28 food postfix/cleanup[26603]: 4C9D13000A1: milter-reject: > END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try > again later; from= to= > > This looks like a "tempfail" action to me. Why isn't "accept" being honored? It seems the tempfail is from the milter, not from Postfix. Postfix is not in a position to know that the milter is not working as it should, the milter is responding "normally". -- Viktor.
Re: Client host rejected
On Tue, Nov 19, 2019 at 08:13:49PM +0100, siefke_lis...@web.de wrote: > I use unbound. > > I have stop unbound an use the dns direct with resolv.conf. Why did you stop unbound? Presumably it provides the recursive service on 127.0.0.1, which is listed below... > $ cat /etc/resolv.conf > nameserver 46.182.19.48 > nameserver 80.241.218.68 > nameserver 2a03:b0c0:0:1010::e9a:3001 > nameserver 127.0.0.1 > search silviosiefke.com What are all those other nameservers? You should not need anything other than 127.0.0.1. > Nov 19 19:58:20 netcup.silviosiefke.com postfix/smtpd[11593]: NOQUEUE: > reject: RCPT from unknown[212.227.15.4]: 450 4.7.25 Client host rejected: > cannot find your hostname, [212.227.15.4]; from= > to= proto=ESMTP helo= Is smtpd(8) chrooted? It may be using a different set of nameservers. > dig-x 212.227.15.4 > 4.15.227.212.in-addr.arpa. 14109 IN PTR mout.web.de. > > dig mout.web.de > mout.web.de. 1800IN A 212.227.15.4 This should normally result in a "known" name of mout.web.de. -- Viktor.
Re: Client host rejected
On Mon, 18 Nov 2019 21:08:47 +0100 (CET) Bernardo Reino wrote: > $ dig -x 81.91.160.182 > office.denic.de. 3600IN A 81.91.160.182 > > $ dig office.denic.de > office.denic.de. 3508IN A 81.91.160.182 > > which looks OK. See if your resolver also produces the above results. dig -x 81.91.160.182 182.160.91.81.in-addr.arpa. 14400 INPTR office.denic.de. dig office.denic.de office.denic.de.3600IN A 81.91.160.182 I use unbound. I have stop unbound an use the dns direct with resolv.conf. cat /etc/resolv.conf nameserver 46.182.19.48 nameserver 80.241.218.68 nameserver 2a03:b0c0:0:1010::e9a:3001 nameserver 127.0.0.1 search silviosiefke.com Test mail and result. Nov 19 19:58:20 netcup.silviosiefke.com postfix/smtpd[11593]: NOQUEUE: reject: RCPT from unknown[212.227.15.4]: 450 4.7.25 Client host rejected: cannot find your hostname, [212.227.15.4]; from= to= proto=ESMTP helo= dig-x 212.227.15.4 4.15.227.212.in-addr.arpa. 14109 IN PTR mout.web.de. dig mout.web.de mout.web.de.1800IN A 212.227.15.5 mout.web.de.1800IN A 212.227.15.4 mout.web.de.1800IN A 212.227.15.14 mout.web.de.1800IN A 212.227.17.12 mout.web.de.1800IN A 217.72.192.78 mout.web.de.1800IN A 212.227.15.6 mout.web.de.1800IN A 212.227.17.11 mout.web.de.1800IN A 212.227.15.3 Self with direct dns contact it will not work. There is a big mistake. -- Nice Day & Thank you -- Silvio Siefke
milter_default_action=accept not honored
Running postfix-2.10.1-7.0.1 on a fully updated CentOS 7.7 box. Postfix is configured with an OpenDKIM milter like so, which works fine under normal circumstances: smtpd_milters = inet:127.0.0.1:8891 non_smtpd_milters = $smtpd_milters milter_default_action = accept However, when file permissions on the OpenDKIM key pair are wrong, resulting in a failed signing, this happens and the message goes back into the queue: Nov 14 00:00:27 food opendkim[2135]: can't load key from /etc/opendkim/keys/private: Permission denied Nov 14 00:00:28 food postfix/cleanup[26603]: 4C9D13000A1: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from= to= This looks like a "tempfail" action to me. Why isn't "accept" being honored? Thanks in advance! j
Re: Client host rejected
On Tue, Nov 19, 2019 at 09:21:23AM -0500, Bill Cole wrote: > Generally, a mail server should have a caching recursive resolver > running locally: either on the same machine or the same truly local > network. +1, especially for running on the MTA host itself, on the loopback interface, with only 127.0.0.1 listed in /etc/resolv.conf. Make that a DNSSEC validating resolver, and enabled DANE outbound: smtp_dns_support_level = dnssec smtp_tls_security_level = dane If you want to share cache hits with other nearby MTAs, the loopback resolver can forward queries to a shared nearby forwarder. > Between some distributions adopting Unbound and others changing their > standard BIND configs to be simple caching resolvers, the excuses for > not running a local caching recursive resolver on a mail server have > become quite weak. Indeed. -- Viktor.
Re: IP addresses in helo
Matus UHLAR - fantomas wrote: On 18.11.19 18:10, Gregory Heytings wrote: Bill Cole wrote: Rejecting mail is a far better choice than delivering to a 'spam box' since most users never bother looking there for anything. Rejections at least stand some chance of making enough noise on the sender side to get misconfigurations fixed. IMO this is naive. As Kris Deugau wrote in most cases nobody ever looks at that noise, your users will just not receive their email. A common answer to this is that the sender was supposed to get error message. Since the message might be rejected anywhere between sender and recipient, it's usually a must. Yes, they're *supposed to* get an error. But some end users have blackholed postmaster notices, and many end users have trouble making sense of even the best postmaster notices (assuming they don't just treat the error as a reply, and continue their conversation like nothing went wrong - yes, I see this at least a couple times a month). If a message is rejected with an error message that reads, more or less literally: 550 Rejected for spammy content how is the sender supposed to make any kind of sense of what, exactly, they need to do to get their message through? At least with most of the DNSBL rejections, there's usually a link to the list's website with some reference information the sender can take to their provider, and ask "Hey, why are you on this blacklist? It's preventing me from sending mail!". (Not that that helps all the time, due to shared hosting and the unavoidable mystery meat so many desktop/mobile clients stuff into their HTML formatting.) If you want to receive any possible spam and send them to spam folder, it's completely up to you. *nod* "Your system, your rules." Just note that people with too many spams in spam folder may start ignoring it and complain... *sigh* All too true, although not just with "many" spams. I've lost count of the number of customers who have complained about maybe 5-10 messages in the Spam folder over the course of a week: "Why is this spam in the Spam folder?!?" "Er... because... it's not in your Inbox?" -kgd
Re: how to setup storage for two different MX in different locations
On 19 Nov 2019, at 1:04, Merrick wrote: Hello, We plan to setup two postfix as MX servers. One is in west location, such as CA state. Another is in east location, such as NYC. The usefulness of such an architecture in modern times is marginal. If the "4th nine" (or maybe 5th) is worth doubling your hard costs and possibly doing worse to your support costs, go for it. As an example, one 2-node mail cluster I manage has had a bit less than 2 hours of downtime per node in the past year, all of it for scheduled updates, so the whole system has never been unavailable but if it was a single node it would only have been out for 2 hours of our own choosing: 99.977% available even without a "planned downtime" exemption. The second node takes us to 100% but at a significant cost of technical and human resources. The question is, how to make storage shared by two MX servers? The messages should be stored in one place, such as webmail/IMAP could read all messages directly from this location. This is not something Postfix would handle. When acting as a MX server, Postfix accepts messages and (except in cases of extreme load or malfunction) passes them in sub-second time to Something Else that manages the storage of and access to delivered mail. Sometimes that's just files on disk that can be accessed by traditional mail tools (mail/mailx, mutt, etc.) or by IMAP /POP/webmail servers. Sometimes it is an independent delivery agent that is handed messages over LMTP or a pipe or more arcane mechanisms (see master.cf's often-commented lines for delivery mechanisms Postfix can do.) What you are looking for is either an independent IMAP server OR synchronized IMAP servers. Typically webmail accesses delivered mail via IMAP. https://wiki.dovecot.org/Replication explains one way to synch 2 or more IMAP servers, using Dovecot. Cyrus IMAP also has a mechanism for it. If you are committed to truly singular storage, a single IMAP server apart from the MX servers would suffice, but I don't think that's a sensible architecture because it makes the solitary IMAP server a single point of failure. Replication allows each node to stand on its own if the other(s) fail, and avoids the problems of treating distant storage as local. It is also possible to use a commercial mail clustering solution, such as CommuniGate Pro. I hear Microsoft has some sort of supposed multi-node mail system as well... One might expect a commercial solution to be a simpler tool to support but one might be surprised. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: Client host rejected
On 18 Nov 2019, at 15:38, Gregory Heytings wrote: replace the contents of /etc/resolv.conf by: nameserver 8.8.8.8 nameserver 8.8.4.4 your problem will likely be solved. Note that doing this (using Google's public DNS service) will kill the effectiveness of DNSBLs and of anti-spam tools like SpamAssassin that use DNSBLs for scoring. The most common effectiveness problem people report to us on the Apache SpamAssassin project is the de facto non-use of the many DNSBLs (including URIBLs and RHSBLs) SA normally uses, resulting from the use of shared public and ISP DNS resolvers. Generally, a mail server should have a caching recursive resolver running locally: either on the same machine or the same truly local network. If you have to cross a router and/or a WAN link of some sort for every DNS lookup, performance will suffer (in addition to the issue with DNSBLs.) If you use one of the shared resolvers that hijack NXDOMAIN results or otherwise bowdlerize DNS to suit web browsing, security is at risk. Between some distributions adopting Unbound and others changing their standard BIND configs to be simple caching resolvers, the excuses for not running a local caching recursive resolver on a mail server have become quite weak. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: how to setup storage for two different MX in different locations
My purpose is to setup two MX servers in different locations for high availability. I'm not sure I understand your question, but I guess that what you want is a secondary MX in case the primary MX becomes unavailable for some reason (power outage, server crash, whatever). If this is indeed what you want to do, you could check http://www.postfix.org/STANDARD_CONFIGURATION_README.html#backup , or https://www.howtoforge.com/postfix_backup_mx , or any other howto. Gregory
Re: may we suggest ICANN not run that many new tlds?
Thanks for the info Viktor. On 2019/11/19 6:48 下午, Viktor Dukhovni wrote: On Nov 19, 2019, at 5:31 AM, Viktor Dukhovni wrote: If you are considering blocking, try to look at the SpamHaus (or similar) TLD worst-offender list, and block just a few of those and review the list from time to time. You may also find useful (a bit dated, but perhaps still relevant): Statistical Analysis of DNS Abuse in gTLDs Final Report https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf I must admit that I don't have the cycles or motivation to wade through it, but perhaps someone on this list does, and might then comment on its relevance to the discussion in this thread.
Re: may we suggest ICANN not run that many new tlds?
> On Nov 19, 2019, at 5:31 AM, Viktor Dukhovni > wrote: > > If you are considering blocking, try to look at the SpamHaus > (or similar) TLD worst-offender list, and block just a few of those and review > the list from time to time. You may also find useful (a bit dated, but perhaps still relevant): Statistical Analysis of DNS Abuse in gTLDs Final Report https://www.icann.org/en/system/files/files/sadag-final-09aug17-en.pdf I must admit that I don't have the cycles or motivation to wade through it, but perhaps someone on this list does, and might then comment on its relevance to the discussion in this thread. -- Viktor.
Re: may we suggest ICANN not run that many new tlds?
On Tue, Nov 19, 2019 at 05:58:02PM +0800, Merrick wrote: > May we suggest ICANN not open a new TLD anymore? More gTLDs are already planned, and will likely be added soon. Many are "brand" TLDs, and are just "hoarded" as trademarks, or very lightly used exclusively by the trademark holder, so aren't a source of any abuse. The ones that are "open" for registration by the public, vary substantially in their abuse affinity. I don't recommend blocking any outright, but for some smaller systems with a stable set of correspondents, such a choice can be workable. Below, I list most of the current gTLDs along with the number of (directly) delegated sub-domains (NS RRsets in the TLD zone). For example, while .goog has only 121 direct delegations, there are at least 15k 3LDs under .cloud.goog. This may be useful in assessing how many potential domains you are willing to risk blocking, but if you are considering blocking, try to look at the SpamHaus (or similar) TLD worst-offender list, and block just a few of those and review the list from time to time. -- Viktor. 142751684 com 13190953 net 9991530 org 4517141 info 3602467 icu 3286176 top 2397899 xyz 1703497 site 1535542 biz 1229852 online 1185048 club 1158279 vip 842395 wang 625019 shop 618558 live 586533 work 517212 fun 483641 app 392482 space 382670 mobi 360304 gdn 322869 website 302909 store 291899 pro 258667 tech 234295 ltd 209636 buzz 189635 life 183433 blog 178732 cloud 175597 xn--ses554g 170136 dev 154471 world 123574 name 114573 host 107532 cat 101057 rocks 99506 design 99147 tel 98713 tokyo 92830 xxx 89582 email 84715 today 78416 win 78106 solutions 70825 one 69503 link 68703 xin 68332 agency 66191 nyc 65407 art 64032 company 62596 group 61165 fit 58150 services 58087 ovh 57883 news 54156 guru 53335 best 50976 studio 49768 network 48939 berlin 48616 global 48456 media 47158 photography 45923 london 44142 jobs 41828 digital 40145 center 37764 xn--55qx5d 37470 ink 37374 men 36437 realtor 36145 ooo 34482 press 34169 business 33825 expert 33729 click 32717 xn--kput3i 32710 page 32120 academy 31787 ninja 31224 technology 29951 bayern 29860 tips 29734 love 29138 systems 29015 city 28311 xn--3ds443g 28226 red 27383 bid 27089 xn--p1acf 27034 koeln 26650 consulting 26633 xn--czr694b 26314 zone 26163 team 25851 amsterdam 25289 xn--io0a7i 25192 international 25153 events 24745 pub 24512 church 24004 education 23785 social 23782 loan 23485 support 22933 monster 22565 care 22554 hamburg 22005 marketing 21872 africa 21738 wedding 21572 bet 21422 photos 21167 paris 20650 xn--czru2d 20642 market 20536 family 20456 video 20208 gmbh 20189 travel 20081 works 19766 party 19359 realestate 19203 house 19203 training 19168 games 19064 cool 18861 coffee 18484 moscow 18417 sale 18035 reviews 18008 swiss 17893 wiki 17767 gallery 17756 run 17575 photo 17228 xn--6qq986b3xl 16712 ren 16635 earth 16615 farm 16459 casa 16325 guide 16282 uno 16225 wtf 16016 land 16002 trade 15989 bio 15804 bike 15804 software 15774 coach 15503 plus 15488 directory 15365 nrw 15347 cafe 15341 wien 15283 immo 14883 foundation 14835 wine 14762 community 14569 blue 14564 fund 14414 capital 14263 band 14168 kiwi 14104 vegas 13965 fyi 13904 beer 13864 school 13776 chat 13622 ventures 13609 boston 13550 science 13460 properties 13381 cash 13374 frl 13358 help 13347 legal 13261 xn--80adxhks 13133 review 13013 wales 12890 tools 12670 kim 12478 institute 12382 date 12293 homes 12166 dog 12151 direct 11950 health 11836 energy 11732 rentals 11730 money 11728 stream 11705 style 11420 lawyer 11343 scot 11232 law 11167 clothing 11073 tours 10929 management 10878 exchange 10863 show 10637 yoga 10557 fitness 10440 codes 10367 porn 10260 cologne 10169 llc 9934 pet 9883 golf 9770 ruhr 9659 eus 9582 watch 9521 estate 9517 istanbul 9186 ist 9034 miami 9028 sport 8984 healthcare 8765 finance 8759 fashion 8741 gold 8649 boutique 8618 bzh 85
Re: may we suggest ICANN not run that many new tlds?
> On 19 Nov 2019, at 09:58, Merrick wrote: > > in the coming future, everything is a TLD, the cat, the dog, the pig, the > rose, the coffee, the wine, the bike ... > that would be terrible for domain based validation. > we have already too many TLDs today. > may we suggest ICANN not open a new TLD anymore? The ICANN policy process is open to all. Knock yourself out. :-)
may we suggest ICANN not run that many new tlds?
in the coming future, everything is a TLD, the cat, the dog, the pig, the rose, the coffee, the wine, the bike ... that would be terrible for domain based validation. we have already too many TLDs today. may we suggest ICANN not open a new TLD anymore? regards.
Re: Relay attempt questions
This should really be fixed. SMTPD_ACCESS_README (five times), ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README specify that "reject_unauth_destination is not needed here [= in smtpd_recipient_restrictions] if the mail relay policy is specified under smtpd_relay_restrictions". Sorry: it's SMTPD_ACCESS_README, SMTPD_POLICY_README (four times), ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README. Gregory
Re: how to setup storage for two different MX in different locations
Dominic Raferd wrote: If you are a small organisation you could consider relaying into Gmail. Or, easiest of all, use G Suite (which is free for non-profits). I know there is gsuite exists, :) Also a lot of cheap providers like MXroute on the world. We just want to make an email service for ourselves, about 100 members using this service. regards.
relay based on sender and destination
Hi, I have a mail server relaying for different domains and using a transport map to deliver local domains. Now I need the following: * Mail from @internal1.com and to @external1.com to be relayed through relay.provider.com * the rest of mails, to be deliver or relayed according to transport_maps I have found the sender_dependent_relayhost_maps but with this I can only check the sender but not the destination. Any idea? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 86337
Re: Relay attempt questions
Nick wrote: But postconf(5) says "smtpd_recipient_restrictions ... applies in the context of a client RCPT TO command, after smtpd_relay_restrictions." If smtpd_relay_restrictions applies first, why didn't its reject_unauth_destination cause rejection before anything in smtpd_recipient_restrictions was consulted? Sorry, I did not see that part of your question. Viktor Dukhovni wrote: Sadly, the implementation changed without a documentation update. Perhaps there were competing interests dependent on the evaluation order, and issuing better backwards compatibility warnings prevailed? I agree that the documented order seems more optimal otherwise. This should really be fixed. SMTPD_ACCESS_README (five times), ADDRESS_VERIFICATION_README and RESTRICTION_CLASS_README specify that "reject_unauth_destination is not needed here [= in smtpd_recipient_restrictions] if the mail relay policy is specified under smtpd_relay_restrictions". Gregory
Re: how to setup storage for two different MX in different locations
On Tue, 19 Nov 2019 at 08:56, Merrick wrote: > My purpose is to setup two MX servers in different locations for high > availability. > But I am not sure how the two MX servers handle message storage. > If you are a small organisation you could consider relaying into Gmail. Or, easiest of all, use G Suite (which is free for non-profits).
Re: how to setup storage for two different MX in different locations
Bernardo Reino wrote: Perhaps you first need to think/consider what you actually want. I cannot recommend you to install an IMAP server in Dallas or any other location. Maybe you don't even need or want IMAP but want to deliver mail to a local mailbox, or relay to another server, etc. If this is a hobby project or some kind of theoretical question or experiment, then OK, but if this is work then I'm not sure this is the right place (and maybe -- meaning no offense -- you're not the right person). You could read about virtual_transport in postfix so you know which options you have when delivering. I use dovecot (IMAP server), so I have virtual_transport = lmtp:unix:private/dovecot-lmtp If you install dovecot somewhere you could deliver received mails to it, but not using a unix socket (as MX and IMAP would run on different servers), but using something like lmtp:[IP_of_IMAP_server]:port Thanks for the helps. My purpose is to setup two MX servers in different locations for high availability. But I am not sure how the two MX servers handle message storage. regards.
Re: how to setup storage for two different MX in different locations
On Tue, 19 Nov 2019, Merrick wrote: Bernardo Reino wrote: The messages should be stored in one place, such as webmail/IMAP could read all messages directly from this location. Use a single IMAP server. Have both mail servers deliver the messages to the single IMAP server. Do you mean I setup a single IMAP server in middle location (such as Dallas) then both MX servers deliver messages to the IMAP? Perhaps you first need to think/consider what you actually want. I cannot recommend you to install an IMAP server in Dallas or any other location. Maybe you don't even need or want IMAP but want to deliver mail to a local mailbox, or relay to another server, etc. If this is a hobby project or some kind of theoretical question or experiment, then OK, but if this is work then I'm not sure this is the right place (and maybe -- meaning no offense -- you're not the right person). You could read about virtual_transport in postfix so you know which options you have when delivering. I use dovecot (IMAP server), so I have virtual_transport = lmtp:unix:private/dovecot-lmtp If you install dovecot somewhere you could deliver received mails to it, but not using a unix socket (as MX and IMAP would run on different servers), but using something like lmtp:[IP_of_IMAP_server]:port Good luck!
Re: Relay attempt questions
On 2019-11-19 08:37 GMT, Viktor Dukhovni wrote: > Sadly, the implementation changed without a documentation update. I see. > > If possible, when my server receives an unwanted relay attempt I would > > prefer it did not make pointless queries to third parties. Can that > > be accomplished? > > You can add "reject_unauth_destination" (possibly preceded by > permit_mynetworks) also near the top of the recipient restrictions. I'll try that, thanks. -- Nick
Re: Relay attempt questions
On Tue, Nov 19, 2019 at 08:21:07AM +, Nick wrote:
> > Because Postfix evaluates smtpd_relay_restrictions *after* it checks
> > smtpd_recipient_restrictions.
>
> postconf(5) says the opposite.
>
> smtpd_recipient_restrictions (default: see postconf -d output)
>Optional restrictions that the Postfix SMTP server applies in the
>context of a client RCPT TO command, after smtpd_relay_restrictions.
>
> smtpd_relay_restrictions (default: permit_mynetworks,
>permit_sasl_authenticated, defer_unauth_destination)
>Access restrictions for mail relay control that the Postfix SMTP
>server applies in the context of the RCPT TO command, before
>smtpd_recipient_restrictions.
Sadly, the implementation changed without a documentation update. Perhaps
there were competing interests dependent on the evaluation order, and issuing
better backwards compatibility warnings prevailed? I agree that the documented
order seems more optimal otherwise.
Date: Sat Jan 6 00:00:00 2018 -0500
postfix-3.3-20180106
diff --git a/postfix/src/smtpd/smtpd_check.c
b/postfix/src/smtpd/smtpd_check.c
index e1615223..94e8c018 100644
--- a/postfix/src/smtpd/smtpd_check.c
+++ b/postfix/src/smtpd/smtpd_check.c
@@ -4958,15 +4962,31 @@ char *smtpd_check_rcpt(SMTPD_STATE *state, char
*recipient)
* Apply restrictions in the order as specified. We allow relay
* restrictions to be empty, for sites that require backwards
* compatibility.
+ *
+ * If compatibility_level < 1 and smtpd_relay_restrictions is left at
its
+ * default value, find out if the new smtpd_relay_restrictions default
+ * value would block the request, without logging REJECT messages.
+ * Approach: evaluate fake relay restrictions (permit_mynetworks,
+ * permit_sasl_authenticated, permit_auth_destination) and log a
warning
+ * if the result is DUNNO instead of OK, i.e. a
reject_unauth_destinatin
+ * at the end would have blocked the request.
*/
SMTPD_CHECK_RESET();
-restrctions[0] = relay_restrctions;
-restrctions[1] = rcpt_restrctions;
+restrctions[0] = rcpt_restrctions;
+restrctions[1] = warn_compat_break_relay_restrictions ?
+ fake_relay_restrctions : relay_restrctions;
for (n = 0; n < 2; n++) {
status = setjmp(smtpd_check_buf);
if (status == 0 && restrctions[n]->argc)
status = generic_checks(state, restrctions[n],
recipient, SMTPD_NAME_RECIPIENT, CHECK_RECIP_ACL);
+ if (n == 1 && warn_compat_break_relay_restrictions
+ && status == SMTPD_CHECK_DUNNO) {
+ msg_info("using backwards-compatible default setting \""
+VAR_RELAY_CHECKS " = (empty)\" to avoid \"Relay "
+"access denied\" error for recipient \"%s\" from "
+"client \"%s\"", state->recipient, state->namaddr);
+ }
if (status == SMTPD_CHECK_REJECT)
break;
}
> If possible, when my server receives an unwanted relay attempt I would
> prefer it did not make pointless queries to third parties. Can that
> be accomplished?
You can add "reject_unauth_destination" (possibly preceded by
permit_mynetworks) also near the top of the recipient restrictions.
--
Viktor.
Re: Relay attempt questions
On 2019-11-19 05:59 GMT, Viktor Dukhovni wrote: > On Mon, Nov 18, 2019 at 09:40:24PM +, Nick wrote: > > > Why did reject_unauth_destination (line 11) only take effect after the > > probe (line 8, if that's what it is) and after check_policy_service > > (line 10)? > > Because Postfix evaluates smtpd_relay_restrictions *after* it checks > smtpd_recipient_restrictions. postconf(5) says the opposite. smtpd_recipient_restrictions (default: see postconf -d output) Optional restrictions that the Postfix SMTP server applies in the context of a client RCPT TO command, after smtpd_relay_restrictions. smtpd_relay_restrictions (default: permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination) Access restrictions for mail relay control that the Postfix SMTP server applies in the context of the RCPT TO command, before smtpd_recipient_restrictions. > > Did smtpd_relay_restrictions apply only after > > smtpd_recipient_restrictions? > > Yes. If possible, when my server receives an unwanted relay attempt I would prefer it did not make pointless queries to third parties. Can that be accomplished? -- Nick
