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 j
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
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? An
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 regularl
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
> 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 _n
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 re
> 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
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 cor
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
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 instruc
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
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-loc
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 foun
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
15 matches
Mail list logo
