On 22/12/24 02:54, Michael Tokarev via Postfix-users wrote:
However, there are other mechanisms being developed, for example OAUTH2,
which, in terms of Cyrus SASL, does not work with saslauthd at all,
I don't see why it wouldn't.
so
needs direct integration within postfix in a form of plugin
On 22/12/24 03:19, Tomasz Pala via Postfix-users wrote:
What's worth mentioning is that PLAIN/LOGIN also requires cleartext
password storage - on the client side.
This is not entirely true. It is possible for a client to store
passwords in an encrypted db which is decrypted with its own pass
Michael Tokarev via Postfix-users:
> 21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
> > On Sat, Dec 21, 2024 at 08:35:29PM +0300, Michael Tokarev via Postfix-users
> > wrote:
> >
> >> 21.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
> >>
> >>> plus a few other workarounds fo
21.12.2024 16:30, Tomasz Pala via Postfix-users wrote:
The real problem is I can't really confine local, as it's the same
CGroup as the rest of postfix, so the holes punched for example for
postfix-script cannot be sealed and are kept for good.
As I demonstrated before, it's rather trivial to
Tomasz Pala via Postfix-users:
> On 2024-12-20 19:02, Wietse Venema via Postfix-users wrote:
> >
> >> You say "local is non-chrootable" - I say local is the mostly exposed,
> >> running user-provided content, binary and environment. It's the local
> >> which can exploit CVE in your kernel. You're
21.12.2024 18:31, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
It *feels* like postfix needs some separation of this sasl stuff into
its own process somehow, similar to how proxymap is done, so that
eg cyrus sasl code is not linked directly into smtp[d] with all it
21.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
plus a few other workarounds for lack of cap-dac-override.
It looks like it's hardly possible to get away from cap_dac_override,
because it is relied on in a number of other places. Currently postfix
happily opens non-root-owned maps b
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
On Sat, Dec 21, 2024 at 08:35:29PM +0300, Michael Tokarev via Postfix-users
wrote:
21.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
plus a few other workarounds for lack of cap-dac-override.
It looks like it's hardly poss
Michael Tokarev via Postfix-users:
> I still yet to see the reason for this, besides a statement "chroot is
> painless for freebsd but for linux is unsupportable", which is nothing
> but a big old myth, since the two works the same.
That is a myth, because we already discussed that glibc needs fil
21.12.2024 19:51, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
I still yet to see the reason for this, besides a statement "chroot is
painless for freebsd but for linux is unsupportable", which is nothing
but a big old myth, since the two works the same.
That is a
On 2024-12-21 14:54, Michael Tokarev via Postfix-users wrote:
>
> cleartext password (storage) is required for many SASL mechanisms over
> than PLAIN. And none of these mechanisms work with -a pam or with
[...]
> However, there are other mechanisms being developed, for example OAUTH2,
What's wor
On 2024-12-21 11:51, Michael Tokarev via Postfix-users wrote:
>
> We've basically two big kinds of SASL mechanisms: plaintext
> (which are login and plain) and non-plaintest (everything else).
[...]
> There's nothing in the docs saying if dovecot sasl can work with
> non-plaintext mechanisms. In
21.12.2024 16:16, Viktor Dukhovni via Postfix-users wrote:
On Sat, Dec 21, 2024 at 01:51:46PM +0300, Michael Tokarev via Postfix-users
wrote:
...
As far as I can see, Cyrus SASL can work with plaintext methods
using saslauthd (which has very simple username,password => ok|bad
protocol), and ca
On Sat, Dec 21, 2024 at 08:35:29PM +0300, Michael Tokarev via Postfix-users
wrote:
> 21.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
>
> > plus a few other workarounds for lack of cap-dac-override.
>
> It looks like it's hardly possible to get away from cap_dac_override,
> because it
On 2024-12-20 19:02, Wietse Venema via Postfix-users wrote:
>
>> You say "local is non-chrootable" - I say local is the mostly exposed,
>> running user-provided content, binary and environment. It's the local
>> which can exploit CVE in your kernel. You're not preventing any of this.
>
> I think
On Sat, Dec 21, 2024 at 01:51:46PM +0300, Michael Tokarev via Postfix-users
wrote:
> Hi!
>
> I'm trying to get a "big picture" about how postfix works with
> various SASL options. It looks like there's a big overview
> missing in the docs somehow.
>
> We've basically two big kinds of SASL mecha
22.12.2024 01:10, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
It looks like it's hardly possible to get away from cap_dac_override,
because it is relied on in a number of other places. Currently postfix
21.12.2024 22:16, Michael Tokarev via Postfix-users wrote:
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
I suggest you take a break from high-volume extemporising, and come
back with narrow, carefully thought out issues or questions tackled
one at a time to a conclusion, with some
22.12.2024 03:39, Peter via Postfix-users wrote:
On 22/12/24 02:54, Michael Tokarev via Postfix-users wrote:
However, there are other mechanisms being developed, for example OAUTH2,
which, in terms of Cyrus SASL, does not work with saslauthd at all,
I don't see why it wouldn't.
saslauthd ha
On 21/12/24 12:37, E R via Postfix-users wrote:
Curious if there are others using the maillog_file setting who have
found that "out of the box" RHEL 8+ or 9+ will not allow Postfix to
start? I worked around the issue by creating a policy module for
testing purposes thanks to the help the SELInux
Hi!
I'm trying to get a "big picture" about how postfix works with
various SASL options. It looks like there's a big overview
missing in the docs somehow.
We've basically two big kinds of SASL mechanisms: plaintext
(which are login and plain) and non-plaintest (everything else).
The "everything
Michael Tokarev via Postfix-users:
> There's nothing in the docs saying if dovecot sasl can work with
> non-plaintext mechanisms. In almost all docs and examples I've
> found, dovecot side of the config is configured with
> "auth_mechanisms = plain login". There are some vague references
> to usa
22 matches
Mail list logo
