Hey,
i have withdrawn from
Jaroslaw Rafa wrote in
<20200826083557.ga15...@rafa.eu.org>:
|Dnia 25.08.2020 o godz. 23:39:43 Steffen Nurpmeso pisze:
|> Usually you be given a username and a password, and a server name
|> and a port. That you enter into the MUA, and the rest you do not
|> know.
Dnia 25.08.2020 o godz. 23:39:43 Steffen Nurpmeso pisze:
> Usually you be given a username and a password, and a server name
> and a port. That you enter into the MUA, and the rest you do not
> know. (Unless you use a real primitive MUA, where you have to be
> explicit.)
I would say the opposite:
Viktor Dukhovni wrote in
<20200825182533.gw37...@straasha.imrryr.org>:
|On Tue, Aug 25, 2020 at 07:06:29PM +0200, Steffen Nurpmeso wrote:
|
|>|because:
|>|
|>|1. The server indicated support for SASL in its EHLO response.
|>|2. The client chose to perform SASL auth.
|>|
|>|If you
On Tue, Aug 25, 2020 at 07:06:29PM +0200, Steffen Nurpmeso wrote:
> |because:
> |
> |1. The server indicated support for SASL in its EHLO response.
> |2. The client chose to perform SASL auth.
> |
> |If you want clients to skip SASL auth, configure them to not use
> |SASL auth (no
Viktor Dukhovni wrote in
<20200825160538.gt37...@straasha.imrryr.org>:
|On Tue, Aug 25, 2020 at 04:56:26PM +0200, Steffen Nurpmeso wrote:
|> Emmanuel Fusté wrote in
|> :
|>|Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :
|>|> Something else, maybe.
|>|> I do not understand why my (stupid)
Viktor Dukhovni wrote in
<20200825161847.gu37...@straasha.imrryr.org>:
|On Tue, Aug 25, 2020 at 05:56:41PM +0200, Steffen Nurpmeso wrote:
|You have still now answered Wietse's question. If you were to do
|"EXTERNAL" auth, what determines whether a user presented a valid
|credential, and
On Tue, Aug 25, 2020 at 05:56:41PM +0200, Steffen Nurpmeso wrote:
> Twenty years ago i was an angry young man because the new German
> passports did not include S/MIME++ certificates and PGP keys,
> signed by the German government. In the meantime the
> "Bundesdruckerei" (which has become more
On Tue, Aug 25, 2020 at 04:56:26PM +0200, Steffen Nurpmeso wrote:
> Emmanuel Fusté wrote in
> :
> |Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :
> |> Something else, maybe.
> |> I do not understand why my (stupid) config
> |>
> |>smtpd_sender_restrictions =
> |>check_ccert_a
Hello.
Wietse Venema wrote in
<4bbwrb5qbbzj...@spike.porcupine.org>:
|What is the trust model: can anyone send email as long as they have
|a valid certificate that is signed by one of hundreds of CAs, and
I am a political person and can only response to this politically.
Other than that i do n
Emmanuel Fusté wrote in
:
|Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :
|> Something else, maybe.
|> I do not understand why my (stupid) config
|>
|>smtpd_sender_restrictions =
|>check_ccert_access hash:/etc/postfix/relay_clientcert,
|>permit_tls_clientcerts,
|>
What is the trust model: can anyone send email as long as they have
a valid certificate that is signed by one of hundreds of CAs, and
as long as their certificate contains an email address that matches
smtpd_sender_login_maps?
Wietse
Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :
Something else, maybe.
I do not understand why my (stupid) config
smtpd_sender_restrictions =
check_ccert_access hash:/etc/postfix/relay_clientcert,
permit_tls_clientcerts,
reject_unknown_sender_domain,
#reject_sender
Viktor Dukhovni wrote in
<20200823024200.go37...@straasha.imrryr.org>:
|On Sun, Aug 23, 2020 at 02:36:51AM +0200, Steffen Nurpmeso wrote:
...
|I think that there's a major semantic problem here. The code validating
|the certificate chain against some issuer(s) trusted to identify local
|user
Hello and good evening!
Please excuse the late replay.
Wietse Venema wrote in
<4bzhbq2rngzj...@spike.porcupine.org>:
|Viktor Dukhovni:
|> On Sun, Aug 23, 2020 at 02:36:51AM +0200, Steffen Nurpmeso wrote:
...
|Annd if you must pass additional information to the Dovecot auth
|server, the prop
Viktor Dukhovni:
> On Sun, Aug 23, 2020 at 02:36:51AM +0200, Steffen Nurpmeso wrote:
>
> > However, short of time (it will be no sooner than six o'clock in
> > the morning until i will get home, sorry! Just in case anyone is
> > interested), i blindly added another cert_username=steffen to the
>
On Sun, Aug 23, 2020 at 02:36:51AM +0200, Steffen Nurpmeso wrote:
> However, short of time (it will be no sooner than six o'clock in
> the morning until i will get home, sorry! Just in case anyone is
> interested), i blindly added another cert_username=steffen to the
> stuff in src/xsasl/xsasl_do
Hello!
Steffen Nurpmeso wrote in
<20200820232547.x0nbc%stef...@sdaoden.eu>:
...
|Wietse Venema wrote in
| <4bxstk189nzj...@spike.porcupine.org>:
||Steffen Nurpmeso:
||> Wietse Venema wrote in
||> <4bwxll093mzj...@spike.porcupine.org>:
||>|Steffen Nurpmeso:
...
||>|Short summary: Postfix
Viktor Dukhovni wrote in
<20200820163012.gl86...@straasha.imrryr.org>:
|On Thu, Aug 20, 2020 at 10:59:06AM -0400, Wietse Venema wrote:
|
|> There's a chicken and egg question in there somewhere.
|>
|> https://wiki1.dovecot.org/Authentication%20Protocol mentions
|> two attributes that might
Good evening from Germany.
Please excuse the late reply, it is midsummer here and i spend as
much time as possible on the outside (mostly bicycling). (And
just one more day, then the weather will change and it will be 10
degrees colder.)
Wietse Venema wrote in
<4bxstk189nzj...@spike.porcupine.o
On Thu, Aug 20, 2020 at 10:59:06AM -0400, Wietse Venema wrote:
> There's a chicken and egg question in there somewhere.
>
> https://wiki1.dovecot.org/Authentication%20Protocol mentions
> two attributes that might be relevant, and that Postfix can send:
>
> secured
> Remote user has secured t
Steffen Nurpmeso:
> Hello.
>
> Wietse Venema wrote in
> <4bwxll093mzj...@spike.porcupine.org>:
> |Steffen Nurpmeso:
> |> I have no idea of the inner sensitivities of postfix, but i do not
> |> understand where the problem lies. Why does postfix "wave
> |> through" the SASL offering of EXTERN
Hello.
Wietse Venema wrote in
<4bwxll093mzj...@spike.porcupine.org>:
|Steffen Nurpmeso:
|> I have no idea of the inner sensitivities of postfix, but i do not
|> understand where the problem lies. Why does postfix "wave
|> through" the SASL offering of EXTERNAL when it does not support
|> it
Steffen Nurpmeso:
> I have no idea of the inner sensitivities of postfix, but i do not
> understand where the problem lies. Why does postfix "wave
> through" the SASL offering of EXTERNAL when it does not support
> it? (I have no idea of SASL library interfaces.)
Short summary: Postfix does no
Hello.
I am new to this list, and only come here to continue on this old
thread. I have restored it from
X-MARC-Message: https://marc.info/?l=postfix-users&m=155674111415072
so message-id etc. may not truly be correct, i apologise for that.
And also, first, thank you for postfix, i use it for
Thomas Quinot:
> * Wietse Venema, 2020-05-09 :
>
> > It was implemented in and removed from the un_stable Postfix release.
>
> Thanks for confirming this!
>
> > If you want to avoid incompatible changes, use a stable Postfix
> > release instead.
>
> Sure, that's perfectly fair, and I'm not com
* Wietse Venema, 2020-05-09 :
> It was implemented in and removed from the un_stable Postfix release.
Thanks for confirming this!
> If you want to avoid incompatible changes, use a stable Postfix
> release instead.
Sure, that's perfectly fair, and I'm not complaining about the
removal of the f
Thomas Quinot:
> * Wietse Venema, 2020-05-08 :
>
> > > As far as I can tell, support for issuer and subject CN lookup
> > > was removed on 20200316. Is my understanding correct that support
> >
> > As far as I know it was never implemented.
>
> Sorry, I probably misunderstood the code while read
* Wietse Venema, 2020-05-08 :
> > As far as I can tell, support for issuer and subject CN lookup
> > was removed on 20200316. Is my understanding correct that support
>
> As far as I know it was never implemented.
Sorry, I probably misunderstood the code while reading it.
For the record, the cha
On Sat, May 18, 2019 at 11:01:28AM -0400, Wietse Venema wrote:
> After a week of testing, Postfix snapshot 20190518 implements support
> for:
>
> smtpd_mumble_restrictions =
> ...
> check_ccert_access {
> maptype:mapname, { search_order = cert_fingerprint,
> pubkey_finge
Thomas Quinot:
> * Wietse Venema, 2019-05-18 :
>
> > smtpd_mumble_restrictions =
> > ...
> > check_ccert_access {
> > maptype:mapname, { search_order = cert_fingerprint,
> > pubkey_fingerprint, subject, issuer }
> > }
> > ...
> >
> > Where subject (or issuer) will
* Wietse Venema, 2019-05-18 :
> smtpd_mumble_restrictions =
> ...
> check_ccert_access {
> maptype:mapname, { search_order = cert_fingerprint,
> pubkey_fingerprint, subject, issuer }
> }
> ...
>
> Where subject (or issuer) will search maptype:mapname for a match
Wietse Venema:
> Continuing the discussion of a strawman user interface, I see some
> opportunities to generalize this and to make some improvements
> elsewhere in Postfix.
>
> We start with Postfix access control based on client certificate
> feartures:
>
> smtpd_mumble_restrictions =
> ...
On 01/05/2019 22:04, Viktor Dukhovni wrote:
> On Wed, May 01, 2019 at 09:57:29PM +0200, John Fawcett wrote:
>
>>> virtual_alias_maps = {
>>> hash:/etc/postfix/virtual,
>>> { search = full, full-noext, localpart-if-local, at-domain }
>>> } {
>>> other table ...
>>>
On Wed, May 01, 2019 at 09:57:29PM +0200, John Fawcett wrote:
> > virtual_alias_maps = {
> > hash:/etc/postfix/virtual,
> > { search = full, full-noext, localpart-if-local, at-domain }
> > } {
> > other table ...
> > }
> >
> > Ditto for canonical_maps and transp
On 28/04/2019 21:49, Wietse Venema wrote:
> ...
>
> Once the above is implemented, the same approach could be used to
> improve other parts of Postfix by making existing hard-coded behavior
> configurable, for example how check_client_access looks up subnet
> and partial address information, or how
Continuing the discussion of a strawman user interface, I see some
opportunities to generalize this and to make some improvements
elsewhere in Postfix.
We start with Postfix access control based on client certificate
feartures:
smtpd_mumble_restrictions =
...
check_tls_access {
m
Zitat von Viktor Dukhovni :
On Apr 19, 2019, at 1:10 PM, Wietse Venema wrote:
Using a name instead of cert fingerprint also requires revocation checking.
Cert revocation is not needed, as long as there is an an explicit
mapping like:
certificate identity -> permit/etc action
certif
Viktor Dukhovni:
> > Cert revocation is not needed, as long as there is an an explicit
> > mapping like:
> >
> >certificate identity -> permit/etc action
> >certificate identity -> ersatz SASL login name
> >
> > By removing such a mapping, one can 'revoke' the privileges that
> > were ass
On 4/20/19 1:09 AM, Viktor Dukhovni wrote:
On Apr 19, 2019, at 6:42 PM, Michael Ströder wrote:
If a cert's key get compromised (e.g. laptop lost/stolen) I expect
the user's cert to be revoked and a new cert to be issued for the
*same* subject name. How to deal with that without revocation
check
> On Apr 19, 2019, at 6:42 PM, Michael Ströder wrote:
>
> If a cert's key get compromised (e.g. laptop lost/stolen) I expect the user's
> cert to be revoked and a new cert to be issued for the *same* subject name.
> How to deal with that without revocation check?
Delete the name match, and
On 4/19/19 7:10 PM, Wietse Venema wrote:
Michael Str?der:
On 4/18/19 9:45 PM, Viktor Dukhovni wrote:
On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).
I am not convinc
> On Apr 19, 2019, at 1:10 PM, Wietse Venema wrote:
>
>> Using a name instead of cert fingerprint also requires revocation checking.
>
> Cert revocation is not needed, as long as there is an an explicit
> mapping like:
>
>certificate identity -> permit/etc action
>certificate identity -
Michael Str?der:
> On 4/18/19 9:45 PM, Viktor Dukhovni wrote:
> >> On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
> >>
> >> Eventually there will be a postfix--nonprod release that combines
> >> all the code (jay) and none of the guarantees (bleh).
> >>
> >> I am not convinced that stuffin
On 4/18/19 9:45 PM, Viktor Dukhovni wrote:
On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).
I am not convinced that stuffing arbitrary PKI identities into a
SASL identi
lst_ho...@kwsoft.de:
>
> Zitat von Wietse Venema :
>
> > lst_ho...@kwsoft.de:
> >> What is the way to go to take part of the feature development? I looks
> >> like we need a slight modification of the auth external as described.
> >
> > Mailin glist discussions.
> >
> > Eventually there will be a
Le 18/04/2019 à 21:45, Viktor Dukhovni a écrit :
On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of the guarantees (bleh).
I am not convinced that stuffing arbitrary PKI identities into a
SASL
> On Apr 18, 2019, at 12:01 PM, Wietse Venema wrote:
>
> Eventually there will be a postfix--nonprod release that combines
> all the code (jay) and none of the guarantees (bleh).
>
> I am not convinced that stuffing arbitrary PKI identities into a
> SASL identity is necessarily a good idea.
Zitat von Wietse Venema :
lst_ho...@kwsoft.de:
What is the way to go to take part of the feature development? I looks
like we need a slight modification of the auth external as described.
Mailin glist discussions.
Eventually there will be a postfix--nonprod release that combines
all th
lst_ho...@kwsoft.de:
> What is the way to go to take part of the feature development? I looks
> like we need a slight modification of the auth external as described.
Mailin glist discussions.
Eventually there will be a postfix--nonprod release that combines
all the code (jay) and none of th
Zitat von Emmanuel Fusté :
You need the relay_clientcerts map with relay_clientcerts_auto mode.
Put the fingerprint or pkey_fingerprint and the mapped SASL identity
in the file and it will work
For example:
43:B6:FE:07:BB:2E:BF:86:8A:4D:2A:DD:78:07:09:C6 xxx.kwsoft.de
Will try that, bu
Le 18/04/2019 à 12:05, lst_ho...@kwsoft.de a écrit :
Zitat von Emmanuel Fusté :
Hello,
Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.
Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and
Zitat von Emmanuel Fusté :
Hello,
Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.
Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and
Victor, which adds an option smtpd_sasl_tls_ccert
Zitat von Wietse Venema :
lst_ho...@kwsoft.de:
This sounds like the feature we will need. I doubt the client would be
able to do real AUTH, but we have to trust/relay based on the CN of a
validated certificate. Is there any progress merging this in the 3.5
line or do i have to poke around wit
lst_ho...@kwsoft.de:
> This sounds like the feature we will need. I doubt the client would be
> able to do real AUTH, but we have to trust/relay based on the CN of a
> validated certificate. Is there any progress merging this in the 3.5
> line or do i have to poke around with patches some lon
Zitat von Emmanuel Fusté :
Le 27/03/2019 à 18:10, Emmanuel Fusté a écrit :
Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :
On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts,
Le 27/03/2019 à 18:10, Emmanuel Fusté a écrit :
Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :
On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is
Le 27/03/2019 à 17:14, Viktor Dukhovni a écrit :
On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
The goal is to be as transparent as possible :
- if the client is not found in the relay_clientcerts, act as usual
- if the client is found in the relay_clientcerts, no longer announ
On Wed, Mar 27, 2019 at 04:31:33PM +0100, Emmanuel Fusté wrote:
> The goal is to be as transparent as possible :
> - if the client is not found in the relay_clientcerts, act as usual
> - if the client is found in the relay_clientcerts, no longer announce
> AUTH support, the auth and identity mapp
Hello,
Great piece of work ! It solve a big part of my problem, but sadly I
need to go deeper.
Le 18/03/2019 à 22:45, Bastian Schmidt a écrit :
In the meantime I have completed a patch and sent it to Wietse and
Victor, which adds an option smtpd_sasl_tls_ccert_username.
As the patch is rathe
In the meantime I have completed a patch and sent it to Wietse and
Victor, which adds an option smtpd_sasl_tls_ccert_username.
As the patch is rather small, I also attached it to this message.
This smtpd_sasl_tls_ccert_username option can be used in the following way:
Using smtpd_sasl_tls_ccert
> On Jan 8, 2019, at 5:17 PM, Bastian Schmidt <[hidden email]> wrote:
>
> I have an email client (K-9 on Android), which, when using TLS client
> certificates insists on sending an auth external. However, postfix/SASL
> does not advertise external auth, which causes the client to not being
> able
Bastian Schmidt:
> Shall I remove the check again? After all, it's just a simple if and
> won't hurt. In case later someone makes initialization conditional it
> would prevent the segfault.
Removing this initialization would be a bad idea. The way the
code works is that all table variables are
> On Jan 8, 2019, at 5:17 PM, Bastian Schmidt wrote:
>
> I have an email client (K-9 on Android), which, when using TLS client
> certificates insists on sending an auth external. However, postfix/SASL does
> not advertise external auth, which causes the client to not being able to use
> client
Hello,
I have an email client (K-9 on Android), which, when using TLS client
certificates insists on sending an auth external. However, postfix/SASL
does not advertise external auth, which causes the client to not being
able to use client certificates with postfix.
As I see it, postfix is mi
64 matches
Mail list logo
