Extra listener for client cert ?
Is it possible to, and (if yes) has anyone had experience with setting up an extra listener that requires client certs. The problem I've got is I still need to support Outlook clients. Fortunately these are located in fixed locations on desktop computers. Meanwhile, I would like to harden the configuration for road warriors who are all using devices and OSs that play nicer with client certs than Outlook does (well, Outlook doesn't play at all !). So I was thinking of opening 993 on a seperate IP address with that listener requiring client certificates. The alternative is, of course a VPN, which is still under consideration as an option. But even then, with the security onion, I'd still rather have both :) ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
My understanding was that OX were hoping for a 6-figure sum, or, at best, a high 5-figure. Certainly as far as I am aware nothing was ever going to be on the table for 4-figures or below. If sales have changed their mind and introduced affordable options for non-large-scale deployments then that’s great. But I know at least 10 people who all had the same experience as me, $ or nothing. On Thu, Jun 27, 2024 at 09:33, Aki Tuomi via dovecot wrote: Although things do change in our sales too and things are not set in stone. There are some floor limit, but I know that megabucks are not needed to buy pro licenses. Aki > On 27/06/2024 11:03 EEST Laura Smith via dovecot wrote: > > > Perhaps try reading my last post Scott. > > Perhaps especially the bit where I said OX were offered money but they were > not interested without megabucks being spent. > > As others have said, take your cheap, unsubstatiated, attacks elsewhere chum. > > > > On Wednesday, 26 June 2024 at 21:24, Scott Q. via dovecot > wrote: > > > What's her point really ? That someone owes her up to date, > > FREE, secure software that she wants to use in a commercial setting > > ? > > > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
Perhaps try reading my last post Scott. Perhaps especially the bit where I said OX were offered money but they were not interested without megabucks being spent. As others have said, take your cheap, unsubstatiated, attacks elsewhere chum. On Wednesday, 26 June 2024 at 21:24, Scott Q. via dovecot wrote: > What's her point really ? That someone owes her up to date, > FREE, secure software that she wants to use in a commercial setting > ? > ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
> Why do you care about the repo then ? Use the patch locally, > publish it, etc. You care about OpenSSL 3.0 compatibility right ? What > do you care if it's in the public tree or not. Because Aki has been shouting from the rooftops here that "beware, its not that easy, Dovecot crashes with OpenSSL 3.0". Aki has seen the OpenSSL 3 code already present in Debian (and Ubuntu and Fedora, its the same code) and supposedly that causes crashes. I'm sure the people who submitted code to the Fedora tree are much better programmers than I am, and if their efforts are not good enough, then, well... So, if we rephrase it, Aki is effectively telling people not to waste their time trying to patch OpenSSL 3.0 compatibility into 2.3 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
I suggest you descent rapidly off your high horse Scott, for two reasons: 1. I know people how have approached OpenXChange for commercial Dovecot support. TL;DR OpenXChange are basically not interested unless you're going to spend the big-bucks (i.e. if you're not a major ISP/Telco or something, forget about it). 2. As Aki has demonstrated with his denigration of the 2.3 patches in the Debian tree, they are clearly not particularly interested in contributions to make 2.3 OpenSSL 3.0 compatible. 3. Perhaps most importantly, As Aki has stated, they have no intention in making 2.3 OpenSSL 3.0 compatible ... ergo they would never merge my patch into the tree ... ergo it will never be on the Dovecot repo ... ergo I would have wasted my time. On Wednesday, 26 June 2024 at 14:47, Scott Q. wrote: > Hi Laura, > I understand your frustration but if you are relying on Dovecot for a > commercial solution, I believe your anger is misguided. The open source > project has no duty nor do they have to guarantee anything. Open source means > everyone can contribute, but in this case, only one major contributor exists. > > My advice for anyone facing similar frustrations is to contribute the proper > code to 2.3 to make it compatible with OpenSSL 3.0. Failing that, you can > hire competent programmers and have them contribute the code to the public > GitHub repository. > > No, I don't work for OpenXChange but I do maintain a few open source projects > and am accustomed to people's expectations to get commercial grade > software...for free. > > Cheers > > On Wednesday, 26/06/2024 at 08:34 Laura Smith via dovecot wrote: > > > You are conflating OS with packages. I don't think you'll find any OS > > making promises about packages. > > > > And even if it were the case, you are expecting a community patch based on > > what exactly ? OpenSSL are not releasing the code to non-premium customers, > > and as Aki has repeatedly told us here, OpenSSL 3.0 is vastly different to > > 1.1.1, so its not like you can expect to magically invent patch based on > > the OpenSSL 3.0 code (even if it may be true for a limited number of > > circumstances, it won't be true for all 1.1.1 patches). > > > > The sensible thing to do is to run a current OS with a current version of > > OpenSSL, anything else is wishful thinking based on excess expectations, > > frankly. > > > > > > On Wednesday, 26 June 2024 at 13:11, Lucas Rolff > > wrote: > > > > > They likely do not, but vulnerabilities reported are also patched for the > > > duration of the OS lifecycle. With or without premium access. Since > > > that's what the OS has committed to, unless they pull a redhat and > > > deprecate an OS before initial EOL date. > > > > > > Sent from Outlook for iOS > > > > > > From: Laura Smith > > > Sent: Wednesday, June 26, 2024 2:06:44 PM > > > To: Lucas Rolff > > > Cc: Aki Tuomi ; Laura Smith via dovecot > > > ; Michael > > > Subject: Re: Debian Bookworm packages, please ! > > > > > > So you're saying other operating systems magically get access to OpenSSL > > > premium ? I somehow doubt it. > > > > > > > > > > > > > > > On Wednesday, 26 June 2024 at 13:01, Lucas Rolff > > > wrote: > > > > > > > That Debian doesn't patch their LTS releases properly like other > > > > operating systems, should probably be brought up with the Debian > > > > release and security teams. > > > > > > > > Sent from Outlook for iOS > > > > > > > > From: Laura Smith via dovecot > > > > Sent: Wednesday, June 26, 2024 1:31:48 PM > > > > To: Aki Tuomi > > > > Cc: Laura Smith via dovecot ; Michael > > > > > > > > Subject: Re: Debian Bookworm packages, please ! > > > > > > > > The fundamental problem here is that this turns into a security > > > > problem, which in 2024 is not a nice thing to have. > > > > > > > > Yes, theoretically I could run the previous Debian release, 11 Bullseye > > > > which is now EOL but in LTS until 2026. > > > > > > > > However, the OpenSSL delivered with Bullseye is 1.1.1. Any LTS patches > > > > delivered by Debian are based on public patches, so basically there > > > > will be no OpenSSL patches because OpenSSL moved 1.1.1 to premium > > > > support only, *INCLUDING* security patches, as described on thei
Re: Debian Bookworm packages, please !
You are conflating OS with packages. I don't think you'll find any OS making
promises about packages.
And even if it were the case, you are expecting a community patch based on what
exactly ? OpenSSL are not releasing the code to non-premium customers, and as
Aki has repeatedly told us here, OpenSSL 3.0 is vastly different to 1.1.1, so
its not like you can expect to magically invent patch based on the OpenSSL 3.0
code (even if it may be true for a limited number of circumstances, it won't be
true for all 1.1.1 patches).
The sensible thing to do is to run a current OS with a current version of
OpenSSL, anything else is wishful thinking based on excess expectations,
frankly.
On Wednesday, 26 June 2024 at 13:11, Lucas Rolff wrote:
> They likely do not, but vulnerabilities reported are also patched for the
> duration of the OS lifecycle. With or without premium access. Since that's
> what the OS has committed to, unless they pull a redhat and deprecate an OS
> before initial EOL date.
>
> Sent from Outlook for iOS
>
> From: Laura Smith
> Sent: Wednesday, June 26, 2024 2:06:44 PM
> To: Lucas Rolff
> Cc: Aki Tuomi ; Laura Smith via dovecot
> ; Michael
> Subject: Re: Debian Bookworm packages, please !
>
> So you're saying other operating systems magically get access to OpenSSL
> premium ? I somehow doubt it.
>
>
>
>
> On Wednesday, 26 June 2024 at 13:01, Lucas Rolff wrote:
>
> > That Debian doesn't patch their LTS releases properly like other operating
> > systems, should probably be brought up with the Debian release and security
> > teams.
> >
> > Sent from Outlook for iOS
> >
> > From: Laura Smith via dovecot
> > Sent: Wednesday, June 26, 2024 1:31:48 PM
> > To: Aki Tuomi
> > Cc: Laura Smith via dovecot ; Michael
> >
> > Subject: Re: Debian Bookworm packages, please !
> >
> > The fundamental problem here is that this turns into a security problem,
> > which in 2024 is not a nice thing to have.
> >
> > Yes, theoretically I could run the previous Debian release, 11 Bullseye
> > which is now EOL but in LTS until 2026.
> >
> > However, the OpenSSL delivered with Bullseye is 1.1.1. Any LTS patches
> > delivered by Debian are based on public patches, so basically there will be
> > no OpenSSL patches because OpenSSL moved 1.1.1 to premium support only,
> > *INCLUDING* security patches, as described on their website ("It will no
> > longer be receiving publicly available security fixes after that date")
> > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/index.html.
> >
> > Meanwhile, we are being spoonfed FUD/semi-FUD about the Debian provided 2.3
> > package. "be careful it's broken" is not a warning a good sysadmin takes
> > lightly.
> >
> > Meanwhile, if we're lucky, we might get 2.4 this side of Christmas 2024.
> >
> > Its all a bit of a mess. Its all a bit worrying.
> >
> > Meanwhile alternatives are few and far between, and I suspect Dovecot knows
> > that ! The Dovecot community are left between the proverbial rock and a
> > hard place.
> >
> > Cyrus is now dependent on the commercial goodwill of FastMail, which brings
> > thoughts of comparisons with Dovecot and OpenXChange.
> >
> > Stalwart, whilst extraordinarily promising, needs another year or so of
> > development to reach v1 and mature the code.
> > ___
> > dovecot mailing list -- dovecot@dovecot.org
> > To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
To support my prior comment, FreeBSD are quite clear about it (see below
explicit statement on one of their previous Security Advisories) and I expect
it to be the same with Debian and any other FOSS operating system.
Security Advisory FreeBSD-SA-20:33.openssl CVE-2020-1971: "However, the OpenSSL
project is only giving patches for that version to premium support contract
holders. The FreeBSD project does not have access to these patches"
On Wednesday, 26 June 2024 at 13:01, Lucas Rolff via dovecot
wrote:
> That Debian doesn't patch their LTS releases properly like other operating
> systems, should probably be brought up with the Debian release and security
> teams.
>
> Sent from Outlook for iOShttps://aka.ms/o0ukef
>
> ____
> From: Laura Smith via dovecot dovecot@dovecot.org
>
> Sent: Wednesday, June 26, 2024 1:31:48 PM
> To: Aki Tuomi aki.tu...@open-xchange.com
>
> Cc: Laura Smith via dovecot dovecot@dovecot.org; Michael m...@hemathor.de
>
> Subject: Re: Debian Bookworm packages, please !
>
> The fundamental problem here is that this turns into a security problem,
> which in 2024 is not a nice thing to have.
>
> Yes, theoretically I could run the previous Debian release, 11 Bullseye which
> is now EOL but in LTS until 2026.
>
> However, the OpenSSL delivered with Bullseye is 1.1.1. Any LTS patches
> delivered by Debian are based on public patches, so basically there will be
> no OpenSSL patches because OpenSSL moved 1.1.1 to premium support only,
> INCLUDING security patches, as described on their website ("It will no longer
> be receiving publicly available security fixes after that date")
> https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/index.html.
>
> Meanwhile, we are being spoonfed FUD/semi-FUD about the Debian provided 2.3
> package. "be careful it's broken" is not a warning a good sysadmin takes
> lightly.
>
> Meanwhile, if we're lucky, we might get 2.4 this side of Christmas 2024.
>
> Its all a bit of a mess. Its all a bit worrying.
>
> Meanwhile alternatives are few and far between, and I suspect Dovecot knows
> that ! The Dovecot community are left between the proverbial rock and a hard
> place.
>
> Cyrus is now dependent on the commercial goodwill of FastMail, which brings
> thoughts of comparisons with Dovecot and OpenXChange.
>
> Stalwart, whilst extraordinarily promising, needs another year or so of
> development to reach v1 and mature the code.
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
So you're saying other operating systems magically get access to OpenSSL
premium ? I somehow doubt it.
On Wednesday, 26 June 2024 at 13:01, Lucas Rolff wrote:
> That Debian doesn't patch their LTS releases properly like other operating
> systems, should probably be brought up with the Debian release and security
> teams.
>
> Sent from Outlook for iOS
>
> From: Laura Smith via dovecot
> Sent: Wednesday, June 26, 2024 1:31:48 PM
> To: Aki Tuomi
> Cc: Laura Smith via dovecot ; Michael
> Subject: Re: Debian Bookworm packages, please !
>
> The fundamental problem here is that this turns into a security problem,
> which in 2024 is not a nice thing to have.
>
> Yes, theoretically I could run the previous Debian release, 11 Bullseye which
> is now EOL but in LTS until 2026.
>
> However, the OpenSSL delivered with Bullseye is 1.1.1. Any LTS patches
> delivered by Debian are based on public patches, so basically there will be
> no OpenSSL patches because OpenSSL moved 1.1.1 to premium support only,
> *INCLUDING* security patches, as described on their website ("It will no
> longer be receiving publicly available security fixes after that date")
> https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/index.html.
>
> Meanwhile, we are being spoonfed FUD/semi-FUD about the Debian provided 2.3
> package. "be careful it's broken" is not a warning a good sysadmin takes
> lightly.
>
> Meanwhile, if we're lucky, we might get 2.4 this side of Christmas 2024.
>
> Its all a bit of a mess. Its all a bit worrying.
>
> Meanwhile alternatives are few and far between, and I suspect Dovecot knows
> that ! The Dovecot community are left between the proverbial rock and a
> hard place.
>
> Cyrus is now dependent on the commercial goodwill of FastMail, which brings
> thoughts of comparisons with Dovecot and OpenXChange.
>
> Stalwart, whilst extraordinarily promising, needs another year or so of
> development to reach v1 and mature the code.
> ___
> dovecot mailing list -- dovecot@dovecot.org
> To unsubscribe send an email to dovecot-le...@dovecot.org
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
The fundamental problem here is that this turns into a security problem, which
in 2024 is not a nice thing to have.
Yes, theoretically I could run the previous Debian release, 11 Bullseye which
is now EOL but in LTS until 2026.
However, the OpenSSL delivered with Bullseye is 1.1.1. Any LTS patches
delivered by Debian are based on public patches, so basically there will be no
OpenSSL patches because OpenSSL moved 1.1.1 to premium support only,
*INCLUDING* security patches, as described on their website ("It will no longer
be receiving publicly available security fixes after that date")
https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/index.html.
Meanwhile, we are being spoonfed FUD/semi-FUD about the Debian provided 2.3
package. "be careful it's broken" is not a warning a good sysadmin takes
lightly.
Meanwhile, if we're lucky, we might get 2.4 this side of Christmas 2024.
Its all a bit of a mess. Its all a bit worrying.
Meanwhile alternatives are few and far between, and I suspect Dovecot knows
that ! The Dovecot community are left between the proverbial rock and a hard
place.
Cyrus is now dependent on the commercial goodwill of FastMail, which brings
thoughts of comparisons with Dovecot and OpenXChange.
Stalwart, whilst extraordinarily promising, needs another year or so of
development to reach v1 and mature the code.
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
> > could you please elaborate on this? are there any security issues with > > using the debian version? what are the problems you are implicating with > > your above statement, that it's 'not fully working either'? > > > > greetings... > > > It can sometimes crash. > > Aki Does Dovecot even care about its open-source community any more ? We know you've opted to focus on your commercial efforts, that's fine, that's you prerogative. But at the moment it is feeling like "go closed source or show some more feeling towards the open-source side". I mean seriously, "it can sometimes crash", is that all ? Does it mean people should not use the Debian packages full stop ? Does it mean people can use the Debian packages but not certain configurations ? "it can sometimes crash" is basically the same thing as not bothering to post anything at all. shrug. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
> > We can already see that the Debian/RedHat patched 2.3 which is offered is > broken because there is more than just "making it compile" with things like > OpenSSL3, and yes, I can appreciate that it's not fully broken, but it's not > fully working either. Yeah, that's sort of what's holding me back from just blindly installing the Debian distro package. Whilst I'm no expert, I did spot some OpenSSL3 mentions looking briefly through the Debian bug tracker. Do you have any opinion on the FreeBSD dovecot ? I'd rather stick with Debian but having a working mailserver on a current version of an OS is a somewhat higher importance. If Stalwart was more mature than it currently is, I would have moved over to that already. Sadly that will have to wait for the next round of server refreshes in a few years time. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
On Tuesday, 25 June 2024 at 15:06, Aki Tuomi via dovecot wrote: > > On 25/06/2024 16:58 EEST Laura Smith via dovecot dovecot@dovecot.org wrote: > > > > Debian Bookworm (12) was released June 2023. > > > > It is therefore somewhat disappointing to see no Bookworm packages in > > https://repo.dovecot.org/ce-2.3-latest/debian/ > > > We are going to add support for Debian Bookworm to Dovecot 2.4 version. > > Is there any more concrete news on the mysterious 2.4 ? I found an old post from you from 2023 which said "soon" ? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Debian Bookworm packages, please !
Debian Bookworm (12) was released June 2023. It is therefore somewhat disappointing to see no Bookworm packages in https://repo.dovecot.org/ce-2.3-latest/debian/ ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Replicator service in Dovecot 2.4 CE
> Are you completely removing support for 'replication-with-dsync' starting > from version 2.4? > Are there any plans for built-in tools to implement an active/active or > active/passive cluster in the community edition? kv See the long discussion "the future of SIS" (https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/2CPFZ5OXVA2QYHQBWH7P6QM4J4D7FEYE/) ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
--- Original Message --- On Tuesday, October 17th, 2023 at 15:27, Filip Hanes via dovecot wrote: > Other S3 implementation is Minio on top of any posix filesystem - you can > choose which fills your needs. Minio is great in general, the only thing I would say it its a little bit weird to setup if you're in a VM environment. It was really based around physical hosts, so you need to replicate that on VMs (i.e. 3 x virtual disks per VM so that the error encoding stuff works just like it would on physical hosts). But certainly compared to Ceph its a lot easier on the sysadmin side ! ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
--- Original Message --- On Tuesday, October 17th, 2023 at 06:46, Jean-Daniel Dupas wrote: > > If you are using Ubuntu, OpenZFS is readily available, and support > deduplication natively. I thought nobody sane actually used ZFS dedup because it eats RAM for breakfast, lunch and dinner ? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: The future of SIS
> Is s3 not to slow for this? > I think the clue is in the name "s3-compatible". Clearly calling out to "real" (AWS) S3 would be a non-starter. But a local installation of something like CEPH, MinIO or whatever on the same LAN ? I'd think that should be workable, no ? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: The future of SIS
> > Interesting, nice they use this rust, I am curious how they define this > scaling. What I don't get is why are they messing with smtp. I always get a > bad feeling when a company is trying to do everything. Good they are using rust and even better they've had an independent security audit (https://www.stalw.art/blog/security-audit). On the scaling side, maybe see the storage page ? (https://www.stalw.art/docs/storage/overview). The metadata is stored in a database which can be replicated. And the mails themselves can be stored in filesystem or "S3-compatible" storage, and so there are scaling options there too ? But clearly some experimentation is required to see how it works in practice. Are they messing with SMTP ? As I understand it its an IMAP/JMAP server. And (like Dovecot) it has LMTP for getting mail into it from e.g. Postfix ? From my reading of the docs it looks like SMTP is only there if you don't want to use LMTP to get mail into it ? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
> > Well, so Laura is absolutely right ... > > > "Things like dsync will be GONE in the community version." > > That's not right, dsync is still there. Replicator is not, so dsync can't be > triggered automatically by dovecot after changes to the mailbox Well, to be fair : 1. I said what I said based on the video. And the video seemed pretty clear cut to me ? 2. Its not there in the form that many (most ?) people would use it for (i.e. with Replicator). 3. Then Aki came along and said "there is no hidden cache of code going into 3.0 that will not be open source". When the video kind of makes it clear 3.0 Pro with all its new features (e.g. multi-server) is very much going to be a closed-source job. And that the present open-source version is, just like they say in the video, is going to be "supported for single-server use only". Therefore the waters are still very much muddy overall. The dsync question might well have now been clarified somewhat. But the rest of "how much 3.0 Pro will we see in open source" ? If we're being generous we would say muddy waters, but my gut feeling is the video made clear their direction of travel in that the present Open Source version will continue as-is with updates and support, bu won't be getting any of the fancy new features and functionality that 3.0 Pro is. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
> > If that is the case, well then I have to find another way to keep mails in > sync between 2 mailservers. Hope the community will find a new solution! > I have been keeping one eye on Stalwart (https://stalw.art/) for a while now. I haven't tested it as yet, but I'm very much tempted to get a test instance up and running. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
FUD ? I knew someone would accuse me of that which is why I linked to the video from the horse's mouth, I transcribe what the speaker said: "there will be an open source version, but that open source version will be maintained for single server use only. we are actually taking out anything any actually kinda' involves multiple servers, dsync replication and err some other stuff. so dovecot will be a fully-featured single node server" --- Original Message --- On Friday, October 13th, 2023 at 19:37, Aki Tuomi wrote: > Dear Laura, please don't spread FUD that you made up. > > Dsync is not going anywhere, and we are not close-sourcing Dovecot Core. > There is not a trove of code going into Dovecot 3.0 that "never sees the > daylight". > > Thank you, > Aki > > > On 13/10/2023 21:10 EEST Laura Smith via dovecot dovecot@dovecot.org wrote: > > > > TL;DR If you are a Dovecot Community user, don't waste your time reading > > the Dovecot Pro release notes. > > > > To expand: > > > > I think you have to understand that lots of things that are going into > > Dovecot 3 (Pro) will never see the light of day in the community edition. > > > > In addition, Dovecot have publicly quite plainly announced in public that > > they are actively removing all multi-server related functionality from > > Dovecot Community. > > > > I don't think the community has quite yet grasped it. Things like dsync > > will be GONE in the community version. > > > > If you don't believe me, look at this video, about 15 minutes in: > > https://youtu.be/s-JYrjCKshA?feature=shared&t=912 > > > > --- Original Message --- > > On Friday, October 13th, 2023 at 17:15, Sebastian Marsching > > sebast...@marsching.com wrote: > > > > > Hi, > > > > > > I am currently in the process of planning a new deployment of Dovecot. I > > > was planning to use mdbox or sdbox with “mail_attachment_fs = sis posix”, > > > but I stumbled across the following notice in the documentation for > > > Dovecot 3.0 > > > ___ > > > dovecot mailing list -- dovecot@dovecot.org > > > To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
TL;DR If you are a Dovecot Community user, don't waste your time reading the Dovecot Pro release notes. To expand: I think you have to understand that lots of things that are going into Dovecot 3 (Pro) will never see the light of day in the community edition. In addition, Dovecot have publicly quite plainly announced in public that they are actively removing all multi-server related functionality from Dovecot Community. I don't think the community has quite yet grasped it. Things like dsync will be GONE in the community version. If you don't believe me, look at this video, about 15 minutes in: https://youtu.be/s-JYrjCKshA?feature=shared&t=912 --- Original Message --- On Friday, October 13th, 2023 at 17:15, Sebastian Marsching wrote: > Hi, > > I am currently in the process of planning a new deployment of Dovecot. I was > planning to use mdbox or sdbox with “mail_attachment_fs = sis posix”, but I > stumbled across the following notice in the documentation for Dovecot 3.0 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Outlook and IMAP Flags
Hi I've tried searching the internet, but the only thing I can find is a post on a MIcrosoft forum where a Microsoft reps claims flags are not supported on IMAP (I thought it was an RFC3501 feature ?). Anyway, I have a user who has Outlook/Windows on desktop and iOS (iPhone/iPad) for remote. On the iOS devices, the user can happily set flags against messages with zero issues. And indeed, when they set these flags, they are shown in Outlook. However if they attempt to set the flag in Outlook, nothing happens. Outlook continues showing the message as if it was unflagged. Any ideas ? Laura ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Outlook 2019 and push notifications
Is there some secret config sauce I'm unaware of to get IMAP push notifications
working with Outlook ?
My present situation is that non-Outlook users (e.g. Apple iOS, Apple Mail
etc.) work perfectly with the config below. New emails get pushed, deletes get
reflected, all is happy in the world.
But with Outlook nothing. You send a user an email, nothing happens in their
inbox until you manually refresh by checking for new mails or waiting for the
auto-check to kick in (sometimes switching between IMAP folders also does the
trick).
I know Outlook has a long history of being a mess when it comes to standards
compliance, but surely it can't be this bad ?
doveconf -n :
# 2.3.18 (9dd8408c18): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.18 (0bc28b32)
# OS: Linux 5.10.0-11-amd64 x86_64 Debian 11.2 xfs
# Hostname: foobar.example.com
auth_verbose = yes
auth_verbose_passwords = sha1:7
doveadm_password = # hidden, use -P to show it
imap_capability = +SPECIAL-USE
imapc_features = rfc822.size fetch-headers fetch-bodystructure
imapc_port = 993
imapc_ssl = imaps
mail_location = maildir:/foo_data/mail/%d/%n/Maildir
mail_plugins = notify replication push_notification
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext imapsieve vnd.dovecot.imapsieve
namespace inbox {
inbox = yes
location =
mailbox "Deleted Messages" {
auto = no
special_use = \Trash
}
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
auto = subscribe
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = /etc/dovecot/local_sql_users.conf
driver = sql
}
plugin {
imapsieve_mailbox1_before = file:/etc/dovecot/imap_sieve/spam.sieve
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_name = Junk
imapsieve_mailbox2_before = file:/etc/dovecot/imap_sieve/ham.sieve
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_from = Junk
imapsieve_mailbox2_name = *
sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
sieve_pipe_bin_dir = /etc/dovecot/imap_sieve
sieve_plugins = sieve_imapsieve sieve_extprograms
}
protocols = imap lmtp sieve
service auth {
unix_listener /var/spool/postfix/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
vsz_limit = 2 G
}
service doveadm {
inet_listener {
port = 11867
ssl = yes
}
}
service imap-login {
process_min_avail = 5
service_count = 1
}
service lmtp {
process_min_avail = 5
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
user = foo_virtmail
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieves {
address =
port = 5190
ssl = yes
}
}
ssl = required
ssl_ca = was automatically rejected:%n%r
}
protocol imap {
mail_max_userip_connections = 20
mail_plugins = notify replication push_notification imap_sieve
}
Re: Received invalid SSL certificate: unable to get certificate CRL
--- Original Message --- On Monday, January 31st, 2022 at 06:24, Aki Tuomi wrote: > Markus Hi Laura, did you try this? Did it work? Aki Hi Aki Sorry, your mail got caught in spam. Tried it, it didn't work. So I just ended up using "-o imapc_ssl_verify=no".
Re: doveadm backup : Warning: Deleting mailbox GUID= is missing locally
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, January 27th, 2022 at 16:12, Sami Ketola wrote: > > On 27. Jan 2022, at 16.27, Laura Smith n5d9xq3ti233xiyif...@protonmail.ch > > wrote: > > > > Hi, > > > > As per the docs (https://wiki.dovecot.org/Tools/Doveadm/Sync) I'm presently > > running doveadm backup multiple times with a view to eventual server > > migration. > > > > I am seeing messages such as this: > > > > Warning: Deleting mailbox 'Junk': UID=1826 GUID= is missing locally > > this is probably a bug of some sort. Basically just means that Junk is > resynced completely and not just delta. Great. Thanks you for clarifying. > > > I also have a further question. It is not clear from the docs what the role > > of the "-R" flag is in relation to "doveadm backup" ? Surely by definition > > backup = remote -> local ? > > –R means reverse sync. Reverse direction. > So I should not be using "-R" with "doveadm backup" then ? For "-R" the docs say "will instead pull messages from the remote to the local storage." for "backup" the docs say "doveadm backup performs one-way synchronization" That's where I'm confused.
doveadm backup : Warning: Deleting mailbox GUID= is missing locally
Hi, As per the docs (https://wiki.dovecot.org/Tools/Doveadm/Sync) I'm presently running doveadm backup multiple times with a view to eventual server migration. I am seeing messages such as this: Warning: Deleting mailbox 'Junk': UID=1826 GUID= is missing locally Is it anything to worry about ? If so, how should I be dealing with it. I also have a further question. It is not clear from the docs what the role of the "-R" flag is in relation to "doveadm backup" ? Surely by definition backup = remote -> local ? Thanks ! Laura
Re: Received invalid SSL certificate: unable to get certificate CRL
‐‐‐ Original Message ‐‐‐ > > I thought that > > ssl_ca = > is worth a try. Does ssl_ca even apply to dsync/imapc ? Looking at the docs its all about client certificate authentication ? Something which does not apply to my environment, and even if it did, it would not apply to dsync/imapc because I am initiating the connection, not the remote end ?
Re: Received invalid SSL certificate: unable to get certificate CRL
For the benefit of list, I've decided to work-around the problem using: imapc_ssl_verify = no Obviously I still welcome suggestions as to how I can get dsync working with Let's Encrypt certificates and when OpenSSL validates "ok" but Dovecot does not (despite Dovecot supposedly falling-back to OpenSSL). For the record, I have done this sort of dsync before (i.e. "dsync backup" from source that has Let's Encrypt cert), I've never had a problem before, so I'm wondering if it's something peculiar to Dovecot 2.3.17.1 (whether a bug or a feature, it would be nice to know what's changed since I would have thought this sort of scenario should work "out of the box").
Re: Received invalid SSL certificate: unable to get certificate CRL
> just an idea, but maybe that's the problem?: > > https://doc.dovecot.org/configuration_manual/authentication/proxies/ > > "Note > > ssl_client_ca_dir or ssl_client_ca_file aren’t currently used for verifying > the > > remote certificate, although ideally they will be in a future Dovecot > version. For > > now you need to add the trusted remote certificates to ssl_ca." > Hi Markus Thanks for your suggestion, I have a couple of questions about it though. First, my understanding from the docs was that ssl_client_ca_* were override parameters and that in the absence of the parameters, Dovecot would default to using OpenSSL defaults ? (And building on that, as per my manual tests, you can see OpenSSL returns an "OK" on the validation). Second, I'm dealing with standard Let's Encrypt certs here, no private PKI certs here. Laura
Re: Received invalid SSL certificate: unable to get certificate CRL
Hi Zakaria Thank you for your suggestion. I don't think an out of date ca trust is the issue with me. I'm running Debian Bullseye (i.e. latest Debian release) and its fully up to date with all patches. I will look into your suggestion though. Laura ‐‐‐ Original Message ‐‐‐ On Monday, January 24th, 2022 at 21:29, Zakaria wrote: > Hi Laura, > > I dont know if it will work, but I came across similar issue with letsencrypt > using recent openssl, and it fails verifying with the same error message and > the following has resolved it for me. > > Try to run the following command against the client certificate full chain > and cert file:- > > openssl verify -CAfile fullchain1.pem cert1.pem > > if it did throw the same error then try verifying using the following updated > full chain with valid lets encrypt intermediary and root certificate, if it > will work. > > wget -O isrgrootx1.pem https://letsencrypt.org/certs/isrgrootx1.pem && > wget -O isrg-root-x1-cross-signed.pem > https://letsencrypt.org/certs/isrg-root-x1-cross-signed.pem && wget -O > lets-encrypt-r3.pem https://letsencrypt.org/certs/lets-encrypt-r3.pem && wget > -O lets-encrypt-r3-cross-signed.pem > https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem && cat > isrgrootx1.pem isrg-root-x1-cross-signed.pem lets-encrypt-r3.pem > lets-encrypt-r3-cross-signed.pem > combined_chain1.pem && dos2unix > combined_chain1.pem && rm -f lets-encrypt-r3*.* && rm -f isrg*.* > > If didnt then try to use updated ca bundle directly from OS using following > commands and reference it in verify certificates list > > ssl_client_ca_file = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem > ssl_verify_client_cert = yes > > On how to update, it depends on your OS, and the following works with me > > yum install ca-certificatesupdate-ca-trust > > Refer to > https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ > > Give it a try and if you found another solution please let me know, and good > luck. > > Zakaria > > On 24 Jan 2022 20:25, Laura Smith wrote: > > > I'm having a frustrating problem trying to use "doveadm sync" to pull mails > > off a server for migration purposes. > > > > # 2.3.17.1 (476cd46418): /etc/dovecot/dovecot.conf > > > > # Pigeonhole version 0.5.17.1 (a1a0b892) > > > > # OS: Linux 5.10.0-11-amd64 x86_64 Debian 11.2 > > > > I have tried both explicit "ssl_client_ca_dir = /etc/ssl/certs" and > > commenting it out (i.e. relying on OpenSSL default per the docs) > > > > I always get the same: > > > > Info: Received invalid SSL certificate: unable to get issuer certificate: > > /C=US/O=Internet Security Research Group/CN=ISRG Root X1 (check > > ssl_client_ca_* se > > > > ttings?) > > > > Received invalid SSL certificate: unable to get issuer certificate: > > /C=US/O=Internet Sec > > > > urity Research Group/CN=ISRG Root X1 (check ssl_client_ca_* settings?) - > > disconnecting > > > > openssl s_client -starttls imap -servername $name -connect $name:143 is > > happy though: > > > > --- > > > > Certificate chain > > > > 0 s:CN = > > > > i:C = US, O = Let's Encrypt, CN = R3 > > > > 1 s:C = US, O = Let's Encrypt, CN = R3 > > > > i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 > > > > 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 > > > > i:O = Digital Signature Trust Co., CN = DST Root CA X3 > > > > --- > > > > --- > > > > No client certificate CA names sent > > > > Peer signing digest: SHA256 > > > > Peer signature type: RSA-PSS > > > > Server Temp Key: X25519, 253 bits > > > > --- > > > > SSL handshake has read 4954 bytes and written 412 bytes > > > > Verification: OK > > > > --- > > > > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 > > > > Server public key is 2048 bit > > > > Secure Renegotiation IS NOT supported > > > > Compression: NONE > > > > Expansion: NONE > > > > No ALPN negotiated > > > > Early data was not sent > > > > Verify return code: 0 (ok) > > > > ---
Received invalid SSL certificate: unable to get certificate CRL
I'm having a frustrating problem trying to use "doveadm sync" to pull mails off a server for migration purposes. # 2.3.17.1 (476cd46418): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.17.1 (a1a0b892) # OS: Linux 5.10.0-11-amd64 x86_64 Debian 11.2 I have tried both explicit "ssl_client_ca_dir = /etc/ssl/certs" and commenting it out (i.e. relying on OpenSSL default per the docs) I always get the same: Info: Received invalid SSL certificate: unable to get issuer certificate: /C=US/O=Internet Security Research Group/CN=ISRG Root X1 (check ssl_client_ca_* se ttings?) Received invalid SSL certificate: unable to get issuer certificate: /C=US/O=Internet Sec urity Research Group/CN=ISRG Root X1 (check ssl_client_ca_* settings?) - disconnecting openssl s_client -starttls imap -servername $name -connect $name:143 is happy though: --- Certificate chain 0 s:CN = i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 4954 bytes and written 412 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ---
Re: Containerize dovecot?
‐‐‐ Original Message ‐‐‐ On Tuesday, August 24th, 2021 at 11:46 PM, William Edwards wrote: > I think the general concensus is that containerisation isn't always > > better than 'normal' VMs. 'Easy deployment & scaling' is also perfectly > > possible without containers. > Amen to that ! What's the old saying ? "Just because you can, doesn't mean you should !"
Re: Undefined symbols (macOS Big Sur Intel) during compiling, update
> It seems to use -L/Library/MWSrvrSrvcs/openssl/lib, does this contain some > broken libssl? Additional comment "/Library/MWSrvrSrvcs" looks like its some sort of third-party installation of OpenSSL, "/Library/MWSrvrSrvcs" is not present on any of my OS X boxes.
Re: Undefined symbols (macOS Big Sur Intel) during compiling, update
FYI Aki As of OS X 10.7 Apple anounced they would be phasing out OpenSSL in favour of Common Crypto (announced at their Developer Conference in 2011). The "Why?" is because OpenSSL do not offer API compatibility between versions which impeded upon Apple's ability to provide security updates without breaking developer's apps (more detailed explanation at https://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-technote-about-openssl-on) ‐‐‐ Original Message ‐‐‐ On Friday, August 13th, 2021 at 5:01 PM, Aki Tuomi wrote: > It seems to use -L/Library/MWSrvrSrvcs/openssl/lib, does this contain some > broken libssl? > > Aki > > > On 13/08/2021 19:00 Beosdoc beos...@hotmail.com wrote: > > > > If I remove the rpath from the makefile in the lib-ssl-iostream directory > > it will compile. This shouldn’t cause it not to compile. There are several > > directories that have rpath in the makefile. Also, putting --disable-rpath > > in the configure string doesn’t work. I also need rpath as the files are > > not in the standard path locations. > > > > > On Aug 4, 2021, at 12:30 PM, Beosdoc beos...@hotmail.com wrote: > > > > > > Hi, > > > > > > I’m trying to compile Dovecot 2.3.15 on a Intel Mac with Big Sur and > > > Xcode 12.5.1 with command line. I’ve compiled openSSL -1.1.1k in its own > > > directory and pointed dovecot to use that directory. I’m getting > > > undefined symbols during the linking (see below). I’ve been trying to > > > figure out what’s missing but not having any luck > > > > > > Here’s the configure: > > > > > > CPPFLAGS="-I/Library/MWSrvrSrvcs/openssl/include" > > > LDFLAGS="-L/Library/MWSrvrSrvcs/openssl/lib" ./configure > > > --prefix=/Library/MWSrvrSrvcs/dovecot --with-ssl=openssl --with-gnu-ld > > > --with-pgsql=auto --with-mysql=auto --with-sqlite=auto --with-gssapi=yes > > > --with-ldap=auto --with-solr=no --with-libwrap=auto --with-ioloop=no > > > --with-bzlib --with-zlib --with-notify=no --without-shared-libs > > > --sysconfdir=/Library/MWSrvrSrvcs/Mail/Config > > > --datadir=/Library/MWSrvrSrvcs/Mail/Data > > > > > > Here’s where it errors out: > > > > > > /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 > > > -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W > > > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > > > -Wchar-subscripts -Wformat=2 -Wbad-function-cast > > > -Wno-duplicate-decl-specifier -Wstrict-aliasing=2 -module -avoid-version > > > -L/Library/MWSrvrSrvcs/openssl/lib -o libssl_iostream_openssl.la -rpath > > > /Library/MWSrvrSrvcs/dovecot/lib/dovecot dovecot-openssl-common.lo > > > iostream-openssl.lo iostream-openssl-common.lo > > > iostream-openssl-context.lo istream-openssl.lo ostream-openssl.lo -lssl > > > -lcrypto > > > > > > libtool: link: gcc -o .libs/libssl_iostream_openssl.so -bundle > > > .libs/dovecot-openssl-common.o .libs/iostream-openssl.o > > > .libs/iostream-openssl-common.o .libs/iostream-openssl-context.o > > > .libs/istream-openssl.o .libs/ostream-openssl.o > > > -L/Library/MWSrvrSrvcs/openssl/lib -lssl -lcrypto -g -O2 > > > -fstack-protector-strong > > > > > > Undefined symbols for architecture x86_64: > > > > > > "_buffer_append", referenced from: > > > > > > _openssl_iostream_error in iostream-openssl-common.o > > > > > > _o_stream_ssl_sendv in ostream-openssl.o > > > > > > "_buffer_create_dynamic", referenced from: > > > > > > _o_stream_ssl_sendv in ostream-openssl.o > > > > > > "_buffer_delete", referenced from: > > > > > > _o_stream_ssl_flush_buffer in ostream-openssl.o > > > > > > "_buffer_free", referenced from: > > > > > > _o_stream_ssl_destroy in ostream-openssl.o > > > > > > "_buffer_get_writable_size", referenced from: > > > > > > _o_stream_ssl_sendv in ostream-openssl.o > > > > > > _o_stream_ssl_get_buffer_avail_size in ostream-openssl.o > > > > > > "_default_pool", referenced from: > > > > > > _openssl_iostream_set_error in iostream-openssl.o > > > > > > _openssl_iostream_bio_sync in iostream-openssl.o > > > > > > _openssl_iostream_handle_error in iostream-openssl.o > > > > > > _openssl_iostream_create in iostream-openssl.o > > > > > > _openssl_iostream_handshake in iostream-openssl.o > > > > > > _openssl_iostream_set_log_prefix in iostream-openssl.o > > > > > > _openssl_iostream_free in iostream-openssl.o > > > > > > ... > > > > > > "_i_debug", referenced from: > > > > > > _openssl_iostream_set_error in iostream-openssl.o > > > > > > _openssl_iostream_handle_error in iostream-openssl.o > > > > > > _openssl_iostream_handshake in iostream-openssl.o > > > > > > _openssl_info_callback in iostream-openssl.o > > > > > > _openssl_iostream_verify_client_cert in iostream-openssl.o > > > > > > _ssl_iostream_context_init_common in iostream-openssl-context.o > > > > > > _ssl_servername_callback in iostream-openssl-context.o > > > > > > ... > > > > > > "_i_error", referenced from: > > > > > > _openssl_iostream_bio_sync in iostream-openssl.o > > >
Re: Dovecot Debian repo instructions need updating
Also FYI further supporting detail: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861695 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877012
Re: Dovecot Debian repo instructions need updating
On Thursday, August 5th, 2021 at 4:06 PM, Lucas Castro wrote: > On 8/5/21 8:42 AM, Laura Smith wrote: > > > Re: > > https://doc.dovecot.org/installation_guide/dovecot_community_repositories/debian_packages/ > > > > The instructions need updating for two reasons: > > > > 1. Keep up to date with Debian releases > > (https://wiki.debian.org/DebianReleases), i.e. remove reference to 8.0 > > "Jessie" and replace with 10.0 "Buster". > > To "replace", I guess it should me added instruction for others versions. There is very little point supporting EOL systems. As per the table in the link I provided, 8.0 Jessie is EOL unless you are paying money to Debian for ELTS subscription. > Not (exactly) needed secure connection. Debian will check the package > > using gpg, > > Neither official repositories enforce secure connection. > > As you said "The key MUST be downloaded over secure connection" > > the key, not the package, the package must be signed by the key. > > I am not sure what the point you are trying to make here is ? There is no argument that what I am asking for MUST be done. The Debian link I referred to explains in much detaily WHY it is important.
Dovecot Debian repo instructions need updating
Re: https://doc.dovecot.org/installation_guide/dovecot_community_repositories/debian_packages/ The instructions need updating for two reasons: 1) Keep up to date with Debian releases (https://wiki.debian.org/DebianReleases), i.e. remove reference to 8.0 "Jessie" and replace with 10.0 "Buster". 2) The instructions presented for key handling are not inline with Debian best-practices. As per https://wiki.debian.org/DebianRepository/UseThirdParty: "The key MUST be downloaded over a secure mechanism like HTTPS to a location only writable by root, which SHOULD be /usr/share/keyrings. The key MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add. A sources.list entry SHOULD have the signed-by option set. The signed-by entry MUST point to a file, and not a fingerprint."
Re: Sv: 2FA/MFA with IMAP & postfix/submission
> Perhaps there are dovecot (and postfix submission) options to at least > restrict access by IP? Restricting by IP is soon going to become very tedious, especially if you are dealing with more than a small number of users, and especially once post-COVID travel comes back and people start connecting from random hotels and airport lounges. If you don't fancy the idea of client certs, the alternative I would suggest instead of IP limiting would be a Wireguard VPN instead of IP limiting. Wireguard VPN servers run very quiet and won't respond to anything unless a client sends the right parameters. Of course the downside of a VPN compared to certificates is that the user will have to be aware and know how to manage a VPN, whilst with certificates it can all be quietly done in the background.
Re: Sv: 2FA/MFA with IMAP & postfix/submission
> Client certs appears to be a good solution. > > What's the process for managing them with more than a hundred client accounts? If you've got the budget ... MDM. If you don't, you can probably hack together some sort of self-service system. > > I believe the problem they are trying to solve is hacked accounts from > > compromised passwords. Does client certs solve that problem? > Well yes. If you make client certs mandatory, unless the client can present a valid cert, the server will kill the connection before the client has a chance to try out a compromised password.
Re: 2FA/MFA with IMAP & postfix/submission
> Are there multi-factor options available? Mandating good old-fashioned client-certificates is most likely your best bet in terms of delivering the best user-experience.
Re: Simple backup of maildir folder
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Sunday, 31 May 2020 09:35, @lbutlr wrote:
>
> A couple of notes on this quite useful script:
>
> My mktemp does not support -p (FreeBSD 12.1) is I had to change the script to:
>
In my scripts I tend to create a tempdir and then tempfiles within that. It
makes the cleanup routine neater, e.g. at the top of my scripts :
TEMP_DIR=$(mktemp -qd || { doLog "Failed to make temp dir !"; exit 1; })
rmTmpFiles() { rm -rf "${TEMP_DIR}"; }
createTempFile() { local MYTEMP=$(mktemp -qp "${TEMP_DIR}" || doLog "Failed to
create temp file"; exit 1); echo $MYTEMP; }
Also my backup scripts have locking procedures built-in so as to avoid race
conditions.
Re: Determinant of umask for sieve_pipe_bin_dir scripts?
On Wednesday, 27 May 2020 11:31, Aki Tuomi wrote:
> > On 27/05/2020 13:28 Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote:
> > Hi,
> > What determines the umask of sieve_pipe_bin_dir scripts ?
> > The results from my script are always being set to 0600.
> > My script is simple and shown below, even if I adjust the right line to add
> > " && chmod 644", the actual resulting file still remains at 0600 ?!?
> > #!/bin/bash
> >
> > Usage: imapsieve_copy
> >
> > =
> >
> > MSG_USER="$1"
> > MSG_TYPE="$2"
> > RUN_UUID=$(cat /proc/sys/kernel/random/uuid)
> > BASE_DIR="/foo/bar"
> > TARGET_DIR="${BASE_DIR}/${MSG_TYPE}"
> > TARGET_FILE="${TARGET_DIR}/${RUN_UUID}"
> > cat > "${TARGET_FILE}" < /dev/stdin && pigz -9 "${TARGET_FILE}"
>
> You can run
>
> umask 0222
>
> to change it.
>
> Aki
That did the trick, thanks.
Determinant of umask for sieve_pipe_bin_dir scripts?
Hi,
What determines the umask of sieve_pipe_bin_dir scripts ?
The results from my script are always being set to 0600.
My script is simple and shown below, even if I adjust the right line to add "
&& chmod 644", the actual resulting file still remains at 0600 ?!?
#!/bin/bash
# Usage: imapsieve_copy
MSG_USER="$1"
MSG_TYPE="$2"
RUN_UUID=$(cat /proc/sys/kernel/random/uuid)
BASE_DIR="/foo/bar"
TARGET_DIR="${BASE_DIR}/${MSG_TYPE}"
TARGET_FILE="${TARGET_DIR}/${RUN_UUID}"
cat > "${TARGET_FILE}" < /dev/stdin && pigz -9 "${TARGET_FILE}"
Re: Current thinking on backups ?
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 26 May 2020 05:31, Germain Le Chapelain wrote: > > Le 24 mai 2020 à 14:42, Laura Smith n5d9xq3ti233xiyif...@protonmail.ch a > > écrit : > > Hi, > > What are people doing for backups ? > > My current process is LVM snapshot and backup from that to NFS share. > > But there seems to be hints around the internet that people use/abuse > > "doveadm backup" for backup purposes even though it seems its original > > intention was for transferring mailboxes between dovecot instances. > > Assuming its ok to "doveadm backup" to an NFS share, is it ok to use > > "doveadm backup" when dovecot has replication setup (replication-notify > > etc.) ? Or will it interfere ? > > Thanks! > > Laura > > This has came up in the past: > > https://dovecot.org/pipermail/dovecot/2020-February/thread.html#118206 > > I ended up developing my own system based on forwarding all emails to a > program (from which I back-up as they come in.) > > I am hoping if disaster and/or misfortune were to strike my server, I could > simply cat >> back all those files in order (or not come to think of it) in > the /var/mail/ (or somewhere even better fit in Postfix.) > > I am not interested in saving the state of the mailbox as much as all the > mails that ever come in (or go out.) > > Kindest regards, > > Germain Thanks Germain !
Current thinking on backups ?
Hi, What are people doing for backups ? My current process is LVM snapshot and backup from that to NFS share. But there seems to be hints around the internet that people use/abuse "doveadm backup" for backup purposes even though it seems its original intention was for transferring mailboxes between dovecot instances. Assuming its ok to "doveadm backup" to an NFS share, is it ok to use "doveadm backup" when dovecot has replication setup (replication-notify etc.) ? Or will it interfere ? Thanks! Laura
Re: doveadm backup : Error: Failed to access mailbox
FYI, found the solution. It seems doveadm can't cope with brackets in mailbox names. I moved the user's mails into non-braketed, deleted the bracketed and doveadm backup worked fine after that. ‐‐‐ Original Message ‐‐‐ On Sunday, 24 May 2020 14:32, Laura Smith wrote: > Hi All, > > So close and yet so far. ;-( > Have been migrating users from an old Dovecot server to a new one. > All of the users have doveadm backup'd perfectly, except for one ! > > What does the below mean ? > > $ sudo doveadm -v -o imapc_user=j...@example.org.tld -o > imapc_password=secretSquirrel -o imapc_host=old-server.example.com backup -1 > -R -u j...@example.org.tld imapc: > dsync(j...@example.org.tld): Info: imapc(old-server.example.com:993): > Connected to 10.10.10.10:993 (local 10.10.10.11:35858) > dsync(j...@example.org.tld): Error: Failed to access mailbox Sent Messages > (jasmin@example: Mailbox doesn't exist: Sent Messages (jasmin@example (0.001 > + 0.000 secs). > dsync(j...@example.org.tld): Error: Failed to access mailbox Sent Messages > (jas...@example.org: Mailbox doesn't exist: Sent Messages (jas...@example.org > (0.001 + 0.000 secs). > dsync(j...@example.org.tld): Error: Failed to access mailbox Drafts > (jasmin@example: Mailbox doesn't exist: Drafts (jasmin@example (0.001 + 0.000 > secs). > dsync(j...@example.org.tld): Error: Failed to access mailbox Drafts > (jas...@example.org: Mailbox doesn't exist: Drafts (jas...@example.org (0.001 > + 0.000 secs). > dsync(j...@example.org.tld): Error: Failed to access mailbox Deleted Messages > (jasmin@example: Mailbox doesn't exist: Deleted Messages (jasmin@example > (0.001 + 0.000 secs). > dsync(j...@example.org.tld): Error: Failed to access mailbox Deleted Messages > (jas...@example.org: Mailbox doesn't exist: Deleted Messages > (jas...@example.org (0.001 + 0.000 secs).
doveadm backup : Error: Failed to access mailbox
Hi All, So close and yet so far. ;-( Have been migrating users from an old Dovecot server to a new one. All of the users have doveadm backup'd perfectly, except for one ! What does the below mean ? $ sudo doveadm -v -o imapc_user=j...@example.org.tld -o imapc_password=secretSquirrel -o imapc_host=old-server.example.com backup -1 -R -u j...@example.org.tld imapc: dsync(j...@example.org.tld): Info: imapc(old-server.example.com:993): Connected to 10.10.10.10:993 (local 10.10.10.11:35858) dsync(j...@example.org.tld): Error: Failed to access mailbox Sent Messages (jasmin@example: Mailbox doesn't exist: Sent Messages (jasmin@example (0.001 + 0.000 secs). dsync(j...@example.org.tld): Error: Failed to access mailbox Sent Messages (jas...@example.org: Mailbox doesn't exist: Sent Messages (jas...@example.org (0.001 + 0.000 secs). dsync(j...@example.org.tld): Error: Failed to access mailbox Drafts (jasmin@example: Mailbox doesn't exist: Drafts (jasmin@example (0.001 + 0.000 secs). dsync(j...@example.org.tld): Error: Failed to access mailbox Drafts (jas...@example.org: Mailbox doesn't exist: Drafts (jas...@example.org (0.001 + 0.000 secs). dsync(j...@example.org.tld): Error: Failed to access mailbox Deleted Messages (jasmin@example: Mailbox doesn't exist: Deleted Messages (jasmin@example (0.001 + 0.000 secs). dsync(j...@example.org.tld): Error: Failed to access mailbox Deleted Messages (jas...@example.org: Mailbox doesn't exist: Deleted Messages (jas...@example.org (0.001 + 0.000 secs).
Dovecot passdb and postfix login
Hi,
Long story short I've got a fully functional Dovecot IMAP instance and I am now
looking to upgrade some perimiter authenticated SMTP relays to authenticate
against the Dovecot instance.
Trouble is that I am seeing errors such as "auth: Warning: sql: Ignoring
changed user_query in /etc/dovecot/local_sql_users.conf, because userdb sql not
used." in my Postfix server logs and not able to successfully authenticate via
AUTH LOGIN on the Postfi instance.
Perhaps I'm missing something obvious from my config ? Here is the doveconf -n
from the Postfix server in question:
# 2.3.10.1 (a3d0e1171): /etc/dovecot/dovecot.conf
# OS: Linux 4.19.0-9-amd64 x86_64 Debian 10.4
# Hostname: foobar.example.com
auth_mechanisms = plain login
auth_verbose = yes
auth_verbose_passwords = sha1:7
disable_plaintext_auth = no
mail_location = mbox:~/mail:INBOX=/var/mail/%u
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
args = /etc/dovecot/local_sql_users.conf
driver = sql
}
service auth {
inet_listener {
address = 127.0.0.1
port = 7425
}
inet_listener {
address = ::1
port = 7425
}
unix_listener /var/spool/postfix-authrelay/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
}
ssl = no
The local_sql_users.conf is the same one that's used on the functioning IMAP
servers, just copied accross to the authenticated relay server:
$ sudo cat /etc/dovecot/local_sql_users.conf
driver = pgsql
connect = host=foo dbname=bar user=secret password=squirrel
default_pass_scheme = ARGON2ID
password_query = select dovecot_username as user,password from get_user('%u')
user_query = select 'vmail' as uid, 'vmail' as gid
iterate_query = select dovecot_username as user from get_users()
dovecot sync not pushing automatically ?
Hi,
I'm aware its an async process, but despite sending test messages and then
waiting a few minutes, the stats are still unchanged :
$ sudo doveadm replicator status
Queued 'sync' requests 0
Queued 'high' requests 0
Queued 'low' requests 0
Queued 'failed' requests 0
Queued 'full resync' requests 0
Waiting 'failed' requests 0
Total number of known users 18
However if I manually run it using :
sudo doveadm -D sync -u t...@example.com -1 -d -N -l 30 -U
It syncs fine and the mails are visible on the standby server.
The master server is setup as per the docs :
replication_dsync_parameters = -1 -d -N -l 30 -U
plugin {
mail_replica = tcps:foobar.example.com:11867
}
service replicator {
process_min_avail = 1
}
service aggregator {
fifo_listener replication-notify-fifo {
user = foobar
}
unix_listener replication-notify {
user = foobar
}
}
service replicator {
unix_listener replicator-doveadm {
mode = 0600
user = foobar
}
}
replication_max_conns = 10
Re: iterate_query with static userdb ?
On Sunday, 17 May 2020 11:11, James wrote: > On 17/05/2020 10:43, Laura Smith wrote: > > > Because I wanted to avoid storing uid/gid/home in the database ? > > I use: > > user_query = "SELECT 'vmail' AS uid, 'vmail' AS gid, allow_nets, > '*:storage=' || quota || 'M' AS quota_rule FROM mailbox WHERE username = > '%n' AND domain = '%d';" > > ... uid and gid are not stored in my database but are returned by the query. Thanks !
Re: iterate_query with static userdb ?
On Sunday, 17 May 2020 10:38, Aki Tuomi wrote:
> > On 17/05/2020 12:34 Laura Smith wrote:
> >
> > Hi,
> >
> > Going by the "static userdb" example on this page
> > (https://wiki.dovecot.org/VirtualUsers#homedirs), tried to achieve a
> > similar setup in conjunction with pgsql for passdb.
> >
> > However I get an error "auth: Warning: sql: Ignoring changed iterate_query
> > in /etc/dovecot/local_sql_users.conf, because userdb sql not used. (If this
> > is intentional, set userdb_warning_disable=yes)"
> >
> > Does this mean the following is not a valid config ? Or at least I will not
> > be able to achieve iteration ?
> >
> > mail_location = maildir:/foobar/mail/%d/%n/Maildir
> > passdb {
> > driver = sql
> > args = /etc/dovecot/local_sql_users.conf
> > }
> > userdb {
> > driver = static
> > args = uid=foo gid=bar home=/foobar/mail/%d/%n
> > }
>
> It's valid but why do it like this? You can return these fields with
> user_query in the sql config.
>
> Aki
>
> ---
> Aki Tuomi
Because I wanted to avoid storing uid/gid/home in the database ?
iterate_query with static userdb ?
Hi,
Going by the "static userdb" example on this page
(https://wiki.dovecot.org/VirtualUsers#homedirs), tried to achieve a similar
setup in conjunction with pgsql for passdb.
However I get an error "auth: Warning: sql: Ignoring changed iterate_query in
/etc/dovecot/local_sql_users.conf, because userdb sql not used. (If this is
intentional, set userdb_warning_disable=yes)"
Does this mean the following is not a valid config ? Or at least I will not be
able to achieve iteration ?
mail_location = maildir:/foobar/mail/%d/%n/Maildir
passdb {
driver = sql
args = /etc/dovecot/local_sql_users.conf
}
userdb {
driver = static
args = uid=foo gid=bar home=/foobar/mail/%d/%n
}
"/etc/dovecot/dovecot.conf: passdb is missing driver"
Hi,
I'm trying to get dovecot working with postgres, I'm on Debian 10 and have
installed dovecot-pgsql from the Dovecot repo
(https://repo.dovecot.org/ce-2.3-latest/debian/).
I have the following in my local.conf :
passdb sql {
args = /etc/dovecot/local_sql_users.conf
}
And the following in the referenced file:
driver = pgsql
connect = host=localhost dbname=foobar user=bar password=foo
default_pass_scheme = ARGON2ID
password_query = select dovecot_username as user,password from get_user('%u')
iterate_query = select dovecot_username as user from get_users()
So surely it should work ?
doveconf -n just to complete the picture
# 2.3.10 (0da0eff44): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.10 (bf8ef1c2)
# OS: Linux 4.19.0-9-amd64 x86_64 Debian 10.4 xfs
# Hostname: foobar.example.com
auth_verbose = yes
auth_verbose_passwords = sha1:7
doveadm_password = # hidden, use -P to show it
mail_location = maildir:/foobar/mail/%d/%n/Maildir
mail_plugins = " notify replication"
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/local_sql_users.conf
name = sql
}
plugin {
mail_replica = tcps:standby.example.com:11867
sieve = file:~/sieve;active=~/.dovecot.sieve
}
protocols = imap lmtp
replication_dsync_parameters = -1 -d -N -l 30 -U
service aggregator {
fifo_listener replication-notify-fifo {
user = foobar
}
unix_listener replication-notify {
user = foobar
}
}
service auth {
unix_listener /var/spool/postfix/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
vsz_limit = 2 G
}
service doveadm {
inet_listener {
port = 11867
ssl = yes
}
}
service imap-login {
process_min_avail = 5
service_count = 1
}
service lmtp {
process_min_avail = 5
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
user = foobar
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieves {
address =
port = 5190
ssl = yes
}
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0600
user = foobar
}
}
ssl = required
ssl_ca = was automatically rejected:%n%r
}
protocol imap {
mail_max_userip_connections = 20
}
Help needed with managesieve
Hi,
I'm really struggling with the following inbound filtering:
Let's say:• My email address is "my.em...@example.com"
• I've setup a filtered address "filtered.em...@example.com"
• I've setup a sending/reply address "send.em...@example.com"
I am sending a message to a small group of people where detailed tracking is
required (yes, I know there are better automated ways outside of Dovecot to do
this... but let's leave that topic for another day shall we !)
My desired action is as follows :
• Message "From" shows "send.em...@example.com"
• Message "To" is set as "filtered.em...@example.com"
• General recipients in Bcc
When I send a test to an *external* address, it works as expected, i.e. :
• External address receives mail in its inbox
• Copy of mail gets put in relevant IMAP folder for "filtered.em...@example.com"
When I send a test to my own address, it does not work, the following happens
instead:
• Copy of mail gets put in relevant IMAP folder for
"filtered.em...@example.com" (this is good and as expected)
• The BCC "my.em...@example.com" never gets deposited in my inbox (this is not
good)
My dovecot sieve (as applied to "my.em...@example.com") is as follows (I have
tried both with and without the "stop" as you can see from the comment:
anyof (address :is :all "to" ["send.em...@example.com"],
header :contains ["Cc", "Delivered-To"] ["send.em...@example.com"]) {
fileinto :create "XYZmail-replies";
# Ignore stop for this rule only
# stop;
}
elsif anyof (address :is :all "to" ["filtered.em...@example.com"],
header :contains ["Cc", "Delivered-To"] ["filtered.em...@example.com"]) {
fileinto :create "XYZmail-sent";
# Ignore stop for this rule only
# stop;
}
Any need to be worried about occasional dsync errors ?
I am occasionally (maybe every 4 hours or less frequently) seeing the following two errors appear in my logs. Are they any cause for concern ? Error: Timeout during state=sync_mails (send=done recv=mails) I/O has stalled, no activity for 600 seconds (last sent=mail_request (EOL)
dsync not replicatiing .dovecot.sieve
There was a post on this topic to the list Aug 06, 2018 to which Aki replied "Thank you for reporting this, we'll take a look at this.". But its not clear what (if anything) has happened since ? The problem still seems to exist in 2.3.3 (original report by previous poster was for 2.3.2.1) The scenario I'm seeing is pretty much identical to the original poster's. Mail seems to be replicating fine, but sieve doesn't replicate at all.
Warning: Failed to do incremental sync
Setup dovecot sync along the lines of (https://wiki2.dovecot.org/Replication). I am doing one way replication. The initial full replication happened without issue, but now I'm seeing these errors on the slave server: doveadm: Warning: /data/mail/foo/bar/Maildir/dovecot-uidlist: Duplicate file entry at line 26397: 1562173159.M215923P17350.mxp,S=2290,W=2339 (uid 143128 -> 143142) Warning: Failed to do incremental sync for mailbox Sent Messages, retry with a full sync (Modseq 1766 no longer in transaction log (highest=17617, last_common_uid=17559, nextuid=17560)) Warning: Failed to do incremental sync for mailbox INBOX, retry with a full sync (Modseq 2540 no longer in transaction log (highest=13870, last_common_uid=19912, nextuid=19913)) I guess dovecot automatically tries a full replication because eventually the messages get pushed and "sync failed" status changes from 'y' to '-'
mail_replica equivalent to replicator_host/replicator_port
Silly question but regarding https://wiki.dovecot.org/Replication, is the mail_replica parameter shown in the docs equivalent to replicator_host and replicator_port in 2.3.3 ? 2.3.3 doesn't seem to like the mail_replica param (and indeed doveconf -a doesn't show it as an option) Thanks !
Re: failed: read(/var/run/dovecot/dns-client)
‐‐‐ Original Message ‐‐‐ On Thursday, April 11, 2019 9:01 PM, John Fawcett via dovecot wrote: > On 11/04/2019 10:02, Laura Smith via dovecot wrote: > > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, April 11, 2019 12:55 AM, John Fawcett via dovecot > > dovecot@dovecot.org wrote: > > > > > On 11/04/2019 00:51, Laura Smith via dovecot wrote: > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, April 10, 2019 11:48 PM, John Fawcett via dovecot > > > > dovecot@dovecot.org wrote: > > > > > > > > > On 11/04/2019 00:18, Laura Smith via dovecot wrote: > > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Wednesday, April 10, 2019 10:24 PM, Aki Tuomi > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > On 10 April 2019 23:56 Laura Smith via dovecot < > > > > > > > > dovecot@dovecot.org> wrote: > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > On Wednesday, April 10, 2019 9:14 PM, Aki Tuomi < > > > > > > > > aki.tu...@open-xchange.com> wrote: > > > > > > > > > > > > > > > > > > On 10 April 2019 23:13 Laura Smith via dovecot > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi > > > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > > > > > On 10 April 2019 22:13 Laura Smith via dovecot > > > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi > > > > > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot > > > > > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > dsync( foo...@example.com): Error: > > > > > > > > > > > > > > imapc(foobar.example.com:993): > > > > > > > > > > > > > > dns_lookup(foobar.example.com) failed: > > > > > > > > > > > > > > read(/var/run/dovecot/dns-client) failed: > > > > > > > > > > > > > > read(size=512) failed: Connection reset by peer > > > > > > > > > > > > > > This is dovecot's internal dns-client, and > > > > > > > > > > > > > > something goes wrong when talking to the service. > > > > > > > > > > > > > > dsync( foo...@example.com): Error: Failed to > > > > > > > > > > > > > > initialize user: imapc: Login to foobar.example.com > > > > > > > > > > > > > > failed: Disconnected from server > > > > > > > > > > > > > > This is btw dsync service, not imap service. > > > > > > > > > > > > > > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > > > > > > > > > > > > > Initially I thought "oh no, not a
Re: auth-worker unknown user
On Thursday, April 11, 2019 5:49 PM, Aki Tuomi
wrote:
> > On 11 April 2019 17:56 Laura Smith via dovecot dovecot@dovecot.org wrote:
> > On Thursday, April 11, 2019 3:07 PM, Aki Tuomi aki.tu...@open-xchange.com
> > wrote:
> >
> > > > On 11 April 2019 16:45 Laura Smith via dovecot < dovecot@dovecot.org>
> > > > wrote:
> > > > On Thursday, April 11, 2019 2:02 PM, Aki Tuomi <
> > > > aki.tu...@open-xchange.com> wrote:
> > > >
> > > > > PAM is trying to lookup user@domain while you probably only have
> > > > > user. PAM driver does not yet support username_format.
> > > >
> > > > > Aki
> > > >
> > > > But /etc/dovecot/users file isn't pam ? I don't need pam if if I'm
> > > > using /etc/dovecot/users ? Or am I understanding you wrong?
> > >
> > > you have passdb block using pam. it is involved in the lookup process.
> > >
> > > Aki Tuomi
> >
> > > doveconf -n passdb userdb
> > > passdb {
> > > args = scheme=ARGON2ID username_format=%u /etc/dovecot/users
> > > auth_verbose = yes
> > > driver = passwd-file
> > > }
> > > userdb {
> > > args = scheme=ARGON2ID username_format=%u /etc/dovecot/users
> > > auth_verbose = yes
> > > driver = passwd-file
> > > }
>
> Looks OK now. PAM is quite often the culprit as it's part of the default
> shipped config and can be often missed when setting things up.
>
> Aki
I guess for the future it might be nice to have an options in the params to
enable overrides for shipped configs (e.g. something similar to '!important' in
CSS land).
It would be nice to be able to make local.conf the source of truth instead of
having to say 97.5% local.conf and then these few hacks of shipped configs
(which may or may not get overwritten by package updates from the distros)
Re: auth-worker unknown user
On Thursday, April 11, 2019 3:07 PM, Aki Tuomi
wrote:
> > On 11 April 2019 16:45 Laura Smith via dovecot < dovecot@dovecot.org> wrote:
> >
> > On Thursday, April 11, 2019 2:02 PM, Aki Tuomi <
> > aki.tu...@open-xchange.com> wrote:
> >
> > > PAM is trying to lookup user@domain while you probably only have user.
> > > PAM driver does not yet support username_format.
> >
> > > Aki
> >
> > But /etc/dovecot/users file isn't pam ? I don't need pam if if I'm using
> > /etc/dovecot/users ? Or am I understanding you wrong?
>
> you have passdb block using pam. it is involved in the lookup process.
>
> ---
> Aki Tuomi
> doveconf -n passdb userdb
passdb {
args = scheme=ARGON2ID username_format=%u /etc/dovecot/users
auth_verbose = yes
driver = passwd-file
}
userdb {
args = scheme=ARGON2ID username_format=%u /etc/dovecot/users
auth_verbose = yes
driver = passwd-file
}
Re: auth-worker unknown user
‐‐‐ Original Message ‐‐‐ On Thursday, April 11, 2019 3:07 PM, Aki Tuomi wrote: > > On 11 April 2019 16:45 Laura Smith via dovecot < dovecot@dovecot.org> wrote: > > > > On Thursday, April 11, 2019 2:02 PM, Aki Tuomi < > > aki.tu...@open-xchange.com> wrote: > > > > > PAM is trying to lookup user@domain while you probably only have user. > > > PAM driver does not yet support username_format. > > > > > Aki > > > > But /etc/dovecot/users file isn't pam ? I don't need pam if if I'm using > > /etc/dovecot/users ? Or am I understanding you wrong? > > you have passdb block using pam. it is involved in the lookup process. Well, I didn't but it seems to be the default example config (i.e its in auth-system.conf.ext, not my local.cf). I commented it out, but now I get "auth: Fatal: No passdbs specified in configuration file. LOGIN mechanism needs one" What am I missing to make it look in /etc/dovecot/users ? My local.cf came from a known-good server so I don't understand why it hasn't implemented the changes that need to be done on this new one ? What parameters am I missing ? I'm lost and exhausted by struggling with dovecot these last few days.
Re: auth-worker unknown user
On Thursday, April 11, 2019 2:02 PM, Aki Tuomi wrote: > PAM is trying to lookup user@domain while you probably only have user. PAM > driver does not yet support username_format. > > Aki But /etc/dovecot/users file isn't pam ? I don't need pam if if I'm using /etc/dovecot/users ? Or am I understanding you wrong?
auth-worker unknown user
pam(foo...@example.com,192.0.1.1,<9zMTUUCGNfHZzMpL>): unknown user (SHA1 of
given password: ff75068c2f4d700a49dae204d56477a5ffa5d23d)
The password is correct, i.e. 'echo -n 'passed' | openssl dgst -sha1' matches.
The user is setup correctly in /etc/dovecot/users (the /etc/dovecot/users was
copied from another known-good server, so the syntax is correct and appropriate
adjustments have been made for chmod and directory).
doveconf -N follows:
# 2.3.3 (dcead646b): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.3 (f018bbab)
# OS: Linux 4.12.14-lp150.12.48-default x86_64
# Hostname: foobar
auth_mechanisms = plain login
auth_verbose = yes
auth_verbose_passwords = sha1
doveadm_password = # hidden, use -P to show it
first_valid_uid = 471
imapc_features = rfc822.size fetch-headers
imapc_host = foobar.example.com
imapc_password = # hidden, use -P to show it
imapc_port = 993
imapc_ssl = imaps
imapc_user = %u
mail_location = maildir:~/Maildir
mail_plugin_dir = /usr/lib64/dovecot/modules
mail_prefetch_count = 20
mailbox_list_index = yes
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body environment mailbox date ihave enotify
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
name =
}
plugin {
sieve = file:~/.dovecot.sieve
}
protocols = imap lmtp
service auth {
unix_listener /var/spool/postfix/private/dovecot-auth {
group = postfix
mode = 0660
user = postfix
}
}
service imap-login {
process_min_avail = 3
}
service lmtp {
process_min_avail = 5
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
user = my_virtmailuser
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieves {
address =
port = 5190
ssl = yes
}
}
ssl = required
ssl_ca = was automatically rejected:%n%r
}
protocol imap {
mail_max_userip_connections = 20
}
Re: failed: read(/var/run/dovecot/dns-client)
‐‐‐ Original Message ‐‐‐ On Thursday, April 11, 2019 9:05 AM, Aki Tuomi wrote: > > On 11 April 2019 11:02 Laura Smith via dovecot dovecot@dovecot.org wrote: > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, April 11, 2019 12:55 AM, John Fawcett via dovecot > > dovecot@dovecot.org wrote: > > > > > On 11/04/2019 00:51, Laura Smith via dovecot wrote: > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, April 10, 2019 11:48 PM, John Fawcett via dovecot > > > > dovecot@dovecot.org wrote: > > > > > > > > > On 11/04/2019 00:18, Laura Smith via dovecot wrote: > > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Wednesday, April 10, 2019 10:24 PM, Aki Tuomi > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > On 10 April 2019 23:56 Laura Smith via dovecot < > > > > > > > > dovecot@dovecot.org> wrote: > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > On Wednesday, April 10, 2019 9:14 PM, Aki Tuomi < > > > > > > > > aki.tu...@open-xchange.com> wrote: > > > > > > > > > > > > > > > > > > On 10 April 2019 23:13 Laura Smith via dovecot > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > > > On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi > > > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > > > > > On 10 April 2019 22:13 Laura Smith via dovecot > > > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi > > > > > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot > > > > > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > dsync( foo...@example.com): Error: > > > > > > > > > > > > > > imapc(foobar.example.com:993): > > > > > > > > > > > > > > dns_lookup(foobar.example.com) failed: > > > > > > > > > > > > > > read(/var/run/dovecot/dns-client) failed: > > > > > > > > > > > > > > read(size=512) failed: Connection reset by peer > > > > > > > > > > > > > > This is dovecot's internal dns-client, and > > > > > > > > > > > > > > something goes wrong when talking to the service. > > > > > > > > > > > > > > dsync( foo...@example.com): Error: Failed to > > > > > > > > > > > > > > initialize user: imapc: Login to foobar.example.com > > > > > > > > > > > > > > failed: Disconnected from server > > > > > > > > > > > > > > This is btw dsync service, not imap service. > > > > > > > > > > > > > > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > > > > > > > > > > > > > Initially I thought "oh no, not a
Re: failed: read(/var/run/dovecot/dns-client)
‐‐‐ Original Message ‐‐‐ On Thursday, April 11, 2019 12:55 AM, John Fawcett via dovecot wrote: > On 11/04/2019 00:51, Laura Smith via dovecot wrote: > > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 10, 2019 11:48 PM, John Fawcett via dovecot > > dovecot@dovecot.org wrote: > > > > > On 11/04/2019 00:18, Laura Smith via dovecot wrote: > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, April 10, 2019 10:24 PM, Aki Tuomi > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > On 10 April 2019 23:56 Laura Smith via dovecot < > > > > > > dovecot@dovecot.org> wrote: > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Wednesday, April 10, 2019 9:14 PM, Aki Tuomi < > > > > > > aki.tu...@open-xchange.com> wrote: > > > > > > > > > > > > > > On 10 April 2019 23:13 Laura Smith via dovecot > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > Sent with ProtonMail Secure Email. > > > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > > > On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > On 10 April 2019 22:13 Laura Smith via dovecot > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi > > > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot > > > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > > > == > > > > > > > > > > > > dsync( foo...@example.com): Error: > > > > > > > > > > > > imapc(foobar.example.com:993): > > > > > > > > > > > > dns_lookup(foobar.example.com) failed: > > > > > > > > > > > > read(/var/run/dovecot/dns-client) failed: > > > > > > > > > > > > read(size=512) failed: Connection reset by peer > > > > > > > > > > > > This is dovecot's internal dns-client, and something > > > > > > > > > > > > goes wrong when talking to the service. > > > > > > > > > > > > dsync( foo...@example.com): Error: Failed to initialize > > > > > > > > > > > > user: imapc: Login to foobar.example.com failed: > > > > > > > > > > > > Disconnected from server > > > > > > > > > > > > This is btw dsync service, not imap service. > > > > > > > > > > > > === > > > > > > > > > > > > Initially I thought "oh no, not another AppArmor block". > > > > > > > > > > > > But then surely the second message would not appear if > > > > > > > > > > > > the DNS lookup was not successful ? > > > > > > > > > > > > Also "dig foobar.example.com" works fine. > > > > > > > > > > > > How should I be troubleshooting this ? And if it is > > > > > > > > > > > > still likely to be AppArmor, what is calling it ? > > > > > > > > > > > > "doveadm" itself or something else ? What does > > > > > > > > > > > > "/var/run/dovecot/dns-client" do and why doesn't > > > > > > > > > > > > dovecot use standard OS calls like everyone else ? > > > > > > > > > >
Re: failed: read(/var/run/dovecot/dns-client)
‐‐‐ Original Message ‐‐‐ On Wednesday, April 10, 2019 11:48 PM, John Fawcett via dovecot wrote: > On 11/04/2019 00:18, Laura Smith via dovecot wrote: > > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 10, 2019 10:24 PM, Aki Tuomi aki.tu...@open-xchange.com > > wrote: > > > > > > On 10 April 2019 23:56 Laura Smith via dovecot < dovecot@dovecot.org> > > > > wrote: > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, April 10, 2019 9:14 PM, Aki Tuomi < > > > > aki.tu...@open-xchange.com> wrote: > > > > > > > > > > On 10 April 2019 23:13 Laura Smith via dovecot dovecot@dovecot.org > > > > > > wrote: > > > > > > Sent with ProtonMail Secure Email. > > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > > On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > On 10 April 2019 22:13 Laura Smith via dovecot > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi > > > > > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > > > > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot > > > > > > > > > > dovecot@dovecot.org wrote: > > > > > > > > > > > > > > > > > > > > == > > > > > > > > > > > > > > > > > > > > dsync( foo...@example.com): Error: > > > > > > > > > > imapc(foobar.example.com:993): > > > > > > > > > > dns_lookup(foobar.example.com) failed: > > > > > > > > > > read(/var/run/dovecot/dns-client) failed: read(size=512) > > > > > > > > > > failed: Connection reset by peer > > > > > > > > > > This is dovecot's internal dns-client, and something goes > > > > > > > > > > wrong when talking to the service. > > > > > > > > > > dsync( foo...@example.com): Error: Failed to initialize > > > > > > > > > > user: imapc: Login to foobar.example.com failed: > > > > > > > > > > Disconnected from server > > > > > > > > > > This is btw dsync service, not imap service. > > > > > > > > > > > > > > > > > > > > === > > > > > > > > > > > > > > > > > > > > Initially I thought "oh no, not another AppArmor block". > > > > > > > > > > But then surely the second message would not appear if the > > > > > > > > > > DNS lookup was not successful ? > > > > > > > > > > Also "dig foobar.example.com" works fine. > > > > > > > > > > How should I be troubleshooting this ? And if it is still > > > > > > > > > > likely to be AppArmor, what is calling it ? "doveadm" > > > > > > > > > > itself or something else ? What does > > > > > > > > > > "/var/run/dovecot/dns-client" do and why doesn't dovecot > > > > > > > > > > use standard OS calls like everyone else ? > > > > > > > > > > Because the "standard OS call" is blocking and we would > > > > > > > > > > prefer it to not block everything else. > > > > > > > > > > So many questions ! > > > > > > > > > > Aki > > > > > > > > > > Thanks for your reply, but both those message are generated > > > > > > > > > > from a simple : > > > > > > > > > > doveadm
Re: failed: read(/var/run/dovecot/dns-client)
‐‐‐ Original Message ‐‐‐
On Wednesday, April 10, 2019 10:24 PM, Aki Tuomi
wrote:
> > On 10 April 2019 23:56 Laura Smith via dovecot < dovecot@dovecot.org> wrote:
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, April 10, 2019 9:14 PM, Aki Tuomi <
> > aki.tu...@open-xchange.com> wrote:
> >
> > > > On 10 April 2019 23:13 Laura Smith via dovecot dovecot@dovecot.org
> > > > wrote:
> > > > Sent with ProtonMail Secure Email.
> > > > ‐‐‐ Original Message ‐‐‐
> > > > On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi
> > > > aki.tu...@open-xchange.com wrote:
> > >
> > > > > > On 10 April 2019 22:13 Laura Smith via dovecot dovecot@dovecot.org
> > > > > > wrote:
> > > > > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi
> > > > > > aki.tu...@open-xchange.com wrote:
> > > > >
> > > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot
> > > > > > > > dovecot@dovecot.org wrote:
> > > > > > > > ==
> > > > > > > > dsync( foo...@example.com): Error:
> > > > > > > > imapc(foobar.example.com:993): dns_lookup(foobar.example.com)
> > > > > > > > failed: read(/var/run/dovecot/dns-client) failed:
> > > > > > > > read(size=512) failed: Connection reset by peer
> > > > > >
> > > > > > > This is dovecot's internal dns-client, and something goes wrong
> > > > > > > when talking to the service.
> > > > > >
> > > > > > > > dsync( foo...@example.com): Error: Failed to initialize user:
> > > > > > > > imapc: Login to foobar.example.com failed: Disconnected from
> > > > > > > > server
> > > > > >
> > > > > > > This is btw dsync service, not imap service.
> > > > > >
> > > > > > > > ===
> > > > > > > > Initially I thought "oh no, not another AppArmor block".
> > > > > > > > But then surely the second message would not appear if the DNS
> > > > > > > > lookup was not successful ?
> > > > > > > > Also "dig foobar.example.com" works fine.
> > > > > > > > How should I be troubleshooting this ? And if it is still
> > > > > > > > likely to be AppArmor, what is calling it ? "doveadm" itself or
> > > > > > > > something else ? What does "/var/run/dovecot/dns-client" do and
> > > > > > > > why doesn't dovecot use standard OS calls like everyone else ?
> > > > > >
> > > > > > > Because the "standard OS call" is blocking and we would prefer it
> > > > > > > to not block everything else.
> > > > > >
> > > > > > > > So many questions !
> > > > > >
> > > > > > > Aki
> > > > >
> > > > > > Thanks for your reply, but both those message are generated from a
> > > > > > simple :
> > > > > > doveadm -v -o mail_fsync=never backup -R -u foo...@example.com
> > > > > > imapc:
> > > > > > So I don't know what you mean about dsync service failing ? Surely
> > > > > > the DNS lookup succeeded if the 'dsync service' failed due to
> > > > > > remote disconnect ?
> > > > > > I'm still none the wiser as to where to start looking for
> > > > > > troubleshoting ?
> > > >
> > > > > Did you check dovecot logs? Maybe there is something useful?
> > > > > Aki
> > >
> > > > Only the same old cryptic message about dns-client ?
> > > > master: Fatal: execv(/usr/lib/dovecot/dns-client) failed: Permission
> > > > denied
> >
> > > Something prevents executing the dns-client binary.
> >
> > > > master: Error: service(dns_client): command startup failed, throttling
> > > > for 16 secs
> > > > dns_client: Fatal: master: service(dns_client): child 14293 returned
> > > > error 84 (exec() failed)
> >
> > > Aki
> >
> > Yes but is it being called by doveadm directly or by some other dovecot
> > program ? If I'm going to have to go down the AppArmor route, then I would
> > prefer if you told me what was calling it instead of me having to
> > un-necessarily spend time doing straces !
> >
> > Also, should I be able to call dns-client directly myself ? (or is there a
> > way to do so to enable testing ?
>
> It is started by dovecot's master process when you connect to dns-client unix
> socket. You can try
>
> socat stdio unix-connect:/var/run/dovecot/dns-client
>
> I thought apparmor tells when something is blocked into kernel log? have you
> checked dmesg?
>
> Apologies for your frustration.
> ---
Yeah nothing in dmesg. I'm still hunting around to find some log somewhere but
so far silence.
"socat stdio unix-connect:/var/run/dovecot/dns-client" runs but returns
nothing. Is that expected ?
When you say "dovecot's master process", so doveadm sync talks to the master
process ? So in terms of apparmor I would therefore be looking at
/usr/sbin/dovecot ? If that's the case, the relevant apparmor permisssions are
already provided :
/{,var/}run/dovecot/ rw,
/{,var/}run/dovecot/** rw,
Re: failed: read(/var/run/dovecot/dns-client)
‐‐‐ Original Message ‐‐‐ On Wednesday, April 10, 2019 9:14 PM, Aki Tuomi wrote: > > On 10 April 2019 23:13 Laura Smith via dovecot dovecot@dovecot.org wrote: > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi aki.tu...@open-xchange.com > > wrote: > > > > > > On 10 April 2019 22:13 Laura Smith via dovecot dovecot@dovecot.org > > > > wrote: > > > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi > > > > aki.tu...@open-xchange.com wrote: > > > > > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot dovecot@dovecot.org > > > > > > wrote: > > > > > > == > > > > > > dsync(foo...@example.com): Error: imapc(foobar.example.com:993): > > > > > > dns_lookup(foobar.example.com) failed: > > > > > > read(/var/run/dovecot/dns-client) failed: read(size=512) failed: > > > > > > Connection reset by peer > > > > > > > > > > This is dovecot's internal dns-client, and something goes wrong when > > > > > talking to the service. > > > > > > > > > > > dsync(foo...@example.com): Error: Failed to initialize user: imapc: > > > > > > Login to foobar.example.com failed: Disconnected from server > > > > > > > > > > This is btw dsync service, not imap service. > > > > > > > > > > > === > > > > > > Initially I thought "oh no, not another AppArmor block". > > > > > > But then surely the second message would not appear if the DNS > > > > > > lookup was not successful ? > > > > > > Also "dig foobar.example.com" works fine. > > > > > > How should I be troubleshooting this ? And if it is still likely to > > > > > > be AppArmor, what is calling it ? "doveadm" itself or something > > > > > > else ? What does "/var/run/dovecot/dns-client" do and why doesn't > > > > > > dovecot use standard OS calls like everyone else ? > > > > > > > > > > Because the "standard OS call" is blocking and we would prefer it to > > > > > not block everything else. > > > > > > > > > > > So many questions ! > > > > > > > > > > Aki > > > > > > > > Thanks for your reply, but both those message are generated from a > > > > simple : > > > > doveadm -v -o mail_fsync=never backup -R -u foo...@example.com imapc: > > > > So I don't know what you mean about dsync service failing ? Surely the > > > > DNS lookup succeeded if the 'dsync service' failed due to remote > > > > disconnect ? > > > > I'm still none the wiser as to where to start looking for > > > > troubleshoting ? > > > > > > Did you check dovecot logs? Maybe there is something useful? > > > Aki > > > > Only the same old cryptic message about dns-client ? > > master: Fatal: execv(/usr/lib/dovecot/dns-client) failed: Permission denied > > Something prevents executing the dns-client binary. > > > master: Error: service(dns_client): command startup failed, throttling for > > 16 secs > > dns_client: Fatal: master: service(dns_client): child 14293 returned error > > 84 (exec() failed) > > Aki Yes but is it being called by doveadm directly or by some other dovecot program ? If I'm going to have to go down the AppArmor route, then I would prefer if you told me what was calling it instead of me having to un-necessarily spend time doing straces ! Also, should I be able to call dns-client directly myself ? (or is there a way to do so to enable testing ?) # /usr/lib/dovecot/dns-client Panic: BUG: No IOs or timeouts set. Not waiting for infinity. Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0xd879e) [0x7f582c65f79e] -> /usr/lib64/dovecot/libdovecot.so.0(+0xd87e1) [0x7f582c65f7e1] -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7f582c5c9024] -> /usr/lib64/dovecot/libdovecot.so.0(+0xf045c) [0x7f582c67745c] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x36) [0x7f582c679e96] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c) [0x7f582c6786ec] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f582c678908] -> /usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f582c5ee203] -> /usr/lib/dovecot/dns-client(main+0x8d) [0x55866c96050d] -> /lib64/libc.so.6(__libc_start_main+0xea) [0x7f582c1edf4a] -> /usr/lib/dovecot/dns-client(_start+0x2a) [0x55866c96055a]
Re: failed: read(/var/run/dovecot/dns-client)
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, April 10, 2019 8:20 PM, Aki Tuomi wrote: > > On 10 April 2019 22:13 Laura Smith via dovecot dovecot@dovecot.org wrote: > > On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi aki.tu...@open-xchange.com > > wrote: > > > > > > On 10 April 2019 21:26 Laura Smith via dovecot dovecot@dovecot.org > > > > wrote: > > > > > > > > == > > > > > > > > dsync(foo...@example.com): Error: imapc(foobar.example.com:993): > > > > dns_lookup(foobar.example.com) failed: > > > > read(/var/run/dovecot/dns-client) failed: read(size=512) failed: > > > > Connection reset by peer > > > > > > This is dovecot's internal dns-client, and something goes wrong when > > > talking to the service. > > > > > > > dsync(foo...@example.com): Error: Failed to initialize user: imapc: > > > > Login to foobar.example.com failed: Disconnected from server > > > > > > This is btw dsync service, not imap service. > > > > > > > === > > > > Initially I thought "oh no, not another AppArmor block". > > > > But then surely the second message would not appear if the DNS lookup > > > > was not successful ? > > > > Also "dig foobar.example.com" works fine. > > > > How should I be troubleshooting this ? And if it is still likely to be > > > > AppArmor, what is calling it ? "doveadm" itself or something else ? > > > > What does "/var/run/dovecot/dns-client" do and why doesn't dovecot use > > > > standard OS calls like everyone else ? > > > > > > Because the "standard OS call" is blocking and we would prefer it to not > > > block everything else. > > > > > > > So many questions ! > > > > > > Aki > > > > Thanks for your reply, but both those message are generated from a simple : > > doveadm -v -o mail_fsync=never backup -R -u foo...@example.com imapc: > > So I don't know what you mean about dsync service failing ? Surely the DNS > > lookup succeeded if the 'dsync service' failed due to remote disconnect ? > > I'm still none the wiser as to where to start looking for troubleshoting ? > > Did you check dovecot logs? Maybe there is something useful? > > Aki Only the same old cryptic message about dns-client ? master: Fatal: execv(/usr/lib/dovecot/dns-client) failed: Permission denied master: Error: service(dns_client): command startup failed, throttling for 16 secs dns_client: Fatal: master: service(dns_client): child 14293 returned error 84 (exec() failed)
Re: failed: read(/var/run/dovecot/dns-client)
On Wednesday, April 10, 2019 7:57 PM, Aki Tuomi wrote: > > On 10 April 2019 21:26 Laura Smith via dovecot dovecot@dovecot.org wrote: > > === > > dsync(foo...@example.com): Error: imapc(foobar.example.com:993): > > dns_lookup(foobar.example.com) failed: read(/var/run/dovecot/dns-client) > > failed: read(size=512) failed: Connection reset by peer > > This is dovecot's internal dns-client, and something goes wrong when talking > to the service. > > > dsync(foo...@example.com): Error: Failed to initialize user: imapc: Login > > to foobar.example.com failed: Disconnected from server > > This is btw dsync service, not imap service. > > > === > > Initially I thought "oh no, not another AppArmor block". > > But then surely the second message would not appear if the DNS lookup was > > not successful ? > > Also "dig foobar.example.com" works fine. > > How should I be troubleshooting this ? And if it is still likely to be > > AppArmor, what is calling it ? "doveadm" itself or something else ? What > > does "/var/run/dovecot/dns-client" do and why doesn't dovecot use standard > > OS calls like everyone else ? > > Because the "standard OS call" is blocking and we would prefer it to not > block everything else. > > > So many questions ! > > Aki Thanks for your reply, but both those message are generated from a simple : doveadm -v -o mail_fsync=never backup -R -u foo...@example.com imapc: So I don't know what you mean about dsync service failing ? Surely the DNS lookup succeeded if the 'dsync service' failed due to remote disconnect ? I'm still none the wiser as to where to start looking for troubleshoting ?
Re: ssl_cert: Can't open file permission denied
‐‐‐ Original Message ‐‐‐ On Wednesday, April 10, 2019 1:08 PM, Michael Orlitzky via dovecot wrote: > On 4/10/19 6:39 AM, Dmitry Donskih via dovecot wrote: > > > `chmod -R 655 /etc/foobar/ssl' drops x attribute from`ssl' itself. > > Use `chmod -R 755' or`chmod +x' or similar. > > Your private keys should be... private. Use 750 instead. You are teaching granny to suck eggs. Sometimes granny needs to do troubleshooting (especially when neither Dovecot or the Operating System are generating any sort of useful log entries to help granny... it means granny needs to resort to real basics like file permissions and then work upwards).
failed: read(/var/run/dovecot/dns-client)
=== dsync(foo...@example.com): Error: imapc(foobar.example.com:993): dns_lookup(foobar.example.com) failed: read(/var/run/dovecot/dns-client) failed: read(size=512) failed: Connection reset by peer dsync(foo...@example.com): Error: Failed to initialize user: imapc: Login to foobar.example.com failed: Disconnected from server === Initially I thought "oh no, not another AppArmor block". But then surely the second message would not appear if the DNS lookup was not successful ? Also "dig foobar.example.com" works fine. How should I be troubleshooting this ? And if it is still likely to be AppArmor, what is calling it ? "doveadm" itself or something else ? What does "/var/run/dovecot/dns-client" do and why doesn't dovecot use standard OS calls like everyone else ? So many questions !
Re: ssl_cert: Can't open file permission denied
On Wednesday, April 10, 2019 11:40 AM, Gerald Galster via dovecot wrote: > > Am 10.04.2019 um 11:59 schrieb Laura Smith via dovecot > > : > > > > On Wednesday, April 10, 2019 10:52 AM, Aki Tuomi via dovecot > > wrote: > > > > > On 10.4.2019 12.36, Laura Smith via dovecot wrote: > > > > > > > Dovecot 2.3.3 (dcead646b) > > > > openSUSE Leap 15.0 > > > > I am getting a weird error message: > > > > Fatal: Error in configuration file /etc/dovecot/local.conf line 16: > > > > ssl_cert: Can't open file /etc/foobar/ssl/certbot.pem: Permission denied > > > > I have tried the following: > > > > > > > > - chmod -R 655 /etc/foobar/ssl (/etc/foobar is 755) > > > > - create "ssl_users" group add dovecot to it chown -R > > > > dovecot:ssl_users /etc/foobar/ssl > > > > > > > > How can I fix this ? There's no obvious solution ? > > > > > > Are you by chance using selinux? If you are, you might need to relabel > > > the files. > > > > > > Aki > > > > This is openSUSE, not Centos, I don't think it even comes with selinux. > > Maybe apparmor? > > https://git.ispconfig.org/ispconfig/ispconfig3/issues/5071 > > > OpenSuSE and apparmor expect dovecot certs to be in /etc/ssl/private > > ISPConfig setup script expects SSL certs to be in /etc/postfix but > apparmor prevents dovecot from reading them in that directory > > Otherwise you could login as dovecot user (temporarily change the shell to > bash if needed; usermod -s /bin/bash) and see if you can access the > certificate. > Check all directory/file permissions, including acls (man getfacl), along the > path. > > Best regards > Gerald @Gerald Spot on with apparmor !
Re: ssl_cert: Can't open file permission denied
On Wednesday, April 10, 2019 10:52 AM, Aki Tuomi via dovecot wrote: > On 10.4.2019 12.36, Laura Smith via dovecot wrote: > > > Dovecot 2.3.3 (dcead646b) > > openSUSE Leap 15.0 > > I am getting a weird error message: > > Fatal: Error in configuration file /etc/dovecot/local.conf line 16: > > ssl_cert: Can't open file /etc/foobar/ssl/certbot.pem: Permission denied > > I have tried the following: > > > > - chmod -R 655 /etc/foobar/ssl (/etc/foobar is 755) > > - create "ssl_users" group add dovecot to it chown -R dovecot:ssl_users > > /etc/foobar/ssl > > > > How can I fix this ? There's no obvious solution ? > > Are you by chance using selinux? If you are, you might need to relabel > the files. > > Aki This is openSUSE, not Centos, I don't think it even comes with selinux.
ssl_cert: Can't open file permission denied
Dovecot 2.3.3 (dcead646b) openSUSE Leap 15.0 I am getting a weird error message: Fatal: Error in configuration file /etc/dovecot/local.conf line 16: ssl_cert: Can't open file /etc/foobar/ssl/certbot.pem: Permission denied I have tried the following: - chmod -R 655 /etc/foobar/ssl (/etc/foobar is 755) - create "ssl_users" group add dovecot to it chown -R dovecot:ssl_users /etc/foobar/ssl How can I fix this ? There's no obvious solution ?
Re: Struggling to get dovecot working with postfix auth
On Thursday, October 11, 2018 1:29 PM, Aki Tuomi wrote: > > On 11 October 2018 at 15:02 Laura Smith n5d9xq3ti233xiyif...@protonmail.ch > > wrote: > > > > > That's a permission error. Somewhere in your directory hierarchy things > > > are off. See Postfix' set-permissions command. > > > > But surely if Dovecot is staring as root then directory permissions are > > relevant, especially if I'm then asking the config to chmod the file anway ? > > To me, it seems dovecot is not behaving correctly, because if it is not > > using root to access the directory then it is not going to be able to chmod > > the socket later is it ? > > You should probably check few things: > > 1. check dmesg or /var/log/audit/audit.log for any possible security > framework problems > 2. check namei -vl /var/spool/postfix-authrelay/private/dovecot-auth for > anything strange > 3. there is some reason the socket is not bound into, dovecot creates these > sockets as root. > > Aki > Thanks. It ended up being an AppArmor issue. That's now fixed the socket gets created. However, the first part of my problem described earlier still exists, namely: 2018-10-11T15:58:41.230340+01:00 X postfix-authrelay/smtpd[21297]: warning: X.example.com[X]: SASL PLAIN authentication failed: I was hoping going via the socket instead of TCP might fix it, but apparently not. ;-(
Re: Struggling to get dovecot working with postfix auth
> That's a permission error. Somewhere in your directory hierarchy things > are off. See Postfix' set-permissions command. > But surely if Dovecot is staring as root then directory permissions are relevant, especially if I'm then asking the config to chmod the file anway ? To me, it seems dovecot is not behaving correctly, because if it is not using root to access the directory then it is not going to be able to chmod the socket later is it ?
Re: Struggling to get dovecot working with postfix auth
> Do you have SELinux or the like running on the system? > Not as far as I'm aware. Its openSUSE LEAP 15, which does not ship with SELinux.
Re: Struggling to get dovecot working with postfix auth
On Thursday, October 11, 2018 12:07 PM, Ralph Seichter
wrote:
> On 11.10.18 11:30, Laura Smith wrote:
>
> > unix_listener /var/spool/postfix-authrelay/private/dovecot-auth {
> > group = postfix
> > mode = 0666
> > user = postfix
> > }
>
> I suggest using "mode = 0660" instead.
Makes no difference.
>
> > Dovecot is unable to create the socket ?
>
> What exactly do the logs show?
Erm, they show exactly what I posted earlier ?
2018-10-11T12:14:15.467791+01:00 X dovecot: master: Error:
bind(/var/spool/postfix-authrelay/private/dovecot-auth) failed: Permission
denied
2018-10-11T12:14:15.468094+01:00 X dovecot: master: Error: service(auth):
net_listen_unix(/var/spool/postfix-authrelay/private/dovecot-auth) failed:
Permission denied
2018-10-11T12:14:15.468216+01:00 X dovecot: master: Fatal: Failed to start
listeners
>
> > postconf -c /etc/postfix-authrelay | fgrep sasl
>
> As described inhttp://www.postfix.org/DEBUG_README.html please use
> "postconf -n".
>
alias_database =
alias_maps =
append_dot_mydomain = no
authorized_submit_users =
command_directory = /usr/sbin
compatibility_level = 2
config_directory = /etc/postfix-authrelay
daemon_directory = /usr/lib/postfix/bin/
data_directory = /var/lib/postfix-authrelay
disable_vrfy_command = yes
html_directory = /usr/share/doc/packages/postfix-doc/html
inet_interfaces = 198.51.100.168
inet_protocols = ipv4
local_recipient_maps =
local_transport = error:5.1.1 Mailbox unavailable
mail_owner = postfix
mail_spool_directory = /var/mail
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 2048
milter_default_action = accept
milter_mail_macros = i {mail_addr} {daemon_addr} {client_name} {auth_authen}
milter_protocol = 2
multi_instance_enable = yes
multi_instance_name = postfix-authrelay
mydestination =
mydomain = example.com
myhostname = X.example.com
mynetworks = 127.0.0.0/8,192.168.107.0/24,192.168.109.0/24
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
non_smtpd_milters = inet:localhost:8891
parent_domain_matches_subdomains =
queue_directory = /var/spool/postfix-authrelay
readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES
relay_domains =
sample_directory = /usr/share/doc/packages/postfix-doc/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = maildrop
smtp_bind_address = 198.51.100.168
smtp_sasl_auth_enable = no
smtpd_banner = $myhostname ESMTP
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_relay_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = inet:localhost:7425
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = ${config_directory}/ssl_certs/star_example_com.pem
smtpd_tls_dh1024_param_file = ${config_directory}/ssl_certs/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/ssl_certs/dh512.pem
smtpd_tls_eecdh_grade = strong
smtpd_tls_key_file = ${config_directory}/ssl_certs/X_workremote_eu.key
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2,!TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_security_level = encrypt
smtputf8_enable = no
tls_eecdh_strong_curve = prime256v1
tls_preempt_cipherlist = yes
unknown_local_recipient_reject_code = 550
Struggling to get dovecot working with postfix auth
Hi,
I am trying to create an authenticated relay server using Postfix and Dovecot.
However I am having two problems :
(a) If I create a dovecot config entry as follows :
unix_listener /var/spool/postfix-authrelay/private/dovecot-auth {
group = postfix
mode = 0666
user = postfix
}
Dovecot is unable to create the socket ? I thought surely if dovecot is
started as root it should create the socket before dropping privileges ?
(b) The alternative method of TCP SASL is not working either:
250 DSN
ehlo localhost
250-foobar.example.com
250-PIPELINING
250-SIZE 2048
250-ETRN
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN
535 5.7.8 Error: authentication failed:
and in the logs...
2018-10-11T10:17:40.491483+01:00 X postfix-authrelay/smtpd[18312]: warning:
X[X]: SASL PLAIN authentication failed:
postconf
>postconf -a
cyrus
dovecot
> postconf -c /etc/postfix-authrelay | fgrep sasl
broken_sasl_auth_clients = no
cyrus_sasl_config_path =
lmtp_sasl_auth_cache_name =
lmtp_sasl_auth_cache_time = 90d
lmtp_sasl_auth_enable = no
lmtp_sasl_auth_soft_bounce = yes
lmtp_sasl_mechanism_filter =
lmtp_sasl_password_maps =
lmtp_sasl_path =
lmtp_sasl_security_options = noplaintext, noanonymous
lmtp_sasl_tls_security_options = $lmtp_sasl_security_options
lmtp_sasl_tls_verified_security_options = $lmtp_sasl_tls_security_options
lmtp_sasl_type = cyrus
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$smtpd_sender_login_maps $sender_bcc_maps $recipient_bcc_maps
$smtp_generic_maps $lmtp_generic_maps $alias_maps $smtpd_client_restrictions
$smtpd_helo_restrictions $smtpd_sender_restrictions $smtpd_relay_restrictions
$smtpd_recipient_restrictions
$address_verify_sender_dependent_default_transport_maps
$address_verify_sender_dependent_relayhost_maps $address_verify_transport_maps
$fallback_transport_maps $lmtp_discard_lhlo_keyword_address_maps
$lmtp_pix_workaround_maps $lmtp_sasl_password_maps $lmtp_tls_policy_maps
$mailbox_command_maps $mailbox_transport_maps
$postscreen_discard_ehlo_keyword_address_maps $rbl_reply_maps
$sender_dependent_default_transport_maps $sender_dependent_relayhost_maps
$smtp_discard_ehlo_keyword_address_maps $smtp_pix_workaround_maps
$smtp_sasl_password_maps $smtp_tls_policy_maps
$smtpd_discard_ehlo_keyword_address_maps $smtpd_milter_maps $virtual_gid_maps
$virtual_uid_maps
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name
$address_verify_map $postscreen_cache_map
send_cyrus_sasl_authzid = no
smtp_sasl_auth_cache_name =
smtp_sasl_auth_cache_time = 90d
smtp_sasl_auth_enable = no
smtp_sasl_auth_soft_bounce = yes
smtp_sasl_mechanism_filter =
smtp_sasl_password_maps =
smtp_sasl_path =
smtp_sasl_security_options = noplaintext, noanonymous
smtp_sasl_tls_security_options = $smtp_sasl_security_options
smtp_sasl_tls_verified_security_options = $smtp_sasl_tls_security_options
smtp_sasl_type = cyrus
smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_relay_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = no
smtpd_sasl_exceptions_networks =
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = inet:localhost:7425
smtpd_sasl_security_options = noanonymous
smtpd_sasl_service = smtp
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = dovecot
DOVECONF
> doveconf -n
# 2.3.1 (8e2f634): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.1 (d9bc6dfe)
# OS: Linux 4.12.14-lp150.12.19-default x86_64
# Hostname: test.example.com
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date index ihave duplicate
mime foreverypart extracttext
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
}
passdb {
driver = pam
}
plugin {
sieve = file:~/sieve;active=~/.dovecot.sieve
}
service auth {
inet_listener {
address = 127.0.0.1
port = 7425
}
inet_listener {
address = ::1
port = 7425
}
# If I disable this, dovecot loads fine, but the tcp auth is unusable ?
# If I enable this, dovecot is unable to create the socket ?
# unix_listener /var/spool/postfix-authrelay/private/dovecot-auth {
#group = postfix
#mode = 0666
#user = postfix
#
