Re: PCRE2 error
Trying to test latest postfix 3.7.0 with PCRE2 I have found a problem in building documentation. According to PCRE_README (http://www.postfix.org/PCRE_README.html), pcre2-config is used: "AUXLIBS_PCRE=`pcre2-config --libs`" But "pcre2-config" doesn't have "--libs" as available argument. # pcre2-config --help Usage: pcre2-config [--prefix] [--exec-prefix] [--version] [--libs8] [--libs-posix] [--libs32] [--libs16]? [--cflags] [--cflags-posix] Confirmed in debian manpage and source code https://manpages.debian.org/stretch/libpcre2-dev/pcre2-config.1.en.html https://github.com/PhilipHazel/pcre2/blob/master/pcre2-config.in Maybe: $ pcre2-config --libs8 -L/usr/local/lib -Wl,-R/usr/local/lib -lpcre2-8 (on my system, YMMV) But Postfix "make makefiles" already does that for you. Wietse `pcre2-config --libs8` worked for me. I have libs in non-standard locations, "make makefiles" doesn't work for me. Regards, Carlos Velasco
Re: Need help with smtp_tls_policy_maps settings.
On 18/2/22 00:13, Noel Jones wrote: The fix is to tell your postfix to not offer STARTTLS in the EHLO response, using smtpd_discard_ehlo_keyword_address_maps http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps something like: # main.cf smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/discard_ehlo_keyword_map.cidr # /etc/postfix/discard_ehlo_keyword_map.cidr 216.109.104.12 starttls -- Noel Jones Thank you very much for the reply and for the advice. I will try it out and report back. P.V.Anthony
Re: Need help with smtp_tls_policy_maps settings.
On 18/2/22 00:13, Noel Jones wrote: The fix is to tell your postfix to not offer STARTTLS in the EHLO response, using smtpd_discard_ehlo_keyword_address_maps http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps something like: # main.cf smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/discard_ehlo_keyword_map.cidr # /etc/postfix/discard_ehlo_keyword_map.cidr 216.109.104.12 starttls -- Noel Jones I am reporting back to say it works well. One more question. In the maps file is it possible to use a hostname instead of an ip address? P.V.Anthony
Re: PCRE2 error
Carlos Velasco: > `pcre2-config --libs8` worked for me. > I have libs in non-standard locations, "make makefiles" doesn't work for me. Surprise, "make makefiles" uses "pcre2-config --libs8". and "pcre2-config --cflags". Wietse
Re: Need help with smtp_tls_policy_maps settings.
P.V.Anthony: > On 18/2/22 00:13, Noel Jones wrote: > > > The fix is to tell your postfix to not offer STARTTLS in the EHLO > > response, using smtpd_discard_ehlo_keyword_address_maps > > http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps > > > > > > > > something like: > > > > # main.cf > > smtpd_discard_ehlo_keyword_address_maps = > > ? cidr:/etc/postfix/discard_ehlo_keyword_map.cidr > > > > # /etc/postfix/discard_ehlo_keyword_map.cidr > > 216.109.104.12? starttls > > > > ? -- Noel Jones > > I am reporting back to say it works well. > > One more question. In the maps file is it possible to use a hostname > instead of an ip address? No, we want this to be RELIABLE. Specify a net/masl form to exclude a rangeof IP addresses. Wietse
Re: Need help with smtp_tls_policy_maps settings.
> On Feb 18, 2022, at 7:02 AM, P.V.Anthony wrote: > I am reporting back to say it works well. > > One more question. In the maps file is it possible to use a hostname instead > of an ip address? > > P.V.Anthony > > No. The docs say the table is not searched by hostname — Noel Jones
Re: canonical_maps vs. *_recipient_maps
On 2/17/2022 6:47 AM, Matus UHLAR - fantomas wrote: last week's discussions showed that using *canonical_maps to e.g. map to different domains can result into taking all addresses as existing: https://marc.info/?l=postfix-users&m=164459031004167&w=2 https://marc.info/?l=postfix-users&m=164459739009282&w=2 I expected the canonical_maps to be resolved and address then checked in local_recipient_maps or relay_recipient_maps, but apparently in this case the *_recipient_maps are not checked. I was trying to understand how this works, but have not found any description of this process in the docs. Can someone explain this, point me to the docs or perhaps proper web search? On 17.02.22 10:56, Noel Jones wrote: This could be better documented, but basically when receiving mail postfix does not do a full expansion of the recipient address. So the first time an address is accepted by canonical, virtual, local, relay, ... whatever maap, the address is considered as valid. Consequently, avoid using wildcard rewrites for recipient addresses. This is a result of distributed nature of postfix. Incoming mail recipients are checked by cleanup(8) and trivial-rewrite(8). To do a full expansion, the functionality of the various delivery agents would also need to be folded into those programs, or a new recipient expansion checker program would need to be bolted on. This is not an easy problem to solve without causing other problems. This is not an exhaustive answer, but should be close enough. This subject has been discussed in the archives several times, but might be hard to track down. This explains much, thanks. I'm still curious when it's decided if the address is local or relayed, to match in respective _recipient_maps. I guess that this is skipped in case the address matches canonical_maps. -- 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. Chernobyl was an Windows 95 beta test site.
Re: Need help with smtp_tls_policy_maps settings.
On 18/2/22 22:05, Wietse Venema wrote: One more question. In the maps file is it possible to use a hostname instead of an ip address? No, we want this to be RELIABLE. Specify a net/masl form to exclude a rangeof IP addresses. Thank you very much for the clarifications. I will learn more about specifying net/masl form. Once again thank you for helping. P.V.Anthony
Re: canonical_maps vs. *_recipient_maps
Matus UHLAR - fantomas: > On 17.02.22 10:56, Noel Jones wrote: > >This could be better documented, but basically when receiving mail > >postfix does not do a full expansion of the recipient address. So the > >first time an address is accepted by canonical, virtual, local, relay, > >... whatever maap, the address is considered as valid. Consequently, > >avoid using wildcard rewrites for recipient addresses. > > > >This is a result of distributed nature of postfix. Incoming mail > >recipients are checked by cleanup(8) and trivial-rewrite(8). To do a > >full expansion, the functionality of the various delivery agents would > >also need to be folded into those programs, or a new recipient > >expansion checker program would need to be bolted on. This is not an > >easy problem to solve without causing other problems. > > > >This is not an exhaustive answer, but should be close enough. This > >subject has been discussed in the archives several times, but might be > >hard to track down. > > This explains much, thanks. > > I'm still curious when it's decided if the address is local or relayed, to > match in respective _recipient_maps. > > I guess that this is skipped in case the address matches canonical_maps. Indeed. The result of table lookup is not validated in the SMTP daemon. Some tables can return multiple values (virtual_alias_maps, alias_maps), and lookups are recursive. Validating those expansions in the SMTP daemon would be tricky. Fortunately, there is a way to validate address expansions exactly, and that is with reject_unverified_recipient. The result is cached (under both the RCPT TO address and the result of map lookup) so reject_unverified_recipient is usually fast. Starting to wonder if reject_unverified_recipient should be given more publicity. Wietse
Re: Need help with smtp_tls_policy_maps settings.
P.V.Anthony: > On 18/2/22 22:05, Wietse Venema wrote: > > >> One more question. In the maps file is it possible to use a hostname > >> instead of an ip address? > > > > No, we want this to be RELIABLE. Specify a net/masl form > > to exclude a rangeof IP addresses. > > Thank you very much for the clarifications. I will learn more about > specifying net/masl form. I meant net/mask. For examples, see https://www.postfix.org/cidr_table.5.html Wietse > Once again thank you for helping. > > P.V.Anthony > > >
Re: canonical_maps vs. *_recipient_maps
Dnia 18.02.2022 o godz. 11:17:13 Wietse Venema pisze: > Starting to wonder if reject_unverified_recipient should be given > more publicity. Definitely should. I always thought of reject_unverified_recipient only in context of a front-end server relaying mail to the final server, which is a pretty rare case for me (I usually work with single-server setups). I did not think that it can be used in such context as rewriting by canonical maps. -- 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."
Re: canonical_maps vs. *_recipient_maps
Jaroslaw Rafa: > Dnia 18.02.2022 o godz. 11:17:13 Wietse Venema pisze: > > Starting to wonder if reject_unverified_recipient should be given > > more publicity. > > Definitely should. I always thought of reject_unverified_recipient only in > context of a front-end server relaying mail to the final server, which is a > pretty rare case for me (I usually work with single-server setups). I did > not think that it can be used in such context as rewriting by canonical > maps. Upon closer reading, address verification has limits some of which are intentional. Address verification will validate addresses that result from canonical mappings and of 1-to-1 virtual aliases. Address verification will not validate addresses that result from the expansion of 1-to-many virtual aliases. It will just report that the address before alias expansion is valid. It does not validate 1-to-many expansions because that would result in an explosive behavior, because the result would ambiguous if some addresses in the expansion result are valid and some not, and because it could be undesirable to reveal what 1-to-many aliases expand into. Address verification will also not validate addresses that result from local aliasing/forwarding with alias_maps or ~/.forward files, because I was too lazy to write code that determines if these are 1-to-1 or 1-to-many, but also because it might reveal too much information. It will just report that the address before alias expansion or forwarding is valid. Wietse
