Re: Postfix stable release 3.5.0
Viktor Dukhovni: > On Mon, Mar 16, 2020 at 10:16:13AM -0400, Wietse Venema wrote: > > > [An on-line version of this announcement will be available at > > http://www.postfix.org/announcements/postfix-3.5.0.html] > > > > Postfix stable release 3.5.0 is available. Support has ended for > > legacy release Postfix 3.1. > > Congratulations and thanks for the continued support! > > This is roughly (I am surely missing some early snapshots) number 1145 > in a linear sequence of public snapshots starting with beta-19990122 (I > don't have a copy of anything earlier). > > Including stable release updates and non-prod snapshots the total > tarball count rises to 1653. A daunting volume of work over more than > 21 years. Much appreciated. You're welcome, and of course thanks for your contributions over the years. To get some iedea of the number of tarballs prior to the public beta: 1 142562 May 7 1997 19970220.tar.gz (23 years ago) ... 129 394329 Jul 10 2000 19980107-alpha.tar.gz (closed alpha) ... 258 21619 Dec 8 1998 postfix-contrib-beta.tar.gz 259 591523 May 7 1999 postfix-beta-19981209.tar.gz The last two are the split Postfix beta, with separate tarballs for contributed code and IBM-original code. I guess this is a version that Wietse
Re: Postfix stable release 3.5.0
On March 16, 2020 10:49:26 PM UTC, Viktor Dukhovni wrote: >On Mon, Mar 16, 2020 at 10:16:13AM -0400, Wietse Venema wrote: > >> [An on-line version of this announcement will be available at >> http://www.postfix.org/announcements/postfix-3.5.0.html] >> >> Postfix stable release 3.5.0 is available. Support has ended for >> legacy release Postfix 3.1. > >Congratulations and thanks for the continued support! > >This is roughly (I am surely missing some early snapshots) number 1145 >in a linear sequence of public snapshots starting with beta-19990122 (I >don't have a copy of anything earlier). > >Including stable release updates and non-prod snapshots the total >tarball count rises to 1653. A daunting volume of work over more than >21 years. Much appreciated. Absolutely. I've uploaded 3.5.0 to Debian Unstable and it's built on all 19 Linux architectures we build for. That seems like a lot to me. Cross-platform support doesn't happen by accident. I'd also like to take special note of the long support for existing releases. Because of the consistently high quality of postfix updates, we do post-Debian release updates for our stable users. We've been able to provide them with a continuously improving experience through delivering these updates (a Debian oldstable user can install 3.1.15 from our repositories and 3.4.10 should be available for stable in a few days). I really appreciate your continuing commitment to quality. Scott K
Re: Postfix stable release 3.5.0
On Mon, Mar 16, 2020 at 10:16:13AM -0400, Wietse Venema wrote: > [An on-line version of this announcement will be available at > http://www.postfix.org/announcements/postfix-3.5.0.html] > > Postfix stable release 3.5.0 is available. Support has ended for > legacy release Postfix 3.1. Congratulations and thanks for the continued support! This is roughly (I am surely missing some early snapshots) number 1145 in a linear sequence of public snapshots starting with beta-19990122 (I don't have a copy of anything earlier). Including stable release updates and non-prod snapshots the total tarball count rises to 1653. A daunting volume of work over more than 21 years. Much appreciated. -- Viktor.
Re: gmail.com is Unsecure ssl cert ?
On Mon, Mar 16, 2020 at 02:45:55PM -0400, Wietse Venema wrote: > > Looks valid to me, unless I'm missing something, or is posttls-finger > > missing something? > > Postfix code will enforce the security level that you specify. > If you want Postfix to trust the certificate, then specify that. > > posttlls-finger -l ... > > Ditto in main.cf and smtp_tls_policy_maps. Everything is as expected. Postfix defaults to opportunistic TLS, which does not care about the peer certificate (does not attempt to verify it), and *also* by default has an empty trust store. If you want to trust some list of random third-parties, you have to explicitly turn that on. And if you want "Verified", rather than "trusted" you often have to also specify appropriate name matching: $ posttls-finger -c -l secure -L summary -F /etc/ssl/cert.pem gmail.com mx.google.com posttls-finger: Verified TLS connection established to gmail-smtp-in.l.google.com[172.217.197.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 -- Viktor.
Re: gmail.com is Unsecure ssl cert ?
Peter: > On 17/03/20 2:08 am, Viktor Dukhovni wrote: > > For opportunistic TLS, unvalidated certificates are not a failure. > > There is no problem, everything is working as expected: > > > >$ posttls-finger -l may -c -L summary gmail.com > >posttls-finger: Untrusted TLS connection established to > > gmail-smtp-in.l.google.com[2607:f8b0:400d:c0f::1a]:25: TLSv1.3 with cipher > > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature > > RSA-PSS (2048 bits) server-digest SHA256 > > $ openssl s_client -connect "gmail-smtp-in.l.google.com:25" -servername > "gmail-smtp-in.l.google.com" -starttls smtp <<<"QUIT" | tee >(openssl > x509 -noout -text); sleep 0.1 > ... > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mx.google.com > i:/C=US/O=Google Trust Services/CN=GTS CA 1O1 > 1 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1 > i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign > ... > Not After : May 19 20:43:24 2020 GMT > ... > X509v3 Subject Alternative Name: > ...DNS:gmail-smtp-in.l.google.com,... > ... > > Looks valid to me, unless I'm missing something, or is posttls-finger > missing something? Postfix code will enforce the security level that you specify. If you want Postfix to trust the certificate, then specify that. posttlls-finger -l ... Ditto in main.cf and smtp_tls_policy_maps. Wietse
Re: gmail.com is Unsecure ssl cert ?
On 17/03/20 2:08 am, Viktor Dukhovni wrote: For opportunistic TLS, unvalidated certificates are not a failure. There is no problem, everything is working as expected: $ posttls-finger -l may -c -L summary gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2607:f8b0:400d:c0f::1a]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 $ openssl s_client -connect "gmail-smtp-in.l.google.com:25" -servername "gmail-smtp-in.l.google.com" -starttls smtp <<<"QUIT" | tee >(openssl x509 -noout -text); sleep 0.1 ... Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mx.google.com i:/C=US/O=Google Trust Services/CN=GTS CA 1O1 1 s:/C=US/O=Google Trust Services/CN=GTS CA 1O1 i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign ... Not After : May 19 20:43:24 2020 GMT ... X509v3 Subject Alternative Name: ...DNS:gmail-smtp-in.l.google.com,... ... Looks valid to me, unless I'm missing something, or is posttls-finger missing something? Peter
Re: how to reroute messages in queue
On Mon, March 16, 2020 13:37, Wietse Venema wrote: > > Is that a content filter setting? You may be able to work around > that with "postsuper -r AD79220201". That command moves the message > to the maildrop queue. From there on, Postfix ignores the content > filter record, and handles the message as if it is submnitted with > /usr/sbin/sendmail. If you have enabled content inspection for the > pickup daemon, then the message will get a new content_filter record > with the correct IP address. > > Wietse > Thank you very much. That worked perfectly for Q in $(mailq | grep Mar | cut -f1 -d" "); do postsuper -r $Q; done -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: how to reroute messages in queue
James B. Byrne: > postfix v-3.4.9 on FreeBSD-12. > > We run our postfix mail exchangers in FreeBSD jails. Following the conversion > of one of these from ezjail to iocage we encountered a problem with amavisd > and > opendkim resulting from the different manner in which iocage handles the > loopback address. > > These issues have been resolved. However, there are 20 messages stuck in the > delivery queue all having the same reason: > > AD79220201 1501819 Mon Mar 16 08:34:42 byrn...@harte-lyne.ca > (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: > Connection refused) Is that a content filter setting? You may be able to work around that with "postsuper -r AD79220201". That command moves the message to the maildrop queue. From there on, Postfix ignores the content filter record, and handles the message as if it is submnitted with /usr/sbin/sendmail. If you have enabled content inspection for the pickup daemon, then the message will get a new content_filter record with the correct IP address. Wietse > Is there any way to change the queued messages target address from 127.0.0.1 > to > the one assigned by iocage, in this case 127.0.32.1? > > Sincerely, > > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > >
how to reroute messages in queue
postfix v-3.4.9 on FreeBSD-12. We run our postfix mail exchangers in FreeBSD jails. Following the conversion of one of these from ezjail to iocage we encountered a problem with amavisd and opendkim resulting from the different manner in which iocage handles the loopback address. These issues have been resolved. However, there are 20 messages stuck in the delivery queue all having the same reason: AD79220201 1501819 Mon Mar 16 08:34:42 byrn...@harte-lyne.ca (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused) Is there any way to change the queued messages target address from 127.0.0.1 to the one assigned by iocage, in this case 127.0.32.1? Sincerely, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Postfix stable release 3.5.0
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.5.0.html] Postfix stable release 3.5.0 is available. Support has ended for legacy release Postfix 3.1. The main changes are below. See the RELEASE_NOTES file for further details. * Support for the haproxy v2 protocol. The Postfix implementation supports TCP over IPv4 and IPv6, as well as non-proxied connections; the latter are typically used for heartbeat tests. * Support to force-expire email messages. This introduces new postsuper(1) command-line options to request expiration, and additional information in mailq(1) or postqueue(1) output. * The Postfix SMTP and LMTP client support a list of nexthop destinations separated by comma or whitespace. These destinations will be tried in the specified order. Examples: /etc/postfix/main.cf: relayhost = foo.example, bar.example default_transport = smtp:foo.example, bar.example Incompatible changes: * Logging: Postfix daemon processes now log the from= and to= addresses in external (quoted) form in non-debug logging (info, warning, etc.). This means that when an address localpart contains spaces or other special characters, the localpart will be quoted, for example: from=<"name with spaces"@example.com> Specify "info_log_address_format = internal" for backwards compatibility. * Postfix now normalizes IP addresses received with XCLIENT, XFORWARD, or with the HaProxy protocol, for consistency with direct connections to Postfix. This may change the appearance of logging, and the way that check_client_access will match subnets of an IPv6 address. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse
Re: client_access not working
Viktor Dukhovni:
> On Mon, Mar 16, 2020 at 09:06:00AM +0100, Robby Van Mieghem wrote:
>
> > smtpd_client_restrictions =
> > check_client_access cidr:${config_directory}/client_access,
> > reject
> >
> > # EOP ranges as indicated by MS
> > 23.103.132.0/22 OK
> > 23.103.136.0/21 OK
> > 23.103.156.0/22 OK
> > 23.103.198.0/24 OK
> > 23.103.200.0/22 OK
> > 23.103.212.0/22 OK
>
> Unsurpringly, this returns "OK" for the listed entries, and
> no result otherwise, which then in "smtpd_client_restrictions"
> falls through to "reject".
>
> > Tried testing it also with:
> >
> > $ postmap -q "1.1.1.1" cidr:/etc/postfix-EOP2DC/client_access
> >
> > ? no result
>
> As expected, since "1.1.1.1" does not appear to be listed in the CIDR
> table.
>
> > So it generally allows every IP now...
>
> No, that's not the right conclusion.
To test access rules properly, use XCLIENT.
http://www.postfix.org/XCLIENT_README.html
Wietse
Re: client_access not working
On Mon, Mar 16, 2020 at 09:06:00AM +0100, Robby Van Mieghem wrote:
> smtpd_client_restrictions =
> check_client_access cidr:${config_directory}/client_access,
> reject
>
> # EOP ranges as indicated by MS
> 23.103.132.0/22 OK
> 23.103.136.0/21 OK
> 23.103.156.0/22 OK
> 23.103.198.0/24 OK
> 23.103.200.0/22 OK
> 23.103.212.0/22 OK
Unsurpringly, this returns "OK" for the listed entries, and
no result otherwise, which then in "smtpd_client_restrictions"
falls through to "reject".
> Tried testing it also with:
>
> $ postmap -q "1.1.1.1" cidr:/etc/postfix-EOP2DC/client_access
>
> à no result
As expected, since "1.1.1.1" does not appear to be listed in the CIDR
table.
> So it generally allows every IP now...
No, that's not the right conclusion.
--
Viktor.
Re: gmail.com is Unsecure ssl cert ?
> On Mar 16, 2020, at 9:04 AM, Benny Pedersen wrote: > > tested with > > posttls-finger gmail.com > > is it my own postfix that fails with this ? > > how can i solve it ? For opportunistic TLS, unvalidated certificates are not a failure. There is no problem, everything is working as expected: $ posttls-finger -l may -c -L summary gmail.com posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2607:f8b0:400d:c0f::1a]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 -- Viktor.
gmail.com is Unsecure ssl cert ?
tested with posttls-finger gmail.com is it my own postfix that fails with this ? how can i solve it ?
Re: How to match From as MAILFROM
On Monday, March 16, 2020 5:54:02 AM EDT Burn Zero wrote: > Hi, > > I have configured an internal postfix server where users will use that as > relay servers to relay emails to outside and internal users. > > I have restricted postfix to allow only one domain as MAILFROM and deny > rest all. But how to restrict From address like this? Is there any way in > postfix? It's out of scope for postfix itself to do that, but vrfydmn [1] does exactly that and can be added to your postfix configuration. Scott K [1] https://github.com/croessner/vrfydmn
How to match From as MAILFROM
Hi, I have configured an internal postfix server where users will use that as relay servers to relay emails to outside and internal users. I have restricted postfix to allow only one domain as MAILFROM and deny rest all. But how to restrict From address like this? Is there any way in postfix? Thank you.
client_access not working
Hello
I'm setting up a new postfix multi-instance and having issue with the
client_access setting ( this worked fine on our other RH6 servers with
postfix 2.6.6 )
Now with RH8 and postfix 3.3.1 it's not working. We are using the same
config :
smtpd_client_restrictions =
check_client_access cidr:${config_directory}/client_access,
reject
Waar de client_access bevat :
# EOP ranges as indicated by MS
23.103.132.0/22 OK
23.103.136.0/21 OK
23.103.156.0/22 OK
23.103.198.0/24 OK
23.103.200.0/22 OK
23.103.212.0/22 OK
…..
Tried testing it also with : postmap -q "1.1.1.1"
cidr:/etc/postfix-EOP2DC/client_access à no result
So it generally allows every IP now...
Anyone else came into this one ?
regs
