[pfx] Re: Documentation on upgrade 2.10 to 3.5

have several questions for the group. Background - Currently I have Postfix 2.10.1 running on CentOS7.  It is rock-solid.  If not for the coming EOL on CentOS7 I would leave it alone. Indeed CentOS 7 is very near to EOL. If you want you can upgrade CentOS 7 to the latest version of Postfix

[pfx] Re: Documentation on upgrade 2.10 to 3.5

On Wed, Jan 24, 2024 at 11:17:16AM -0500, Viktor Dukhovni via Postfix-users wrote: > > > 2) The leapp output mentions a compatibility option.  I think I need to > > > use that.  Is there documentation on it? > > https://www.postfix.org/postconf.5.html#compatibility_level >

[pfx] Re: Documentation on upgrade 2.10 to 3.5

ood way to > > actually run messages through it, but I can at least see if the Postfix > > service starts. Your choice. > 4) Probably not a PostFix question, but it is related. One big reason for > doing an in-place upgrade is because I do not know how to move my mailbox > fro

[pfx] Re: Documentation on upgrade 2.10 to 3.5

Oops! I just realized that I sent this instead of saving it. Dang! So continuing my thoughts with item 4 ... 4) Probably not a PostFix question, but it is related. One big reason for doing an in-place upgrade is because I do not know how to move my mailbox from the old server to something

[pfx] Re: Postfix stopped logging lines with sender IP addresses after upgrade

On Tuesday, January 2, 2024 at 08:46:01 PM GMT+1, Vince Heuser via Postfix-users wrote: >I recently upgraded to mail_version = 3.4.23 >Suddenly, Postfix no longer logs the lines with IP addresses for the >connections. >There use to be some additional log lines with sender ip addresses.

[pfx] Re: Postfix stopped logging lines with sender IP addresses after upgrade

A. Schulze via Postfix-users wrote in <8c5873ea-137e-4938-8b77-2194fd757...@andreasschulze.de>: |Am 02.01.24 um 20:44 schrieb Vince Heuser via Postfix-users: |> smtp   inet  n   -   y   -   -   smtpd | |Hi, | |the smtp server run chroot. You need to configure syslog

[pfx] Re: Postfix stopped logging lines with sender IP addresses after upgrade

On Tue, Jan 02, 2024 at 02:44:06PM -0500, Vince Heuser via Postfix-users wrote: > Jan 02 14:26:56 islou postfix/qmgr[2]: 4T4NC41vLCzQ1P: > from=, size=1258, nrcpt=1 (queue active) > Jan 02 14:26:56 islou postfix/smtp[22517]: 4T4N9z4tYzzQ1b: to=, > relay=127.0.0.1[127.0.0.1]:10024, delay=57,

[pfx] Re: Postfix stopped logging lines with sender IP addresses after upgrade

Am 02.01.24 um 20:44 schrieb Vince Heuser via Postfix-users: smtp   inet  n   -   y   -   -   smtpd Hi, the smtp server run chroot. You need to configure syslog to listen on /path/to/postfix-chroot/dev/log (usually /var/spool/postfix/dev/log) Andreas

[pfx] Postfix stopped logging lines with sender IP addresses after upgrade

I recently upgraded to mail_version = 3.4.23 Suddenly, Postfix no longer logs the lines with IP addresses for the connections. There use to be some additional log lines with sender ip addresses. What did I break?  Why no sender data any longer? Sample LOG block: Jan 02 14:26:56 islou

[pfx] Re: forward_path setting not being processed correctly after upgrade

On Thu, Oct 26, 2023 at 03:16:04PM -0400, Viktor Dukhovni via Postfix-users wrote: > What's notable here, is how rare actual compatibility breaks are in > Postfix. Wietse has managed to maintain essentially backwards > compatible behaviour for over 20 years, which speaks to both design >

[pfx] PATCH: forward_path setting not being processed correctly after upgrade

sandmant--- via Postfix-users: > I am updating a system from postfix-2.10.1 to postfix-3.5.9 (and > RHEL7->RHEL9), and it seems my forward_path is no longer getting processed > correctly. > > postconf shows the correct forward_path: > > root@rt2:/etc/postfix-auth> postconf -c

[pfx] Re: forward_path setting not being processed correctly after upgrade

On Thu, Oct 26, 2023 at 01:56:40PM -0500, sandm...@rice.edu wrote: > > So the cases that use ${recipient_delimiter} will only match addresss that > > actually have an extension. If you want to use it unconditionally, you'll > > need to use a literal "+", instead. > > Wow! There is no need

[pfx] Re: forward_path setting not being processed correctly after upgrade

> So the cases that use ${recipient_delimiter} will only match addresss that > actually have an extension. If you want to use it unconditionally, you'll > need to use a literal "+", instead. Wow! There is no need for me to use the literal. Thank you so much for such a quick solution! rt2

[pfx] Re: forward_path setting not being processed correctly after upgrade

On Thu, Oct 26, 2023 at 12:38:22PM -0500, sandmant--- via Postfix-users wrote: > I am updating a system from postfix-2.10.1 to postfix-3.5.9 (and > RHEL7->RHEL9), and it seems my forward_path is no longer getting > processed correctly. The Postfix local delivery agent is extremently stable

[pfx] forward_path setting not being processed correctly after upgrade

I am updating a system from postfix-2.10.1 to postfix-3.5.9 (and RHEL7->RHEL9), and it seems my forward_path is no longer getting processed correctly. postconf shows the correct forward_path: root@rt2:/etc/postfix-auth> postconf -c /etc/postfix-auth/ forward_path forward_path =

Re: symbolic links problem due to do-release-upgrade (postfix 3.6.4)

Hello Victor! Just by a chance I noticed this email and wanted to add a comment. 04.10.2022 02:52, Viktor Dukhovni wrote: .. Perhaps you previously had a "backports" package that uses a non-default release label, and it persisted across the upgrade... You may need to also look at t

Re: symbolic links problem due to do-release-upgrade (postfix 3.6.4)

all the correct package. Perhaps you previously had a "backports" package that uses a non-default release label, and it persisted across the upgrade... You may need to also look at the configs (IIRC) /etc/apt.d/ to see what release pins and preferences you have in place... Recovering a messed up s

Re: symbolic links problem due to do-release-upgrade (postfix 3.6.4) - was: manually build 3.7.2 denies SASL although included in make command

Martin: > HI Wietse, > > yes, I'm afraid that's true, these are the contents of that old > directory All those binaries have mail_version=3.4.13, therefore none will work Postfix 3.6 libraries. > I assume there has been a kind of new configuration between old postfix > version and the 3.6.4

Re: symbolic links problem due to do-release-upgrade (postfix 3.6.4) - was: manually build 3.7.2 denies SASL although included in make command

HI Wietse, yes, I'm afraid that's true, these are the contents of that old directory (I renamed it and put a symbolic link to the sbin directory carrying the current executables): root@jerakeen:/usr/libexec/postfix/sbin.OLD# find . -type f -print | while read file; do echo -n "$file -> ";

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

On 2021-11-16 23:25, PGNet Dev wrote: fyi, upstream pymilter's fixed the issue https://github.com/sdgathman/pymilter/issues/44 using (for now), pymilter from git main, dkimpy-milter signing with python 3.10 is again functional good news, is it then possible to use pymilter in fuglu ?

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

On 11/2/21 16:26, Scott Kitterman wrote: On November 2, 2021 8:18:54 PM UTC, PGNet Dev wrote: i've reported the bug here, python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats" https://bugs.launchpad.net/dkimpy-milter/+bug/1949520

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

On 11/2/21 16:26, Scott Kitterman wrote: Thanks. From the error message, that looks like something from the Python C API, so it's almost certainly in the pymilter Python binding for libmilter, not in dkimpy-milter itself. +1 https://github.com/sdgathman/pymilter/issues/44 thx

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

On November 2, 2021 8:18:54 PM UTC, PGNet Dev wrote: > >i've reported the bug here, > > python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must > be defined for '#' formats" > https://bugs.launchpad.net/dkimpy-milter/+bug/1949520 > >fwiw, python 3.9 still works as

heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

i've reported the bug here, python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats" https://bugs.launchpad.net/dkimpy-milter/+bug/1949520 fwiw, python 3.9 still works as expected now to poke at it ...

Re: Major upgrade of mail server

Hi, you always can create a backup of your EC2 instance and do a rollback in case of any trouble after or during upgrade. WBR, Andrey Tovstik > On 8 Jul 2021, at 04:42, Shawn Heisey wrote: > > I have a mail server in AWS that is currently running Ubuntu 18. Every time > I

Re: Major upgrade of mail server

I've been a little bit terrified of doing an upgrade, because I do have a couple of people using my mail server for real work email and I don't want to disrupt them. Besides Postfix you could have a look at https://doc.dovecot.org/installation_guide/upgrading/from-2.2-to-2.3/

Re: Major upgrade of mail server

ain points I might > encounter when doing this kind of major upgrade, and if there is any > helpful information that can help me get through those problems. I'm > hoping that it will go smoothly and everything just works. Postfix upgrades are typically non-distruptive, but take a look over th

Major upgrade of mail server

I have a mail server in AWS that is currently running Ubuntu 18. Every time I log in, I am reminded that I can upgrade to Ubuntu 20. On Ubuntu 18, postfix is version 3.3.0-1ubuntu0.3. On Ubuntu 20, postfix would be upgraded to 3.4.10-1ubuntu1. Many other packages, probably including

Re: upgrade 2.10 - 3.3 config compatibility

On 22/03/21 3:44 am, Wietse Venema wrote: Matus UHLAR - fantomas: With those set, all services in master.cf explicitly chroot=n, and compatibility_level set to 99 don't do this. You never know what changes in the future and will require your intervention. Indeed. Postfix 3.6 comes with a

Re: upgrade 2.10 - 3.3 config compatibility

/8, 192.168.1.0/24") 3. explicitly set relay_domains=$mydestination If I do those should I explicitly set compatibility_level, or would it not be needed because I have addressed the compatibility issues? And are there any other 'gotchas' to be aware of with this upgrade? On 21.03.21 2

Re: upgrade 2.10 - 3.3 config compatibility

- Message from Viktor Dukhovni - Date: Mon, 22 Mar 2021 00:13:00 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org On Mon, Mar 22, 2021 at 12:32:18PM +1000, Simon

Re: upgrade 2.10 - 3.3 config compatibility

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination ... RBLs, ... for inbound mail ... > With the items I need to watch for (emphasis added ** **) that means I > need it to be less than 1. Once I am confident of the outcome I'll set

Re: upgrade 2.10 - 3.3 config compatibility

- Message from Viktor Dukhovni - Date: Sun, 21 Mar 2021 21:15:36 -0400 From: Viktor Dukhovni Reply-To: postfix-users@postfix.org Subject: Re: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org On Mon, Mar 22, 2021 at 10:17:16AM +1000, Simon

Re: upgrade 2.10 - 3.3 config compatibility

On Mon, Mar 22, 2021 at 10:17:16AM +1000, Simon Wilson wrote: > I've removed mynetworks_style based on improved knowledge as noted > above; commented out append_dot_mydomain and relay_domains, have set > compatibility_level to 0, and will monitor for messages. The right compatibility level

Re: upgrade 2.10 - 3.3 config compatibility

- Message from Matus UHLAR - fantomas - Date: Sun, 21 Mar 2021 15:26:12 +0100 From: Matus UHLAR - fantomas Subject: Re: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org I have a well established 2.10 Postfix instance on 2.10 (CentOS7) which

Re: upgrade 2.10 - 3.3 config compatibility

Matus UHLAR - fantomas: > >With those set, all services in master.cf explicitly chroot=n, and > >compatibility_level set to 99 > > don't do this. You never know what changes in the future and will require > your intervention. Indeed. Postfix 3.6 comes with a handful breaking changes. The

Re: upgrade 2.10 - 3.3 config compatibility

192.168.1.0/24") 3. explicitly set relay_domains=$mydestination If I do those should I explicitly set compatibility_level, or would it not be needed because I have addressed the compatibility issues? And are there any other 'gotchas' to be aware of with this upgrade? On 21.03.21 2

Re: upgrade 2.10 - 3.3 config compatibility

- Message from Simon Wilson - Date: Fri, 19 Mar 2021 13:40:11 +1000 From: Simon Wilson Reply-To: si...@simonandkate.net Subject: upgrade 2.10 - 3.3 config compatibility To: postfix-users@postfix.org I have a well established 2.10 Postfix instance on 2.10 (CentOS7

upgrade 2.10 - 3.3 config compatibility

/8, 192.168.1.0/24") 3. explicitly set relay_domains=$mydestination If I do those should I explicitly set compatibility_level, or would it not be needed because I have addressed the compatibility issues? And are there any other 'gotchas' to be aware of with this upgrade? Thank you kindly. Simon -- Simon Wilson M: 0400 12 11 16

Re: "Postfix Upgrade 3.4.7 to 3.5.x"

On 21/04/20 11:56 pm, SysAdmin EM wrote: Hello everyone. I manage a server which works as a smarthost and I need to update my version of Postfix since the new version incorporates a functionality to manually expire messages and how I handle a large volume of shipments is very useful for me.

"Postfix Upgrade 3.4.7 to 3.5.x"

Hello everyone. I manage a server which works as a smarthost and I need to update my version of Postfix since the new version incorporates a functionality to manually expire messages and how I handle a large volume of shipments is very useful for me. System info: CentOS Linux release 7.7.1908

Re: Upgrade postfix2 to postfix3 - random.pl is compatible?

On Tue, Feb 04, 2020 at 09:45:50AM -0500, Wietse Venema wrote: > BTW You don't need random.pl. Postfix 3 has randmap built-in. > > /etc/postfix/main.cf >foo_maps = randmap:{A,A,A,B,B} Demo: $ yes . | head -n 1 | postmap -q - "randmap:{A,A,A,B,B}" | sort | uniq -c 5957 . A

Re: Upgrade postfix2 to postfix3 - random.pl is compatible?

Emanuel: [ Charset windows-1252 converted... ] > Hello, > > i work in updating my version of postfix, i use the 2.10.1 version, in > Centos 7 arch 64 bits, with an randomize outgoing smtp service, through > a perl script call randomize.pl. Here code example: >

Upgrade postfix2 to postfix3 - random.pl is compatible?

Hello, i work in updating my version of postfix, i use the 2.10.1 version, in Centos 7 arch 64 bits, with an randomize outgoing smtp service, through a perl script call randomize.pl. Here code example: http://marinovl.blogspot.com/2012/09/postfix-how-to-balance-outgoing-emails.html?m=1 I

Re: Post-upgrade script finds wrong version

nt machine? Must have copied that directory from the existing desktop. Fixing the version number in main.cf allowed set_permissions upgrade_configuration to run and upgrade master.cf too. Thanks very much, Rich

Re: Post-upgrade script finds wrong version

Rich Shepard: > I'm migrating to a new desktop as my server/workstation. Postfix-3.3.2 was > installed so I just upgraded to -3.4.6. When I ran postfix set-permissions > upgrade-configuration it returned > chown: cannot access '/usr/doc/postfix-3.3.1/README_FILES': No such file or

Post-upgrade script finds wrong version

I'm migrating to a new desktop as my server/workstation. Postfix-3.3.2 was installed so I just upgraded to -3.4.6. When I ran postfix set-permissions upgrade-configuration it returned chown: cannot access '/usr/doc/postfix-3.3.1/README_FILES': No such file or directory I cannot find the set

Re: Postfix upgrade, possible issue

On Tue, Jul 23, 2019 at 09:11:58AM +0200, Enrico Morelli wrote: > I would to upgrade our mail server from Debian 9 to 10. The postfix > version on Debian 9 is 3.1.12 while on Debian 10 will be 3.4.5. Can I > encounter issue during the upgrade? Are there incompatible > configura

Postfix upgrade, possible issue

Dear, I would to upgrade our mail server from Debian 9 to 10. The postfix version on Debian 9 is 3.1.12 while on Debian 10 will be 3.4.5. Can I encounter issue during the upgrade? Are there incompatible configuration options between the two versions

Re: TLS changes and breakage after 3.3.2 -> 3.4.0 upgrade

On Mon, Mar 04, 2019 at 07:43:17PM -0500, Wietse Venema wrote: > Viktor Dukhovni: > > The reason there's no logging of a problem, is that there is no > > problem to log! :-( The certificate initialization was successful, > > but due to a bug in reporting success/failure to the caller, the > >

Re: TLS changes and breakage after 3.3.2 -> 3.4.0 upgrade

On Tue, Mar 05, 2019 at 06:03:47AM +0500, Mike Kazantsev wrote: > Thanks for testing this one-file case, such a quick patch and releases. You're welcome. > It's rare that such things are bugs and not my misconfiguration, so > apologies for maybe being too long-winded in describing the wrong

Re: TLS changes and breakage after 3.3.2 -> 3.4.0 upgrade

On Mon, 4 Mar 2019 18:43:32 -0500 Viktor Dukhovni wrote: > > Neither of these tells me what the problem with TLS engine was, and why > > it stopped working in 3.4.0, which I think is the main problem here. > > The reason there's no logging of a problem, is that there is no > problem to log!

Re: TLS changes and breakage after 3.3.2 -> 3.4.0 upgrade

Viktor Dukhovni: > The reason there's no logging of a problem, is that there is no > problem to log! :-( The certificate initialization was successful, > but due to a bug in reporting success/failure to the caller, the > successful outcome was treated as a failure (whose reason would > have

Re: TLS changes and breakage after 3.3.2 -> 3.4.0 upgrade

On Tue, Mar 05, 2019 at 04:02:36AM +0500, Mike Kazantsev wrote: > And logs only show two kinds of messages on delivery: > > postfix/smtp[16394]: initializing the client-side TLS engine > postfix/smtp[16393]: 869C7A23AD: TLS is required, but our TLS engine is > unavailable > > Neither of

TLS changes and breakage after 3.3.2 -> 3.4.0 upgrade

is failing, but neither of them provides anything else about the problem. What is the expected way for postfix user to get an understanding of why postfix starts failing here after upgrade? I.e. which option it rejects or lacks, for what reason, etc. (while working perfectly and without any warnings

Re: Since 3.4 upgrade, no incoming mail to server is allowed in?

> Date: Friday, November 30, 2018 07:54:08 -0700 > From: rachalmers > > Well, I can't see what's happening here. 3.4 isn't presenting me > with mail.logs on the Mac. Mojave. > Internally, I can send mail to myself, but I now no longer get mail > from outside? > > Sending to myself >

Since 3.4 upgrade, no incoming mail to server is allowed in?

Well, I can't see what's happening here. 3.4 isn't presenting me with mail.logs on the Mac. Mojave. Internally, I can send mail to myself, but I now no longer get mail from outside? Sending to myself /usr/sbin/sendmail -bv works. It's all internal Sending to anything outside kind of works - it

Before I actually type 'make upgrade"....

\ newaliases_path=/usr/local/bin/newaliases \ sendmail_path=/usr/local/sbin/sendmail \ What I want to know is, will ‘make upgrade’ overwrite any of the .cf files. The configuration files? or will it leave the existing files in place? The INSTALL fine in the sources directory isn’t clear

Re: Make upgrade doesn't copy new binaries

Peter Lindgren: > Hello, I have compiled 3.3.1 from sources with a few extra options, on > OpenBSD 6.3. > I run make upgrade because I have an existing installation (from packages) > whose configuration I want to keep. > I run make upgrade as root, it prints a lot but no errors

Make upgrade doesn't copy new binaries

Hello, I have compiled 3.3.1 from sources with a few extra options, on OpenBSD 6.3. I run make upgrade because I have an existing installation (from packages) whose configuration I want to keep. I run make upgrade as root, it prints a lot but no errors as far as I can tell. I have run postfix

Re: Postfix upgrade breaks emails accounts from Mac OS X

Viktor Dukhovni writes: >> On Feb 6, 2018, at 1:26 AM, Olivier wrote: >> >>> TLS is set up just fine. What's failing is SASL. Perhaps there are >>> different authentication settings on port 587 than on 25, and remaking >>> the email

Re: Postfix upgrade breaks emails accounts from Mac OS X

> On Feb 6, 2018, at 1:26 AM, Olivier wrote: > >> TLS is set up just fine. What's failing is SASL. Perhaps there are >> different authentication settings on port 587 than on 25, and remaking >> the email account has the effect of switching the submission port? >>

Re: Postfix upgrade breaks emails accounts from Mac OS X

Viktor Dukhovni writes: >> On Feb 3, 2018, at 1:21 PM, Karol Augustin wrote: >> >> I have few people connecting using Macs. I had similar issue when I >> upgraded libssl to 1.1.0f-4 all of them couldn't connect as they are >> still using TLS 1.0.

Re: Postfix upgrade breaks emails accounts from Mac OS X

Viktor Dukhovni writes: >> On Feb 2, 2018, at 12:39 AM, Olivier wrote: >> >>> You've also not explained what you mean by deleting and recreating the >>> account. >> >> I am not a Mac user, but from the Mail app, select Files/Account and

Re: Postfix upgrade breaks emails accounts from Mac OS X

; > Ah, I see reading ahead that you are using cyrus. > > I found cyrus to be poorly documented and fragile, and switched to > dovecot on recommendations on this list. I've been pleased with it. OK, I will keep that in mind for a future upgrade :) Now I prefer to limit my changes

Re: Postfix upgrade breaks emails accounts from Mac OS X

"@lbutlr" writes: > On 1 Feb 2018, at 22:39, Olivier wrote: >> A failing connection:AMTP authentication: >> Jan 29 16:44:57 fbsd63 postfix/smtpd[93113]: connect from >> unknown[118.174.201.202] > > >> A successful SMTP authentication >> >> Jan

Upgrade unbound resolver to 1.6.8 if used for DANE

If you're using unbound as your local DNSSEC-validating resolver and have enabled DANE, an issue is resolved in unbound 1.6.8 where NSEC records for wildcards could be misused for invalid denial-of-existence proofs. See:

Re: Postfix upgrade breaks emails accounts from Mac OS X

> On Feb 3, 2018, at 1:21 PM, Karol Augustin wrote: > > I have few people connecting using Macs. I had similar issue when I > upgraded libssl to 1.1.0f-4 all of them couldn't connect as they are > still using TLS 1.0. I had to temporarily downgrade to 1.1.0f-3 until > the

Re: Postfix upgrade breaks emails accounts from Mac OS X

d similar issue when I upgraded libssl to 1.1.0f-4 all of them couldn't connect as they are still using TLS 1.0. I had to temporarily downgrade to 1.1.0f-3 until the problem was fixed in 1.1.0g-1. The problem was that developers decided to disable TLS1.0, which impacted a lot of things. My point is: a

Re: Postfix upgrade breaks emails accounts from Mac OS X

On 1 Feb 2018, at 22:39, Olivier wrote: > A failing connection:AMTP authentication: > Jan 29 16:44:57 fbsd63 postfix/smtpd[93113]: connect from > unknown[118.174.201.202] > A successful SMTP authentication > > Jan 30 17:52:38 fbsd63 postfix/smtpd[15674]: connect

Re: Postfix upgrade breaks emails accounts from Mac OS X

On 1 Feb 2018, at 21:31, Olivier olivier.nic...@cs.ait.ac.th> wrote: > Is that a know problem? Is there a fix? It is not. I have a postfix 3.2 install and primary use Macs to access it. Works fine one new and old accounts. However, this sounds like a dovecot issue, not a postfix issue. And you

Re: Postfix upgrade breaks emails accounts from Mac OS X

> On Feb 2, 2018, at 12:39 AM, Olivier wrote: > >> You've also not explained what you mean by deleting and recreating the >> account. > > I am not a Mac user, but from the Mail app, select Files/Account and > remove the account that makes problem and recreate it

Re: Postfix upgrade breaks emails accounts from Mac OS X

Viktor Dukhovni writes: >> On Feb 2, 2018, at 12:03 AM, Olivier wrote: >> >> I apologize for being abiguous. It is a problem of authentication to >> SMTP (they have no problem with IMAP). And the certificate has not >> changed (same

Re: Postfix upgrade breaks emails accounts from Mac OS X

> On Feb 2, 2018, at 12:03 AM, Olivier wrote: > > I apologize for being abiguous. It is a problem of authentication to > SMTP (they have no problem with IMAP). And the certificate has not > changed (same machine, same name, same file); and cyrus saslauthd has > not

Re: Postfix upgrade breaks emails accounts from Mac OS X

pgraded my postfix server from 2.11.6 to 3.2.3_1. >> >> Postfix server runs on a FreeBSD OS. The upgrade was seamless for all >> the users except the users connecting from a Mac: >> >> - a Mac that never used the Mail app could connect immediately to >> posftix SMT

Re: Postfix upgrade breaks emails accounts from Mac OS X

> On Feb 1, 2018, at 11:31 PM, Olivier <olivier.nic...@cs.ait.ac.th> wrote: > > I apologize if tht has already been posted, but I could not find any > reference. > > I recently upgraded my postfix server from 2.11.6 to 3.2.3_1. > > Postfix server runs on a FreeBS

Postfix upgrade breaks emails accounts from Mac OS X

Hi, I apologize if tht has already been posted, but I could not find any reference. I recently upgraded my postfix server from 2.11.6 to 3.2.3_1. Postfix server runs on a FreeBSD OS. The upgrade was seamless for all the users except the users connecting from a Mac: - a Mac that never used

Re: Upgrade to -3.2.5: permissions question

ou don't really need to do the recursive chown at > all. Since we have > > $queue_directory:d:root:-:755:uc Unfortunately, the recursion is needed, if a new package or a system upgrade changes the mail_owner, with already queued mail then having incorrect ownership. Hence the use of "set-permiss

Re: Upgrade to -3.2.5: permissions question

er owner would be if root changed it. Do we want postfix to "fix" things in that case? Maybe as a last resort... but as part of the standard upgrade procedure?

Re: Upgrade to -3.2.5: permissions question

> On Jan 29, 2018, at 12:21 PM, Michael Orlitzky wrote: > > My question is, can't the $mail_owner -- who knows that this is going to > take place eventually -- throw a hard link into the active queue that > points to a sensitive file? Proof of concept: > > $ sudo su

Re: Upgrade to -3.2.5: permissions question

On 01/29/2018 12:25 PM, Joris (ideeel) wrote: > > Doesnt postfix use proxymap for that? > http://www.postfix.org/proxymap.8.html > For what? I'm wondering whether or not the upgrade procedure is safe w.r.t. the $mail_owner user.

Re: Upgrade to -3.2.5: permissions question

On 01/28/2018 01:53 PM, Viktor Dukhovni wrote: > > You're not supposed to do this "by hand". Instead, when upgrading from > source, run: > > # postfix set-permissions upgrade-configuration > How sensitive is the $mail_owner account? From what I gather, the s

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Wietse Venema wrote: Please tell the maintainer that it they need to run the command, not the user. Wietse, I'll do this. Thanks, Rich

Re: Upgrade to -3.2.5: permissions question

Rich Shepard: > On Sun, 28 Jan 2018, Wietse Venema wrote: > > > You're not supposed to chown the files. That is part of the Postfix > > installation/upgrade process. If you use some non-Postfix > > installation/upgrade procedure, then that is broken. > > Wietse,

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Viktor Dukhovni wrote: When upgrading from an older postfix version, make sure the variables such as html_directory and readme_directory in /etc/postfix/main.cf point to the new location. These can also be fixed later, afterwards make sure to run: postfix

Re: Upgrade to -3.2.5: permissions question

d run "postfix set-permissions" and perform some equivalent of "postfix upgrade-configuration". Punting this step to the user is wrong: http://slackbuilds.org/repository/14.2/network/postfix/ ... When upgrading from an older postfix version, make sure the variables such as

Re: Upgrade to -3.2.5: permissions question

Rich Shepard: >postdrop still is a group. What I had neglected in my post-installation > notes was to change the group to postdrop for those two scripts prior to > running set-gid on them. You're not supposed to chown the files. That is part of the Postfix installation/upgrade proces

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Viktor Dukhovni wrote: Note that "make; make upgrade" would normally take care of this, perhaps you're doing something else (needlessly complicated)? Viktor, I use the SlackBuilds.org build script (as I do for all my installations and upgrades). Also s

Re: Upgrade to -3.2.5: permissions question

> On Jan 28, 2018, at 2:08 PM, Rich Shepard <rshep...@appl-ecosys.com> wrote: > > On Sun, 28 Jan 2018, Viktor Dukhovni wrote: > >> # postfix set-permissions upgrade-configuration Note that "make; make upgrade" would normally take care of this, perhaps you'r

Re: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, Viktor Dukhovni wrote: # postfix set-permissions upgrade-configuration Viktor, I thought there was a procedure for post-upgrade configuration but had forgotten where I had seen it. Thanks very much for the information. It now resides where I'll see it (and use

Re: Upgrade to -3.2.5: permissions question

've not seen these warnings in prior upgrades and would appreciate > learning what I need to change to remove them. You're not supposed to do this "by hand". Instead, when upgrading from source, run: # postfix set-permissions upgrade-configuration -- -- Viktor.

RE: Upgrade to -3.2.5: permissions question

On Sun, 28 Jan 2018, robert.wo...@robertwolfe.org wrote: I would first check and see if group "postdrop" exists. Then, if so, I would recommend running a "chown root:postdrop" on these files. But, of course, YMMV. Robert, postdrop still is a group. What I had neglected in my

RE: Upgrade to -3.2.5: permissions question

Of Rich Shepard Sent: Sunday, January 28, 2018 12:12 PM To: postfix-users@postfix.org Subject: Upgrade to -3.2.5: permissions question I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop and /usr/sbin/postqueue were set gid: -rwxr-sr-x 1 root root 13888 Jan 28 08:58 /usr/sbi

Upgrade to -3.2.5: permissions question

I just upgraded from 3.2.4 to 3.2.5 and ensured that /usr/sbin/postdrop and /usr/sbin/postqueue were set gid: -rwxr-sr-x 1 root root 13888 Jan 28 08:58 /usr/sbin/postdrop* -rwxr-sr-x 1 root root 18012 Jan 28 08:58 /usr/sbin/postqueue* Yet, when I start postfix I see these messages: Jan

Re: postfix upgrade-configuration

Postfix as distributed by me has never nagged about obsolete 'access' files, and I suggest that any complaints about such behavior are directed at the downstream maintainer who introduced that behavior. Wietse

Re: postfix upgrade-configuration

> /usr/local/etc/postfix/generic /usr/local/etc/postfix/relocated >> /usr/local/etc/postfix/transport /usr/local/etc/postfix/virtual > > What is the above list of pathnames? Is that output from 'postconf > upgrade-configuration' Yes. > I frequently install Postfix on

Re: postfix upgrade-configuration

> On Jan 2, 2018, at 12:24 PM, Wietse Venema wrote: > > I frequently install Postfix on a development machine, and I would > certainly have noticed messages about an obsolete 'access' file > (the access file on my development machine dates from 2005). Indeed there have

Re: postfix upgrade-configuration

viously but have now installed the current build: > > postfix 3.3-20171229: > /usr/local/etc/postfix/aliases /usr/local/etc/postfix/canonical > /usr/local/etc/postfix/generic /usr/local/etc/postfix/relocated > /usr/local/etc/postfix/transport /usr/local/etc/postfix/vir

Re: postfix upgrade-configuration

On 1 Jan 2018, at 11:18, Wietse Venema wie...@porcupine.org> wrote: > > @lbutlr: >> On 31 Dec 2017, at 16:41, @lbutlr wrote: >>> Perhaps "are no longer part of the default Postfix install. If you are = >> not using them, they may be removed."? > > Per my previous email,

Re: postfix upgrade-configuration

/postfix/virtual % pwd /home/wietse/postfix-3.3-20171229 % make -j8 ... % su Password: # make upgrade ... Skipping /usr/local/doc/postfix/trivial-rewrite.8.html... Skipping /usr/local/doc/postfix/verify.8.html... Skipping /usr/local/doc/postfix/virtual.5.html... Skipping /usr/local/doc/postfix/virtual

  1   2   3   4   5   >