Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
I received the bug report/patch below from a Debian user. I'm somewhat busy this weekend/week, so I decided to forward it without evaluation rather than sit on it for a week until I could research it. I attempted to remove the distro specific noise from the report. Scott K Package: postfix Version: 3.4.1-1 Severity: important Tags: patch Hi, I have entries like this: [domain.tld]:587secure tafile=/etc/ssl/certs/Lets-Encrypt-Authority-X3.pem … in the file referenced by: smtp_tls_policy_maps = hash:/etc/postfix/tls_policy This worked just fine until 3.3.2-4 inclusive but since I've upgraded my sid system yesterday and Postfix was upgraded to 3.4.1-1 I see: postfix/smtp[15202]: warning: Trust anchor files not supported postfix/smtp[15202]: warning: TLS policy lookup error for [domain.tld]:587/domain.tld: client TLS configuration problem postfix/smtp[15202]: warning: TLS policy lookup for [domain.tld]:587/domain.tld: client TLS configuration problem postfix/smtp[15202]: 8B30018835E3: to=, relay=none, delay=1197, delays=1196/0.82/0.36/0, dsn=4.7.5, status=deferred (client TLS configuration problem) This seems to come from src/tls/tls_dane.c. I see that 3.4.0 has modified this file quite a bit, e.g. these lines were removed: #if OPENSSL_VERSION_NUMBER >= 0x100fL && \ (defined(X509_V_FLAG_PARTIAL_CHAIN) || !defined(OPENSSL_NO_ECDH)) #define TRUST_ANCHOR_SUPPORT … and there's only one "#ifdef TRUST_ANCHOR_SUPPORT" left, that guards the warning I'm seeing. This feels like a leftover of an incomplete cleanup of the TLS support code that happened in this release, such as dropping support for OpenSSL 1.0.1. FWIW the attached patch fixes this problem for me. I don't know if it can cause any trouble. From 4d98d0aa5aeb4fbb9941a4239251edfb1537a0e9 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sun, 10 Mar 2019 06:29:25 + Subject: [PATCH] Drop leftover of obsolete check for trust anchor support. --- src/tls/tls_dane.c | 4 1 file changed, 4 deletions(-) diff --git a/src/tls/tls_dane.c b/src/tls/tls_dane.c index 93f8e2a5..013426b1 100644 --- a/src/tls/tls_dane.c +++ b/src/tls/tls_dane.c @@ -1125,7 +1125,6 @@ TLS_DANE *tls_dane_resolve(unsigned port, const char *proto, DNS_RR *hostrr, int tls_dane_load_trustfile(TLS_DANE *dane, const char *tafile) { -#ifdef TRUST_ANCHOR_SUPPORT BIO*bp; char *name = 0; char *header = 0; @@ -1217,9 +1216,6 @@ int tls_dane_load_trustfile(TLS_DANE *dane, const char *tafile) } /* Some other PEM read error */ tls_print_errors(); -#else -msg_warn("Trust anchor files not supported"); -#endif return (0); } -- 2.20.1
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
Scott Kitterman: > I received the bug report/patch below from a Debian user. I'm somewhat busy > this weekend/week, so I decided to forward it without evaluation rather than > sit on it for a week until I could research it. > > I attempted to remove the distro specific noise from the report. Sorry for making you the guinea pig. I am considering to withdraw Postfix 3.4 and do a proper Postfix 3.5 release as planned later this year. We can't afford having a stable release with bug-of-the-week fixes like we have now. Wietse
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
On Sunday, March 10, 2019 11:11:15 AM Wietse Venema wrote: > Scott Kitterman: > > I received the bug report/patch below from a Debian user. I'm somewhat > > busy this weekend/week, so I decided to forward it without evaluation > > rather than sit on it for a week until I could research it. > > > > I attempted to remove the distro specific noise from the report. > > Sorry for making you the guinea pig. > > I am considering to withdraw Postfix 3.4 and do a proper Postfix > 3.5 release as planned later this year. We can't afford having a > stable release with bug-of-the-week fixes like we have now. I knew I was taking a risk jumping to 3.4 late in our release cycle. A week from now when it hits Debian Testing, the user base will grow significantly and we'll get more feedback. I guess there weren't enough testers for 3.4 before release. I don't know that that situation will be better later in the year for 3.5. From my point of view (I don't know about other distros/OS), it would be somewhat painful to stay on 3.3 for the next release at this point, but it'll be a lot harder a week from now. My preference would be to press on with 3.4 (I don't mind packaging the bug fixes if you don't mind releasing them), but if you are going to withdraw 3.4, please do it before next Sunday so I can keep it out of the next Debian release. Although Debian doesn't normally allow it, I've gotten permission from the release team to update postfix based on your microreleases (thir digit) based on the good history with them fixing relevant bugs with minimal regression risk. It's absolutely not a problem for me to stay on the 3.4 path if you're up for it. Scott K
Re: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
On Sun, 10 Mar 2019 11:11:15 -0400 (EDT), Wietse Venema stated: >Scott Kitterman: >> I received the bug report/patch below from a Debian user. I'm >> somewhat busy this weekend/week, so I decided to forward it without >> evaluation rather than sit on it for a week until I could research >> it. >> >> I attempted to remove the distro specific noise from the report. > >Sorry for making you the guinea pig. > >I am considering to withdraw Postfix 3.4 and do a proper Postfix >3.5 release as planned later this year. We can't afford having a >stable release with bug-of-the-week fixes like we have now. > > Wietse Wietse, the number of bugs found in stable releases of Postfix is infinitesimal when compared to other vendors who release products under the "fix it later" theory. -- Postfix User
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
To add a possible data point to the convo, at least one distro, OpenSUSE, is already toying with apparently poorly thought-thru patches (aka, not vetted/source here, from upstream) -- e,g, here, https://build.opensuse.org/package/view_file/openSUSE:Factory/postfix/postfix-linux45.patch?expand=1 -- to 'old release' postfix 3.3.3 for Linux5 support. no particular skin off _my_ nose -- i contentedly build/deploy only from Postfix upstream source. i understand it's 'their' decision, good or bad. nonetheless, it will inevitably generate noise here.
Re: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
On Sun, 10 Mar 2019 11:41:01 -0400, Scott Kitterman stated: >On Sunday, March 10, 2019 11:11:15 AM Wietse Venema wrote: >> Scott Kitterman: >> > I received the bug report/patch below from a Debian user. I'm >> > somewhat busy this weekend/week, so I decided to forward it >> > without evaluation rather than sit on it for a week until I could >> > research it. >> > >> > I attempted to remove the distro specific noise from the report. >> >> Sorry for making you the guinea pig. >> >> I am considering to withdraw Postfix 3.4 and do a proper Postfix >> 3.5 release as planned later this year. We can't afford having a >> stable release with bug-of-the-week fixes like we have now. > >I knew I was taking a risk jumping to 3.4 late in our release cycle. > >A week from now when it hits Debian Testing, the user base will grow >significantly and we'll get more feedback. > >I guess there weren't enough testers for 3.4 before release. I don't >know that that situation will be better later in the year for 3.5. >From my point of view (I don't know about other distros/OS), it would >be somewhat painful to stay on 3.3 for the next release at this point, >but it'll be a lot harder a week from now. > >My preference would be to press on with 3.4 (I don't mind packaging >the bug fixes if you don't mind releasing them), but if you are going >to withdraw 3.4, please do it before next Sunday so I can keep it out >of the next Debian release. > >Although Debian doesn't normally allow it, I've gotten permission from >the release team to update postfix based on your microreleases (thir >digit) based on the good history with them fixing relevant bugs with >minimal regression risk. It's absolutely not a problem for me to stay >on the 3.4 path if you're up for it. > >Scott K FreeBSD is using Postfix 3.3 for its stable release and Postfix 3.4 for its development (experimental) release. -- Postfix User
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
Scott Kitterman: > On Sunday, March 10, 2019 11:11:15 AM Wietse Venema wrote: > > Scott Kitterman: > > > I received the bug report/patch below from a Debian user. I'm somewhat > > > busy this weekend/week, so I decided to forward it without evaluation > > > rather than sit on it for a week until I could research it. > > > > > > I attempted to remove the distro specific noise from the report. > > > > Sorry for making you the guinea pig. > > > > I am considering to withdraw Postfix 3.4 and do a proper Postfix > > 3.5 release as planned later this year. We can't afford having a > > stable release with bug-of-the-week fixes like we have now. > > I knew I was taking a risk jumping to 3.4 late in our release cycle. > > A week from now when it hits Debian Testing, the user base will grow > significantly and we'll get more feedback. > > I guess there weren't enough testers for 3.4 before release. I don't know > that that situation will be better later in the year for 3.5. From my point > of view (I don't know about other distros/OS), it would be somewhat painful to > stay on 3.3 for the next release at this point, but it'll be a lot harder a > week from now. > > My preference would be to press on with 3.4 (I don't mind packaging the bug > fixes if you don't mind releasing them), but if you are going to withdraw 3.4 > please do it before next Sunday so I can keep it out of the next Debian > release. We know of multiple bugs that broke 'desirable functionality' after an overhaul of the TLS stack, and that were kindly brought to the developer's attention by folks like you. I have to consider the possibility that the same overhaul introduced an equal if not larger number of bugs with 'undesirable functionality', and that these bugs will be found by not-so-kind folks, who will report them only if it helps to promote themselves while at the same time destroying Postfix's good reputation. Wietse
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
On Sun, Mar 10, 2019 at 02:34:02PM +, Scott Kitterman wrote: > This worked just fine until 3.3.2-4 inclusive but since I've upgraded > my sid system yesterday and Postfix was upgraded to 3.4.1-1 I see: > > postfix/smtp[15202]: warning: Trust anchor files not supported > postfix/smtp[15202]: warning: TLS policy lookup error for > [domain.tld]:587/domain.tld: client TLS configuration problem > postfix/smtp[15202]: warning: TLS policy lookup for > [domain.tld]:587/domain.tld: client TLS configuration problem > postfix/smtp[15202]: 8B30018835E3: to=, relay=none, > delay=1197, delays=1196/0.82/0.36/0, dsn=4.7.5, status=deferred (client TLS > configuration problem) > diff --git a/src/tls/tls_dane.c b/src/tls/tls_dane.c > index 93f8e2a5..013426b1 100644 > --- a/src/tls/tls_dane.c > +++ b/src/tls/tls_dane.c > @@ -1125,7 +1125,6 @@ TLS_DANE *tls_dane_resolve(unsigned port, const char > *proto, DNS_RR *hostrr, > > int tls_dane_load_trustfile(TLS_DANE *dane, const char *tafile) > { > -#ifdef TRUST_ANCHOR_SUPPORT > BIO*bp; > char *name = 0; > char *header = 0; > @@ -1217,9 +1216,6 @@ int tls_dane_load_trustfile(TLS_DANE *dane, const > char *tafile) > } > /* Some other PEM read error */ > tls_print_errors(); > -#else > -msg_warn("Trust anchor files not supported"); > -#endif > return (0); > } The proposed patch is correct. Repeated below without "quoting": diff --git a/src/tls/tls_dane.c b/src/tls/tls_dane.c index 93f8e2a5..013426b1 100644 --- a/src/tls/tls_dane.c +++ b/src/tls/tls_dane.c @@ -1125,7 +1125,6 @@ TLS_DANE *tls_dane_resolve(unsigned port, const char *proto, DNS_RR *hostrr, int tls_dane_load_trustfile(TLS_DANE *dane, const char *tafile) { -#ifdef TRUST_ANCHOR_SUPPORT BIO*bp; char *name = 0; char *header = 0; @@ -1217,9 +1216,6 @@ int tls_dane_load_trustfile(TLS_DANE *dane, const char *tafile) } /* Some other PEM read error */ tls_print_errors(); -#else -msg_warn("Trust anchor files not supported"); -#endif return (0); } -- Viktor.
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
On Sun, Mar 10, 2019 at 12:29:44PM -0400, Wietse Venema wrote: > > My preference would be to press on with 3.4 (I don't mind packaging the bug > > fixes if you don't mind releasing them), but if you are going to withdraw > > 3.4 > > please do it before next Sunday so I can keep it out of the next Debian > > release. > > We know of multiple bugs that broke 'desirable functionality' after > an overhaul of the TLS stack, and that were kindly brought to the > developer's attention by folks like you. > > I have to consider the possibility that the same overhaul introduced > an equal if not larger number of bugs with 'undesirable functionality', > and that these bugs will be found by not-so-kind folks, who will > report them only if it helps to promote themselves while at the > same time destroying Postfix's good reputation. Some of the changes in 3.4 are quite useful when Postfix is compiled with OpenSSL 1.1.1, which introduces TLS 1.3. My sense is that the situation is not so dire as to warrant retracting the release. The recent changes in 3.4 are: - Support for server-side SNI, with new code to load multi-algorithm certificate chain sets. This also loads the key + cert in a single pass when both are in the same file, now with the correct test for the return value (first report bug) and tests. - More diligent tlsproxy(8) checking for compatible parameters in TLS connection re-use. The tlsproxy connection re-use was added earlier, and the more recent changes just fine-tune context sharing. - Removal of support for OpenSSL 1.0.2. Reduces the attack surface and intoduces no new code. This was however the source of the present (second) reported bug, because an #ifdef guard testing for 1.0.2 or later that should have been removed, was left in place. - Consolidation of TLS summary logging, and better logging of TLS 1.3 handshake properties. Looking over the various changes again, I think 3.4 is fine. I'll do another code review this week. -- Viktor.
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
Viktor Dukhovni: > On Sun, Mar 10, 2019 at 12:29:44PM -0400, Wietse Venema wrote: > > > > My preference would be to press on with 3.4 (I don't mind packaging the > > > bug > > > fixes if you don't mind releasing them), but if you are going to withdraw > > > 3.4 > > > please do it before next Sunday so I can keep it out of the next Debian > > > release. > > > > We know of multiple bugs that broke 'desirable functionality' after > > an overhaul of the TLS stack, and that were kindly brought to the > > developer's attention by folks like you. > > > > I have to consider the possibility that the same overhaul introduced > > an equal if not larger number of bugs with 'undesirable functionality', > > and that these bugs will be found by not-so-kind folks, who will > > report them only if it helps to promote themselves while at the > > same time destroying Postfix's good reputation. > > Some of the changes in 3.4 are quite useful when Postfix is compiled > with OpenSSL 1.1.1, which introduces TLS 1.3. > > My sense is that the situation is not so dire as to warrant retracting > the release. The recent changes in 3.4 are: > > - Support for server-side SNI, with new code to load multi-algorithm > certificate chain sets. This also loads the key + cert in a > single pass when both are in the same file, now with the correct > test for the return value (first report bug) and tests. > > - More diligent tlsproxy(8) checking for compatible parameters in TLS > connection re-use. The tlsproxy connection re-use was added earlier, > and the more recent changes just fine-tune context sharing. > > - Removal of support for OpenSSL 1.0.2. Reduces the attack > surface and intoduces no new code. > > This was however the source of the present (second) reported > bug, because an #ifdef guard testing for 1.0.2 or later that > should have been removed, was left in place. > > - Consolidation of TLS summary logging, and better logging of > TLS 1.3 handshake properties. > > Looking over the various changes again, I think 3.4 is fine. I'll > do another code review this week. You are looking from the "we made improvements" angle. I am looking from the "with hard work, we introduce 1 bug in 1000 lines of new code" angle. In the TLS library there were 1039 additions and 559 deletions from Postfix 3.3.3 to 3.4.1 (diff -bur --new-file for 'c' and 'h' files only, excluding proxy-related code). That count does not distinguish between low-impact changes that affect only nearby code, and high-impact changes that affect multiple lines, such as global ifdefs. The changes among those 1600 lines that 'broke' intended functionality are 'easy' to weed out - just wait for people to to report breakages. Such a reactive approach might be acceptable in some projects. I am concerned about the changes among those 1600 lines that did NOT break intended behavior, but that introduced some other problem. What is the basis for confidence that no such problems have been introduced, if we obviously missed multiple things that could have been found with simple tests? Wietse
Postfix stable release 3.4.2
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.4.2.html] Postfix stable release 3.4.2 is available. * DANE trust anchor file support was broken after the Postfix 3.4 TLS library overhaul. Fix by Scott Kitterman. * LINUX5 is supported, based on sanity checks with a Rawhide prerelease. * Fixes for two null pointer reads in warnings for errors that never happen (in code from 7 and 18 years ago, respectively). The plan is to maintain zero code difference between the stable release and the development release, until there have been no bug-of-the-week patches for much more than several weeks. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
On 10/03/2019 15:07, Wietse Venema wrote: > You are looking from the "we made improvements" angle. I am looking > from the "with hard work, we introduce 1 bug in 1000 lines of new > code" angle. > > In the TLS library there were 1039 additions and 559 deletions from > Postfix 3.3.3 to 3.4.1 (diff -bur --new-file for 'c' and 'h' files > only, excluding proxy-related code). That count does not distinguish > between low-impact changes that affect only nearby code, and > high-impact changes that affect multiple lines, such as global ifdefs. > > The changes among those 1600 lines that 'broke' intended functionality > are 'easy' to weed out - just wait for people to to report breakages. > Such a reactive approach might be acceptable in some projects. > > I am concerned about the changes among those 1600 lines that did > NOT break intended behavior, but that introduced some other problem. > > What is the basis for confidence that no such problems have been > introduced, if we obviously missed multiple things that could have > been found with simple tests? I have no say in the development of Postfix, however I believe another interesting question that should be asked is: what is going to make you more confident in the releasing those changes later this year with Postfix 3.5? Are there circumstances for which more testing and code auditing will happen if the code is not released? Cheers, Dan
Re: Postfix stable release 3.4.2
when will this version be published? on the web is not yet the source or the change list * Este mensaje y todos los archivos adjuntos son confidenciales y de uso exclusivo por parte de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le agradecemos que lo notifique inmediatamente al remitente y destruya el mensaje. Queda prohibida cualquier modificación, edición, uso o divulgación no autorizados. El Emisor no se hace responsable de este mensaje si ha sido modificado, distorsionado, falsificado, infectado por un virus o editado o difundido sin autorización. *** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. *** El 10/03/2019 a las 23:19, Wietse Venema escribió: [An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.4.2.html] Postfix stable release 3.4.2 is available. * DANE trust anchor file support was broken after the Postfix 3.4 TLS library overhaul. Fix by Scott Kitterman. * LINUX5 is supported, based on sanity checks with a Rawhide prerelease. * Fixes for two null pointer reads in warnings for errors that never happen (in code from 7 and 18 years ago, respectively). The plan is to maintain zero code difference between the stable release and the development release, until there have been no bug-of-the-week patches for much more than several weeks. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse smime.p7s Description: Firma criptográfica S/MIME
Re: Fwd: Bug#924183: postfix: Trust anchor files (tafile=) in TLS policy break secure level email delivery
Daniele Nicolodi: > On 10/03/2019 15:07, Wietse Venema wrote: > > You are looking from the "we made improvements" angle. I am looking > > from the "with hard work, we introduce 1 bug in 1000 lines of new > > code" angle. > > > > In the TLS library there were 1039 additions and 559 deletions from > > Postfix 3.3.3 to 3.4.1 (diff -bur --new-file for 'c' and 'h' files > > only, excluding proxy-related code). That count does not distinguish > > between low-impact changes that affect only nearby code, and > > high-impact changes that affect multiple lines, such as global ifdefs. > > > > The changes among those 1600 lines that 'broke' intended functionality > > are 'easy' to weed out - just wait for people to to report breakages. > > Such a reactive approach might be acceptable in some projects. > > > > I am concerned about the changes among those 1600 lines that did > > NOT break intended behavior, but that introduced some other problem. > > > > What is the basis for confidence that no such problems have been > > introduced, if we obviously missed multiple things that could have > > been found with simple tests? > > I have no say in the development of Postfix, however I believe another > interesting question that should be asked is: what is going to make you > more confident in the releasing those changes later this year with > Postfix 3.5? Are there circumstances for which more testing and code > auditing will happen if the code is not released? Because we won't be changing 1600 lines in a critical library two months before the release. Wietse
Re: Postfix stable release 3.4.2
Francesc Pe?alvez: > when will this version be published? on the web is not yet the source or > the change list It is released on www.porcupine.org. If you get it from a Postfix mirror, then you will have to wait up to 24 hours. Wietse
Re: Postfix stable release 3.4.2
there is an error in that web if i choose the link of wietse own site the link download is this ftp://ftp.porcupine.org/mirrors/postfix-release/index.html * Este mensaje y todos los archivos adjuntos son confidenciales y de uso exclusivo por parte de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le agradecemos que lo notifique inmediatamente al remitente y destruya el mensaje. Queda prohibida cualquier modificación, edición, uso o divulgación no autorizados. El Emisor no se hace responsable de este mensaje si ha sido modificado, distorsionado, falsificado, infectado por un virus o editado o difundido sin autorización. *** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. *** El 11/03/2019 a las 0:07, Wietse Venema escribió: Francesc Pe?alvez: when will this version be published? on the web is not yet the source or the change list It is released on www.porcupine.org. If you get it from a Postfix mirror, then you will have to wait up to 24 hours. Wietse smime.p7s Description: Firma criptográfica S/MIME
Re: Postfix stable release 3.4.2
Is there a simple way to make a deb package from source or do an update from a deb package? * Este mensaje y todos los archivos adjuntos son confidenciales y de uso exclusivo por parte de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le agradecemos que lo notifique inmediatamente al remitente y destruya el mensaje. Queda prohibida cualquier modificación, edición, uso o divulgación no autorizados. El Emisor no se hace responsable de este mensaje si ha sido modificado, distorsionado, falsificado, infectado por un virus o editado o difundido sin autorización. *** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. *** El 11/03/2019 a las 0:21, Francesc Peñalvez escribió: there is an error in that web if i choose the link of wietse own site the link download is this ftp://ftp.porcupine.org/mirrors/postfix-release/index.html * Este mensaje y todos los archivos adjuntos son confidenciales y de uso exclusivo por parte de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le agradecemos que lo notifique inmediatamente al remitente y destruya el mensaje. Queda prohibida cualquier modificación, edición, uso o divulgación no autorizados. El Emisor no se hace responsable de este mensaje si ha sido modificado, distorsionado, falsificado, infectado por un virus o editado o difundido sin autorización. *** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. *** El 11/03/2019 a las 0:07, Wietse Venema escribió: Francesc Pe?alvez: when will this version be published? on the web is not yet the source or the change list It is released on www.porcupine.org. If you get it from a Postfix mirror, then you will have to wait up to 24 hours. Wietse smime.p7s Description: Firma criptográfica S/MIME
Re: Postfix stable release 3.4.2
Francesc Pe?alvez: > Is there a simple way to make a deb package from source or do an update > from a deb package? Postfix is platform neutral, so I don't do deb, rpm, pkg, or other package managers. That is the job for distibutions. Wietse
Re: Postfix stable release 3.4.2
Francesc Pe?alvez: > there is an error in that web if i choose the link of wietse own site > the link download is this > ftp://ftp.porcupine.org/mirrors/postfix-release/index.html Using Chrome? use http://ftp.porcupine.org/mirrors/postfix-release/index.html Wietse
Re: Postfix stable release 3.4.2
Please stop sending this nonsense to the list. > On 10 Mar 2019, at 17:21, Francesc Peñalvez wrote: > > * > Este mensaje y todos los archivos adjuntos son confidenciales y de uso > exclusivo por parte > de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le > agradecemos que > lo notifique inmediatamente al remitente y destruya el mensaje. Queda > prohibida cualquier > modificación, edición, uso o divulgación no autorizados. El Emisor no se hace > responsable > de este mensaje si ha sido modificado, distorsionado, falsificado, infectado > por un virus o > editado o difundido sin autorización. > > > *** > This message and any attachments are confidential and intended for the named > addressee(s) only. > If you have received this message in error, please notify immediately the > sender, then delete > the message. Any unauthorized modification, edition, use or dissemination is > prohibited. > The sender shall not be liable for this message if it has been modified, > altered, falsified, infected > by a virus or even edited or disseminated without authorization. > ***
Re: Postfix stable release 3.4.2
On 3/10/19 3:19 PM, Wietse Venema wrote: >* LINUX5 is supported, based on sanity checks with a Rawhide > prerelease. fyi, still cd postfix-3.4.2 make tidy make -f Makefile.in MAKELEVEL= Makefiles (echo "# Do not edit -- this file documents how Postfix was built for your machine."; /bin/sh makedefs) >makedefs.tmp ATTENTION: ATTENTION: Unknown system type: Linux 5.0.0-lp150.5.g6bc6477-default ATTENTION: make: *** [Makefile.in:31: Makefiles] Error 1 make: *** [Makefile:22: Makefiles] Error 2 checking, grep Linux makedefs # Do not build with Linux EPOLL support. # is unavailable on some recent Linux distributions. Linux.1*) SYSTYPE=LINUX1 Linux.2*) SYSTYPE=LINUX2 ??Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR # The following was validated in 2014 on FreeBSD/Linux and Solaris 9.
Re: Postfix stable release 3.4.2
sure i use it thanks!! the question of whether there is a simple way to make a deb package, is that I have a somewhat complicated configuration and I would not like to lose it or run two postfix one in the local directory and the deb package in normal sbin, so I asked if there is some simple way to pass the source to package deb * Este mensaje y todos los archivos adjuntos son confidenciales y de uso exclusivo por parte de su/sus destinatario/s. Si usted ha recibido este mensaje por error, le agradecemos que lo notifique inmediatamente al remitente y destruya el mensaje. Queda prohibida cualquier modificación, edición, uso o divulgación no autorizados. El Emisor no se hace responsable de este mensaje si ha sido modificado, distorsionado, falsificado, infectado por un virus o editado o difundido sin autorización. *** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. *** El 11/03/2019 a las 0:34, Wietse Venema escribió: Francesc Pe?alvez: there is an error in that web if i choose the link of wietse own site the link download is this ftp://ftp.porcupine.org/mirrors/postfix-release/index.html Using Chrome? use http://ftp.porcupine.org/mirrors/postfix-release/index.html Wietse smime.p7s Description: Firma criptográfica S/MIME
Re: Postfix stable release 3.4.2
PGNet Dev: > On 3/10/19 3:19 PM, Wietse Venema wrote: > >* LINUX5 is supported, based on sanity checks with a Rawhide > > prerelease. > > fyi, still Sorry, I forgot to update the makedefs script. Wietse
Re: Postfix stable release 3.4.2
Sorry its my firm,i erease when send mail to this list smime.p7s Description: Firma criptográfica S/MIME
Postfix stable release 3.4.3
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.4.3.html] Postfix stable release 3.4.3 is available. One of the Postfix 3.4.2 changes (LINUX5) was missing. For your convenience, the remainder of this text repeats the content of the Postfix 3.4.2 announcement. * DANE trust anchor file support was broken after the Postfix 3.4 TLS library overhaul. Fix by Scott Kitterman. * LINUX5 is supported, based on sanity checks with a Rawhide prerelease. * Fixes for two null pointer reads in warnings for errors that never happen (in code from 7 and 18 years ago, respectively). The plan is to maintain zero code difference between the stable release and the development release, until there have been no bug-of-the-week patches for much more than several weeks. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse
Re: Postfix stable release 3.4.2
Francesc Peñalvez skrev den 2019-03-11 00:44: Sorry its my firm,i erease when send mail to this list and there is freemail where forced signatures is not done
Re: TLS client certificates and auth external
> On Jan 8, 2019, at 5:17 PM, Bastian Schmidt <[hidden email]> wrote: > > I have an email client (K-9 on Android), which, when using TLS client > certificates insists on sending an auth external. However, postfix/SASL > does not advertise external auth, which causes the client to not being > able to use client certificates with postfix. > > As I see it, postfix is missing the external mechanism as specified in RFC > (SASL) completely. Thus, I have implemented this feature (for TLS CA > client certs) and I am currently successfully running this on a local > installation using cyrus sasl. > > I would be willing to provide a patch and would really like to see this > integrated in future versions of postfix. I'm quite excited about seeing this feature added to Postfix. I have a similar configuration, and have been putting off making the proposed changes myself. I had previously posted on the Dovecot mailing list [1] to no avail. I'm happy to know that there are at least two of us out there who would benefit from this feature! Thanks, Matt [1] https://www.dovecot.org/list/dovecot/2017-February/106884.html -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html