Re: Authenticating clients based on CA/CN-match

[Michael Ströder]

martin f krafft wrote:

In fact, there are three options right now:

  a/ collect and deploy the fingerprints, as you say
  b/ use a self-signed certificate with life-time 99 years just for
 this purpose
  c/ use public key fingerprints instead of the cert fingerprints

I think (a) is really just ungood. I just implemented (c), which was
trivial and solves the problem. Thanks also to Daniel Kahn Gilmor
for the vital hint that made me realise Postfix 2.9 supports this.

Long-term, I think I might want to look into (b) though. I like the
idea of having a single certificate ("identity") of a host, that
then gets used in its various facets, but that's actually probably
not good security advice anyway.


Frankly I don't get why you prefer (b) over (a). If you enroll the LE 
certs in a central location then you already have the fingerprint and 
you don't have to collect them over an untrusted channel like for 
self-signed certs generated during OS installation (b). Well, you 
probably trust your SSH connection but right after OS deployment you 
have a hen-and-egg trust problem with SSH host key too.


Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Viktor Dukhovni  [2017-09-18 22:39 
+0200]:
> > No, they're all managed centrally and pushed regularly.
> 
> So, though this is not your best option, you can centrally capture
> the updated fingerprints and automate their deployment (along with
> the most recent previous fingerprint to avoid race conditions).

In fact, there are three options right now:

  a/ collect and deploy the fingerprints, as you say
  b/ use a self-signed certificate with life-time 99 years just for
 this purpose
  c/ use public key fingerprints instead of the cert fingerprints

I think (a) is really just ungood. I just implemented (c), which was
trivial and solves the problem. Thanks also to Daniel Kahn Gilmor
for the vital hint that made me realise Postfix 2.9 supports this.

Long-term, I think I might want to look into (b) though. I like the
idea of having a single certificate ("identity") of a host, that
then gets used in its various facets, but that's actually probably
not good security advice anyway.

> > At the moment, I have to assume, however, that LE wouldn't actually
> > care if I requested a cert renewal with a http-01 when I've used
> > dns-01 in the past.
> 
> I'd also be curious to know the answer to that.  Please follow-up
> if you find out.  I'm sure that enough folks here use LE certs to
> justify a slightly off-topic post.

I'll put this in my tickler file for 30 days from now.

> All that said, the case for submission based on CA authenticated
> key -> name bindings is not looking too strong.  This is not going
> to have a significant priority unless a more compelling use-case
> shows up.

Yeah, makes sense. Thanks for your patience!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"computer science is no more about computers
 than astronomy is about telescopes."
   -- edsgar w. dijkstra
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Authenticating clients based on CA/CN-match

[Michael Ströder]

martin f krafft wrote:

also sprach Viktor Dukhovni  [2017-09-18 00:31 
+0200]:

So your certral system generates the keys, and obtains the LE
certificates on behalf of the far-flung hosts?  And then pushes
these keys to the hosts over an SSH tunnel?

Is that only for the initial key issuance?  And then each host
rotates the certs independently of the central system using the
existing key to authenticate to LE?


No, they're all managed centrally and pushed regularly.


Then you have all the cert fingerprints available in a central location 
and can easily push them on your smart host. Maybe I misread something 
though.


Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authenticating clients based on CA/CN-match

[Viktor Dukhovni]

On Mon, Sep 18, 2017 at 10:09:14PM +0200, martin f krafft wrote:

> > Is that only for the initial key issuance?  And then each host
> > rotates the certs independently of the central system using the
> > existing key to authenticate to LE?
> 
> No, they're all managed centrally and pushed regularly.

So, though this is not your best option, you can centrally capture
the updated fingerprints and automate their deployment (along with
the most recent previous fingerprint to avoid race conditions).

> > I am curious why you want to rotate the submission TLS client
> > keys. If you are able to centrally push keys to the hosts, why
> > bother with a CA at all?  Why not generate a self-signed key+cert,
> > store the fingerprint in a database, and leave LE out of it?  The
> > key would not change for the lifetime of the host.
> 
> This is a very good question, and I'm blushing a bit having to admit
> that I haven't thought of that. Heck, Debian even gives you a free
> snakeoil cert on installation. I'll totally have to look into it.
> Thanks for the brainfood.

That should address your problem.  You can think of these are
complex passwords, where the server only knows the hash.  You'd
get the same security with a SASL password database that used
decently hashed passwords as a backend.  I agree that public key
fingerprints are easier to manage, as that gets SASL out of the
way.

> At the moment, I have to assume, however, that LE wouldn't actually
> care if I requested a cert renewal with a http-01 when I've used
> dns-01 in the past.

I'd also be curious to know the answer to that.  Please follow-up
if you find out.  I'm sure that enough folks here use LE certs to
justify a slightly off-topic post.

> > I should also note that with LE and certbot's "--csr" option you
> > can renew LE certificates *without* changing the public key.  In
> > which case the public key fingerprint is stable, and need not
> > change.
> 
> Hm, yes, I knew that, but I only just found out that postfix 2.9+
> can do check_ccert_access based on the public key fingerprint (not
> the certificate fingerprint). So that's that then…

The Postfix fingerprint security level does not distinguish between
certificate fingerprints and public key fingerprints.  It is assumed
computationally infeasible to take a given public key and construct
a certificate with the same hash.  That'd be a 2nd pre-image attack,
and none are known even for MD5 at present.  So the client is
accepted when the key in the lookup table matches either the
certificate or the public key.

I think I made the right call, a non-negligible number of DANE
users initially get confused about the "selector" field, and publish
the certificate digests along the public key selector (SPKI(1)
instead of Cert(0)).

> Indeed, it's not as easy as I had imagined. OTOH, it would not be
> unfathomable to iterate all SANs and check each against an access
> map. For sanity, one could introduce an upper bound. And it's
> a policy decision whether the final decision would be the min or the
> max of the set of sub-decisions…

Yes, that's possible, but not architecturally appealing.  We could
default the limit to say 10, and if the client has more than 10
names process none of them.  I'd not be a fan of processing just
a subset.

All that said, the case for submission based on CA authenticated
key -> name bindings is not looking too strong.  This is not going
to have a significant priority unless a more compelling use-case
shows up.

-- 
Viktor.

Re: Authenticating clients based on CA/CN-match

[martin f krafft]

also sprach Viktor Dukhovni  [2017-09-18 00:31 
+0200]:
> So your certral system generates the keys, and obtains the LE
> certificates on behalf of the far-flung hosts?  And then pushes
> these keys to the hosts over an SSH tunnel?
> 
> Is that only for the initial key issuance?  And then each host
> rotates the certs independently of the central system using the
> existing key to authenticate to LE?

No, they're all managed centrally and pushed regularly.

> I am curious why you want to rotate the submission TLS client
> keys. If you are able to centrally push keys to the hosts, why
> bother with a CA at all?  Why not generate a self-signed key+cert,
> store the fingerprint in a database, and leave LE out of it?  The
> key would not change for the lifetime of the host.

This is a very good question, and I'm blushing a bit having to admit
that I haven't thought of that. Heck, Debian even gives you a free
snakeoil cert on installation. I'll totally have to look into it.
Thanks for the brainfood.

> DNSSEC helps with having CAA records that are difficult to MiTM,
> and protectst the DNS challenge protocol, but I don't whether it
> is possible to disable bootstrapping over weaker email challenges
> and/or control over port 80.

This is another excellent point I'lll bring up with the LE folks: if
I go through lengths securing my DNS chain for their challenges,
I'd like to be able to lock my account onto that, a bit like HSTS.
At the moment, I have to assume, however, that LE wouldn't actually
care if I requested a cert renewal with a http-01 when I've used
dns-01 in the past.

Anyway, this is getting vastly off-topic… sorry about that.

> I should also note that with LE and certbot's "--csr" option you
> can renew LE certificates *without* changing the public key.  In
> which case the public key fingerprint is stable, and need not
> change.

Hm, yes, I knew that, but I only just found out that postfix 2.9+
can do check_ccert_access based on the public key fingerprint (not
the certificate fingerprint). So that's that then…

> The reason I am asking them is not because I've decided to not
> implement access by subject name (though given the SAN situation,
> and the potentially large number of SANs to test, the feature is
> tricky to implement fully and correctly).

Indeed, it's not as easy as I had imagined. OTOH, it would not be
unfathomable to iterate all SANs and check each against an access
map. For sanity, one could introduce an upper bound. And it's
a policy decision whether the final decision would be the min or the
max of the set of sub-decisions…

Thanks a lot for this enlightening exchange.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
takt ist der auf das benehmen angewandte gute geschmack.
  -- nicolas de chamfort
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Mixing of address classes per domain

[Viktor Dukhovni]

> On Sep 18, 2017, at 12:59 PM, Andreas Thienemann  wrote:
> 
>> * ONLY domains that contain no real recipients to be
>> handed off to some transport for delivery may be
>> listed in virtual_alias_domains.
> 
> So just to confirm: virtual_alias_maps is also consulted for a match for
> addresses _not_ listed in virtual_alias_domains?

Virtual alias rewriting applies to *all* recipients, regardless of address
class.

>> Therefore you can have in virtual_alias_maps:
>> 
>>  # The dreaded catchall applies to all mailboxes that
>>   # are not explicitly mapped to themselves or out of the
>>  # domain
>>  @real.example.com   catc...@local.example.com
>>  j...@real.example.com   j...@real.example.com
> 
> What does the mapping of the mailbox to itself do? I had not seen
> that before in the docs.

It avoids hitting the catch-all for that address.  More specific
lookup keys preëmpt less-specific lookup keys, but keep in mind
that rewriting is recursive and stops only when:

   * A lookup key maps to itself, OR
   * A lookup key is not found, Or
   * The recursion limit is reached

Otherwise, the RHS of a lookup becomes the LHS of the next lookup
up to the recursion limit.

>> and then in transport_maps:
>> 
>>  j...@real.example.com   uucp
>> 
>> or, conversely
>> 
>>  real.example.comuucp
>> 
>> If the majority of users that stay in @real.example.comm use that
>> transport.
> 
> During my testing the transport_maps entry seemed to not have been
> consulted, but then again I also did not have the j...@real.example.com
> mapping back to itself. Is that entry needed in such a form?

Transport selection happens downstream of virtual alias rewriting.
If the address rewrites to something else, transport lookup is
based on the final output of virtual alias rewriting.

-- 
Viktor.

Re: Mixing of address classes per domain

[Andreas Thienemann]

Hi Viktor,

On Mon, 18 Sep 2017, Viktor Dukhovni wrote:

As far as I understand, the virtual_alias_maps will only do rewriting 
to local or remote addresses but disregard transport entries.


No, this is not the case.  All that happens with virtual_alias_maps
is recursive rewriting of all input recipient addresses to some final
address.


Ah okay. Then I misunderstood the documentation there. Thanks for 
clarifying this.


[...]

and the only constraints are:

* Each domain belongs to exactly one address class.

That was clear already from the existing documentation.


* ONLY domains that contain no real recipients to be
 handed off to some transport for delivery may be
 listed in virtual_alias_domains.


So just to confirm: virtual_alias_maps is also consulted for a match for 
addresses _not_ listed in virtual_alias_domains?




Therefore you can have in virtual_alias_maps:

# The dreaded catchall applies to all mailboxes that
   # are not explicitly mapped to themselves or out of the
# domain
@real.example.com   catc...@local.example.com
j...@real.example.com   j...@real.example.com


What does the mapping of the mailbox to itself do? I had not seen that 
before in the docs.




and then in transport_maps:

j...@real.example.com   uucp

or, conversely

real.example.comuucp

If the majority of users that stay in @real.example.comm use that
transport.


During my testing the transport_maps entry seemed to not have been 
consulted, but then again I also did not have the j...@real.example.com 
mapping back to itself. Is that entry needed in such a form?


cheers,
 Andreas

Re: Mixing of address classes per domain

[Viktor Dukhovni]

> On Sep 18, 2017, at 11:35 AM, Andreas Thienemann  wrote:
> 
> As far as I understand, the virtual_alias_maps will only do rewriting to 
> local or remote addresses but disregard transport entries.

No, this is not the case.  All that happens with virtual_alias_maps
is recursive rewriting of all input recipient addresses to some final
address.

It is virtual_alias_domains that preempts transport selection for
addresses that are NOT rewritten to some real domain.  Thus you
can have:

mydestination = local.example.com, ...
relay_domains = real.example.com, ...
virtual_alias_domains = valias.example.com, ...
virtual_mailbox_domains = vmbox.example.com, ...

and the only constraints are:

* Each domain belongs to exactly one address class.
* ONLY domains that contain no real recipients to be
  handed off to some transport for delivery may be
  listed in virtual_alias_domains.

Therefore you can have in virtual_alias_maps:

# The dreaded catchall applies to all mailboxes that
# are not explicitly mapped to themselves or out of the
# domain
@real.example.com   catc...@local.example.com
j...@real.example.com   j...@real.example.com

and then in transport_maps:

j...@real.example.com   uucp

or, conversely

real.example.comuucp

If the majority of users that stay in @real.example.comm use that
transport.

-- 
Viktor.

Mixing of address classes per domain

[Andreas Thienemann]

Hi,

I have inherited an older postfix and sendmail system with a cyrus imapd. 
My plan now is to migrate that to a postfix 3.x MTA with a dovecot imap 
backend.

Pretty standard so far.

When trying to migrate the existing mail routing logic I did come accross 
certain rules which are working correctly on the old system but where I am 
having problems fitting them into the current address classes logic.


Local addresses are handled currently through a mailbox_transport = 
lmtp:private/dovecot-lmtp entry. This is working fine for addresses 
directed at hosts listed at mydestination.


I do have a handfull of users received mail via UUCP which I am handling 
as members relay domain class. These I have configured with a 
relay_domains lookup table containing full hostnames such as 
"foo.example.com OK" and a transport_maps entry of "foo.example.com 
uucp:foo". This too is working well.
I also have a few FQDNs where the nexthop is a smtp server, where the 
setup is handled via relay_domains and transport_maps as well.


Where I am a bit unsure is how I want to handle the virtual addresses.
I do have a bunch of domains for which I want postfix to handle mail and 
deliver mainly to local users via lmtp to dovecot.


My initial plan was to use the virtual_alias_domains and 
virtual_alias_maps entries to ensure correct delivery for these addresses.

My routing rules here are as follows:
f...@bar.example.com -> foo
@bar.example.com -> bar
@foobar.example.com -> b...@example.com

99% of these target addresses/values are local accounts with no either no 
domain or example.com which is part of the mydestinations entry.

For these, traffic is correctly delivered.

My problem is, I do have a handful of domains where routing is very mixed.
I might have a catchall account @baz.example.com -> baz but I have _also_ 
a need to route the more specific b...@baz.example.com -> uucp:bar.


As far as I understand, the virtual_alias_maps will only do rewriting to 
local or remote addresses but disregard transport entries.


I would really prefer _not_ to create any workarounds where I redirect 
b...@baz.example.com to b...@bar.uucp.example.com which then is added to 
relay_domains and gets a transport entry. The existing setup seemed to be 
able to cope directly with the redirect to uucp rather than needing any 
workarounds.


Does anyone have a hint how to get this working correctly? Adding the 
domain to both virtual_domains and relay_domains seems to work but as far 
as I understand previous discussions here on the list this is a rather bad 
idea.


Cheers,
 Andreas

Re: using postfix as a smart relay for many servers

[Wietse Venema]

Jason Miller:
> Hi, I'm using Postfix to relay from my internal network, through postfix,
> to mandrill, on to the destination. The issue is that I have multiple
> internal servers, but once it gets to mandrill they all look like one
> because the instructions I found only allowed for one mandrill relay. I
> found instructions how to use a different relay depending on the domain in
> the to: field, but how do I have it select the smart relay based on the
> application server sending the email? The way mandrill works is it
> separates mail into queues based on the username and password provided. So
> the end result is effectively that all application servers have the same
> server and username, but different passwords. Is this possible?

You want to forward mail destined for 'u...@example.com' to different
smart hosts depending on the application server sending the mail
to Postfix?

Basically, index a table by SMTP client (name or IP address) and
use FILTER in a creative manner:

/etc/postfix/main.cf:
smtpd_client_restrictions = hash:/etc/postfix/app-server-access

/etc/postfix/app-server-access:
app-server-1filter smtp:mandril1.example.com
app-server-2filter smtp:mandril2.example.com

(instead of hash: use whatever is appropriate for your systems).

This use of the FILTER command is fully supported.

Wietse

using postfix as a smart relay for many servers

[Jason Miller]

Hi, I'm using Postfix to relay from my internal network, through postfix,
to mandrill, on to the destination. The issue is that I have multiple
internal servers, but once it gets to mandrill they all look like one
because the instructions I found only allowed for one mandrill relay. I
found instructions how to use a different relay depending on the domain in
the to: field, but how do I have it select the smart relay based on the
application server sending the email? The way mandrill works is it
separates mail into queues based on the username and password provided. So
the end result is effectively that all application servers have the same
server and username, but different passwords. Is this possible?

Re: Communication between Postfix and Dovecot LDA

[Daniel Ryšlink]

Thank you very much, this is most useful.

One more question, if I may - besides full mailboxes, there is also a 
problem with domain aliases containing non-existent mailboxes.


For example, I have this definition in virtual_mailbox_domains:

@prefix.domain.com@domain.com

That means mail to u...@prefix.domain.com is delivered to u...@domain.com.

However, if u...@domain.com does not exist, the Postfix that handles 
incoming mail accepts the mail, passes it to DSpam, and only Dovecot-lda 
finds out that the actual mailbox does not exist, and an error mail is 
generated.


I would like to limit backscatter mail generated by my server, because I 
have found out that there are attacks employing bogus domains that put 
the target machine into their MX records and then send mails from these 
bogus domains to users with full mailboxes, etc, which results in 
flooding of the target server with backscatter mail.


So, is there a way for the postfix to determine that a particular 
mailbox @prefix.domain.com will accept the incoming mail, before it 
accepts the mail and hands it over to DSpam?


I am sorry, I have the feeling that I have overlooked something basic 
here, but I have spent much time on this problem, and I promise this is 
my last question regarding the topic.


Thank you very much in advance for any hints.

--
S pozdravem,
Daniel Ryšlink
System Administrator

Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---

On 18.9.2017 14:31, Christian Kivalo wrote:

On 2017-09-18 14:21, Daniel Ryšlink wrote:

Hello,

I am trying to solve a problem with error mails clogging my queue on a
system with the following components:

Incoming mail -> Postfix -> DSpam -> reinjection back to postfix queue
-> Dovecot LDA

The system also handles outgoing mail for non-local users, for any
mail address not found in a table of local users, Postfix just tries
to deliver it according to the MX records.

However, the Postfix handling the incoming messages for local users
(before DSpam) has incomplete information whether the local delivery
will be successful. I would like to immediately reject mails for
mailboxes that are full, for example, but the Postfix does not have
this information. That means that the mail is initially accepted,
passed to DSPam, and only the Dovecot LDA founds out that the mailbox
is full, and generates an error mail message, that is often not
deliverable and clogs the mailqueue.

I would like to reject as many mails as possible during the intial
SMTP session, as a part of the "check_recipient_access" phase. Is
there any way for Postfix to ask dovecot-lda "Will you be able to
locally deliver a message to this user"? I have read dovecot-lda man
page, but did not find any option of "dry" or test delivery. I
understand that Postfix can use a "policy server" - an external script
or daemon that could query dovecot for this information, but so far I
have failed to find a proper way to query dovecot to find out if a
specific mail would be deliverable.
Dovecot provides a quota service, a policy service that can be used by 
postfix.


Take a look at the dovecot wiki for the quota service: 
https://wiki2.dovecot.org/Quota


From the wiki:
Quota service

The quota service allows postfix to check quota before delivery:

service quota-status {
executable = quota-status -p postfix
inet_listener {
port = 12340
# You can choose any port you want
}
client_limit = 1
}

And then have postfix check_policy_service check that:

smtpd_recipient_restrictions =
...
check_policy_service inet:mailstore.example.com:12340

For more about this service see 
https://sys4.de/en/blog/2013/04/08/postfix-dovecot-mailbox-quota/




I know I will be probably referred to Dovecot mailing lists, but I
thought some of you could know the answer.

Thank you in advance for any hint or advice.

--
S pozdravem,
Daniel Ryšlink
System Administrator

Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---

Re: Communication between Postfix and Dovecot LDA

[Christian Kivalo]

On 2017-09-18 14:21, Daniel Ryšlink wrote:

Hello,

I am trying to solve a problem with error mails clogging my queue on a
system with the following components:

Incoming mail -> Postfix -> DSpam -> reinjection back to postfix queue
-> Dovecot LDA

The system also handles outgoing mail for non-local users, for any
mail address not found in a table of local users, Postfix just tries
to deliver it according to the MX records.

However, the Postfix handling the incoming messages for local users
(before DSpam) has incomplete information whether the local delivery
will be successful. I would like to immediately reject mails for
mailboxes that are full, for example, but the Postfix does not have
this information. That means that the mail is initially accepted,
passed to DSPam, and only the Dovecot LDA founds out that the mailbox
is full, and generates an error mail message, that is often not
deliverable and clogs the mailqueue.

I would like to reject as many mails as possible during the intial
SMTP session, as a part of the "check_recipient_access" phase. Is
there any way for Postfix to ask dovecot-lda "Will you be able to
locally deliver a message to this user"? I have read dovecot-lda man
page, but did not find any option of "dry" or test delivery. I
understand that Postfix can use a "policy server" - an external script
or daemon that could query dovecot for this information, but so far I
have failed to find a proper way to query dovecot to find out if a
specific mail would be deliverable.
Dovecot provides a quota service, a policy service that can be used by 
postfix.


Take a look at the dovecot wiki for the quota service: 
https://wiki2.dovecot.org/Quota


From the wiki:
Quota service

The quota service allows postfix to check quota before delivery:

service quota-status {
executable = quota-status -p postfix
inet_listener {
port = 12340
# You can choose any port you want
}
client_limit = 1
}

And then have postfix check_policy_service check that:

smtpd_recipient_restrictions =
...
check_policy_service inet:mailstore.example.com:12340

For more about this service see 
https://sys4.de/en/blog/2013/04/08/postfix-dovecot-mailbox-quota/




I know I will be probably referred to Dovecot mailing lists, but I
thought some of you could know the answer.

Thank you in advance for any hint or advice.

--
S pozdravem,
Daniel Ryšlink
System Administrator

Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---


--
 Christian Kivalo

Communication between Postfix and Dovecot LDA

[Daniel Ryšlink]

Hello,

I am trying to solve a problem with error mails clogging my queue on a 
system with the following components:


Incoming mail -> Postfix -> DSpam -> reinjection back to postfix queue 
-> Dovecot LDA


The system also handles outgoing mail for non-local users, for any mail 
address not found in a table of local users, Postfix just tries to 
deliver it according to the MX records.


However, the Postfix handling the incoming messages for local users 
(before DSpam) has incomplete information whether the local delivery 
will be successful. I would like to immediately reject mails for 
mailboxes that are full, for example, but the Postfix does not have this 
information. That means that the mail is initially accepted, passed to 
DSPam, and only the Dovecot LDA founds out that the mailbox is full, and 
generates an error mail message, that is often not deliverable and clogs 
the mailqueue.


I would like to reject as many mails as possible during the intial SMTP 
session, as a part of the "check_recipient_access" phase. Is there any 
way for Postfix to ask dovecot-lda "Will you be able to locally deliver 
a message to this user"? I have read dovecot-lda man page, but did not 
find any option of "dry" or test delivery. I understand that Postfix can 
use a "policy server" - an external script or daemon that could query 
dovecot for this information, but so far I have failed to find a proper 
way to query dovecot to find out if a specific mail would be deliverable.


I know I will be probably referred to Dovecot mailing lists, but I 
thought some of you could know the answer.


Thank you in advance for any hint or advice.

--
S pozdravem,
Daniel Ryšlink
System Administrator

Dial Telecom a. s.
Křižíkova 36a/237
186 00 Praha 3, Česká Republika
Tel.:+420.226204627
daniel.rysl...@dialtelecom.cz
---
www.dialtelecom.cz
Dial Telecom, a.s.
Jednoduše se připojte
---

Re: Authenticating clients based on CA/CN-match

[Marat Khalili]

A very interesting discussion...

On 17/09/17 22:49, Viktor Dukhovni wrote:

There is no meaningful ordering of SANs.
Can you explain a bit more detail here? (c) :) I though you can list 
SANs in the order you want in your certificate request and everything 
else will preserve it, and that applies to Let's Encrypt signed 
certificates too?


(Also, in case of OP, why couldn't LE certificate with single SAN be 
obtained for each client?)


--

With Best Regards,
Marat Khalili