Support for "Linux 5"

[Scott Kitterman]

I understand that the next Linux release will have a major version of 5.  This 
doesn't portend any technical changes.  As has happened the last few times 
linux 5 should be no different than 4 which was no different than 3.

It looks to me like the postfix 3.4 makedefs still have:

 Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR

Is it too late to add 5?

Scott K

panic after upgrading to 3.3.2 from 3.3.0

[Tamás Gérczei]

Hello List,

I'd like to ask whether You're aware of any change which might cause
breakage in my setup involving spamc with a completely unchanged
configuration in between - I'm getting the following error:

*"panic: master_reap: unknown pid"*

I'm running Docker containers from Alpine images orchestrated by
Kubernetes on ARMv6 with all services running in separate pods, but I
have also tested on Debian to figure out whether it's an Alpine-specific
problem - alas, it also occurs on Debian. The fatal step is invoking
spamc via pipe, although that succeeds since spamd does receive the
call, that is proven. (Everything is alright until that call is made,
and then it reproducibly perishes every single time.) Spamd is 3.4.2
even in working cases, but failures also occur with both 3.4.1 and 3.4.2
client versions. I've spent 2 days trying to debug this on my own, but
fail to comprehend the root cause of the problem, not even when diff'ing
'postconf -x' outputs. I thought it's either a different spamc version
exiting in an unexpected manner or the pipe service handling exits from
external processes differently, but changing spamc versions doesn't
change the symptom, plus the code for pipe in Postfix doesn't seem to
have changed in several years now. As hinted, reverting to a container
with 3.3.0 immediately fixes the problem, but I'd like to be able to
upgrade.

Could You please assist me figure out what's going wrong here?
Documentation says panics are meant to be resolved by the developers, so
this is a justified call for help - I'd be happy to supply any
information necessary.

Thanks,
Tamás

Re: panic after upgrading to 3.3.2 from 3.3.0

[Wietse Venema]

Tam?s G?rczei:
> Hello List,
> 
> I'd like to ask whether You're aware of any change which might cause
> breakage in my setup involving spamc with a completely unchanged
> configuration in between - I'm getting the following error:
> 
> *"panic: master_reap: unknown pid"*

Is the Postfix master daemon running as PID 1? Historically this
PID was reserved for the init daemon which becomes the parent of
orphaned processes, i.e. processes that terminate without a parent
waiting for them. Postfix does not create such processes, but if
you run other programs inside the Postfix container then they
might do that.

Options:

- Run Postfix as PID != 1.

- Don't co-locate Postfix with other software. That means pipe into
socket instead of into a program in the same container.

- Make the master sloppier, and accept events from processes that
it did not create.

Wietse

> I'm running Docker containers from Alpine images orchestrated by
> Kubernetes on ARMv6 with all services running in separate pods, but I
> have also tested on Debian to figure out whether it's an Alpine-specific
> problem - alas, it also occurs on Debian. The fatal step is invoking
> spamc via pipe, although that succeeds since spamd does receive the
> call, that is proven. (Everything is alright until that call is made,
> and then it reproducibly perishes every single time.) Spamd is 3.4.2
> even in working cases, but failures also occur with both 3.4.1 and 3.4.2
> client versions. I've spent 2 days trying to debug this on my own, but
> fail to comprehend the root cause of the problem, not even when diff'ing
> 'postconf -x' outputs. I thought it's either a different spamc version
> exiting in an unexpected manner or the pipe service handling exits from
> external processes differently, but changing spamc versions doesn't
> change the symptom, plus the code for pipe in Postfix doesn't seem to
> have changed in several years now. As hinted, reverting to a container
> with 3.3.0 immediately fixes the problem, but I'd like to be able to
> upgrade.
> 
> Could You please assist me figure out what's going wrong here?
> Documentation says panics are meant to be resolved by the developers, so
> this is a justified call for help - I'd be happy to supply any
> information necessary.
> 
> Thanks,
> Tam?s
> 

DANE issue with postfix 3.4.0-RC2

[A. Schulze]

Hello,

I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
Now I notice delivery problems to "gervers.com". DANE setup looks OK. 
https://dane.sys4.de/smtp/gervers.com

"posttls-finger gervers.com" also show
posttls-finger: Verified TLS connection established to 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

But a message to the domain is not delivered. Instead I found this logged by 
tlsproxy:

Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: 
re-using session with untrusted certificate, look for details earlier in the log
Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection 
established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

But I did not found anything special "earlier in the log" ...

Message was delivered immediately as I disabled smtp_tls_connection_reuse:
Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established 
to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

I could provide further information off-list.

Andreas

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 14:41 schrieb A. Schulze:
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"

corrected the subject, as DANE is not necessary related here.

Re: DANE issue with postfix 3.4.0-RC2

[Wietse Venema]

A. Schulze:
> Hello,
> 
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
> Now I notice delivery problems to "gervers.com". DANE setup looks OK. 
> https://dane.sys4.de/smtp/gervers.com
> 
> "posttls-finger gervers.com" also show
> posttls-finger: Verified TLS connection established to 
> sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> But a message to the domain is not delivered. Instead I found this logged by 
> tlsproxy:
> 
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: 
> re-using session with untrusted certificate, look for details earlier in the 
> log
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection 
> established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> But I did not found anything special "earlier in the log" ...

Surely the SMTP client logged SOMETHING?

Surely the tlsproxy daemon logged SOMETHING when it created the TLS connection?

> Message was delivered immediately as I disabled smtp_tls_connection_reuse:
> Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established 
> to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> I could provide further information off-list.
> 
> Andreas
> 

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 15:24 schrieb Wietse Venema:
> A. Schulze:
>> Hello,
>>
>> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
>> Now I notice delivery problems to "gervers.com". DANE setup looks OK. 
>> https://dane.sys4.de/smtp/gervers.com
>>
>> "posttls-finger gervers.com" also show
>> posttls-finger: Verified TLS connection established to 
>> sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>>
>> But a message to the domain is not delivered. Instead I found this logged by 
>> tlsproxy:
>>
>> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: 
>> re-using session with untrusted certificate, look for details earlier in the 
>> log
>> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection 
>> established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>>
>> But I did not found anything special "earlier in the log" ...
> 
> Surely the SMTP client logged SOMETHING?
> 
> Surely the tlsproxy daemon logged SOMETHING when it created the TLS 
> connection?

Hello Wietse,

thanks for asking :-) Yes, of corse, there are other loglines...
Here are the all message and connection related entries (I found):

Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: 
client=localhost[127.0.0.1]
Feb 17 10:27:54 mail postfix/cleanup[9442]: 442M9Q3L8Kzkn: message-id=<>
Feb 17 10:27:54 mail opendkim[19651]: 442M9Q3L8Kzkn: DKIM-Signature field added
Feb 17 10:27:54 mail postfix/qmgr[29788]: 442M9Q3L8Kzkn: from=<...>, size=1802, 
nrcpt=1 (queue active)
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification failed 
for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: Untrusted TLS connection 
established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:55 mail postfix/smtp[9452]: Untrusted TLS connection established 
to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:55 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: Server certificate not 
trusted
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: DISCONNECT [5.9.100.168]:25
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CONNECT to 
[2a01:4f8:162:32ac::2]:25
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CA certificate verification failed 
for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: Untrusted TLS connection 
established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:56 mail postfix/smtp[9452]: Untrusted TLS connection established 
to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:56 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: to=<***@gervers.com>, 
relay=sys1.mmini.de[2a01:4f8:162:32ac::2]:25, delay=1.6, 
delays=0.11/0.02/1.5/0, dsn=4.7.5, status=deferred (Server certificate not 
trusted)
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: DISCONNECT 
[2a01:4f8:162:32ac::2]:25

the same tlsproxy process handled 5 other connections before this one. All 
logged as 'Untrusted TLS connection established to'

Andreas

PATCH: non-Postfix processes in init mode

[Wietse Venema]

Wietse Venema:
> Tam?s G?rczei:
> > Hello List,
> > 
> > I'd like to ask whether You're aware of any change which might cause
> > breakage in my setup involving spamc with a completely unchanged
> > configuration in between - I'm getting the following error:
> > 
> > *"panic: master_reap: unknown pid"*
> 
> Is the Postfix master daemon running as PID 1? Historically this
> PID was reserved for the init daemon which becomes the parent of
> orphaned processes, i.e. processes that terminate without a parent
> waiting for them. Postfix does not create such processes, but if
> you run other programs inside the Postfix container then they
> might do that.
> 
> Options:
> 
> - Run Postfix as PID != 1.
> 
> - Don't co-locate Postfix with other software. That means pipe into
> socket instead of into a program in the same container.
> 
> - Make the master sloppier, and accept events from processes that
> it did not create.

As per the patch below.

--- src/master/master_spawn.c-  2014-12-06 20:35:33.0 -0500
+++ src/master/master_spawn.c   2019-02-17 09:38:52.0 -0500
@@ -301,8 +301,11 @@
if (msg_verbose)
msg_info("master_reap_child: pid %d", pid);
if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
- (void *) &pid, sizeof(pid))) == 0)
+   (void *) &pid, sizeof(pid))) == 0) {
+   if (init_mode)
+   continue;   /* non-Postfix process */
msg_panic("master_reap: unknown pid: %d", pid);
+   }
serv = proc->serv;
 
 #define MASTER_KILL_SIGNAL SIGTERM

Re: PATCH: non-Postfix processes in init mode

[Tamás Gérczei]

Thanks Wietse, I'll definitely try this patch -  but this code didn't
change in quite a bit of time. Can this behaviour I'm seeing somehow
relate to a change introduced between 3.3.0 and 3.3.2 ? I have zero
problems with the exact same setup and configuration on 3.3.0. Anyway
I'm invoking postfix-script in order to start master:

/ # ps auxwww -o pid,ppid,user,time,comm
PID   PPID  USER TIME  COMMAND
    1 0 root  0:00 postfix-script
    9 1 root  0:01 rsyslogd
   92 1 root  0:00 master
   94    92 postfix   0:00 qmgr
   96    92 postfix   0:00 tlsmgr
  235    92 postfix   0:00 pickup
  275 0 root  0:00 sh
  283    92 postfix   0:00 smtpd
  284    92 postfix   0:00 anvil
  286   275 root  0:00 ps

T.

On 2019. 02. 17. 15:42, Wietse Venema wrote:
> Wietse Venema:
>> Tam?s G?rczei:
>>> Hello List,
>>>
>>> I'd like to ask whether You're aware of any change which might cause
>>> breakage in my setup involving spamc with a completely unchanged
>>> configuration in between - I'm getting the following error:
>>>
>>> *"panic: master_reap: unknown pid"*
>> Is the Postfix master daemon running as PID 1? Historically this
>> PID was reserved for the init daemon which becomes the parent of
>> orphaned processes, i.e. processes that terminate without a parent
>> waiting for them. Postfix does not create such processes, but if
>> you run other programs inside the Postfix container then they
>> might do that.
>>
>> Options:
>>
>> - Run Postfix as PID != 1.
>>
>> - Don't co-locate Postfix with other software. That means pipe into
>> socket instead of into a program in the same container.
>>
>> - Make the master sloppier, and accept events from processes that
>> it did not create.
> As per the patch below.
>
> --- src/master/master_spawn.c-2014-12-06 20:35:33.0 -0500
> +++ src/master/master_spawn.c 2019-02-17 09:38:52.0 -0500
> @@ -301,8 +301,11 @@
>   if (msg_verbose)
>   msg_info("master_reap_child: pid %d", pid);
>   if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
> -   (void *) &pid, sizeof(pid))) == 0)
> + (void *) &pid, sizeof(pid))) == 0) {
> + if (init_mode)
> + continue;   /* non-Postfix process */
>   msg_panic("master_reap: unknown pid: %d", pid);
> + }
>   serv = proc->serv;
>  
>  #define MASTER_KILL_SIGNAL   SIGTERM

Re: DELIVERY issue with postfix 3.4.0-RC2

[Wietse Venema]

A. Schulze:
> 
> 
> Am 17.02.19 um 15:24 schrieb Wietse Venema:
> > A. Schulze:
> >> Hello,
> >>
> >> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
> >> Now I notice delivery problems to "gervers.com". DANE setup looks OK. 
> >> https://dane.sys4.de/smtp/gervers.com
> >>
> >> "posttls-finger gervers.com" also show
> >> posttls-finger: Verified TLS connection established to 
> >> sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
> >> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> >>
> >> But a message to the domain is not delivered. Instead I found this logged 
> >> by tlsproxy:
> >>
> >> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: 
> >> sys1.mmini.de[5.9.100.168]:25: re-using session with untrusted 
> >> certificate, look for details earlier in the log
> >> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection 
> >> established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
> >> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> >>
> >> But I did not found anything special "earlier in the log" ...
> > 
> > Surely the SMTP client logged SOMETHING?
> > 
> > Surely the tlsproxy daemon logged SOMETHING when it created the TLS 
> > connection?
> 
> Hello Wietse,
> 
> thanks for asking :-) Yes, of corse, there are other loglines...
> Here are the all message and connection related entries (I found):
> 
> Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: 
> client=localhost[127.0.0.1]
> Feb 17 10:27:54 mail postfix/cleanup[9442]: 442M9Q3L8Kzkn: message-id=<>
> Feb 17 10:27:54 mail opendkim[19651]: 442M9Q3L8Kzkn: DKIM-Signature field 
> added
> Feb 17 10:27:54 mail postfix/qmgr[29788]: 442M9Q3L8Kzkn: from=<...>, 
> size=1802, nrcpt=1 (queue active)
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification 
> failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: Untrusted TLS connection 
> established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:55 mail postfix/smtp[9452]: Untrusted TLS connection established 
> to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:55 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: Server certificate 
> not trusted
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: DISCONNECT [5.9.100.168]:25
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CONNECT to 
> [2a01:4f8:162:32ac::2]:25
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CA certificate verification 
> failed for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: Untrusted TLS connection 
> established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:56 mail postfix/smtp[9452]: Untrusted TLS connection established 
> to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:56 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: to=<***@gervers.com>, 
> relay=sys1.mmini.de[2a01:4f8:162:32ac::2]:25, delay=1.6, 
> delays=0.11/0.02/1.5/0, dsn=4.7.5, status=deferred (Server certificate not 
> trusted)
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: DISCONNECT 
> [2a01:4f8:162:32ac::2]:25
> 
> the same tlsproxy process handled 5 other connections before this one. All 
> logged as 'Untrusted TLS connection established to'

How do those 'other' connections differ from what is shown above?

What I see is an SMTP client deferring delivery with a NEW TLS
connection. That is different from your earlier report about a
REUSED connection.

Can you confirm that the SMTP client will not deliver to this
destination with NEW and REUSED tlsproxy connections?

The error message suggests a problem in the certificate trust chain,
like an unknown root certificate. What is the output from:

postconf -F smtp/unix/chroot tlsproxy/unix/chroot

Wietse

Re: PATCH: non-Postfix processes in init mode

[A. Schulze]

Am 17.02.19 um 16:01 schrieb Tamás Gérczei:
> Anyway I'm invoking postfix-script in order to start master:

I wonder why you don't use "postfix start-fg" available since postfix-3.3.1
(http://www.postfix.org/announcements/postfix-3.3.1.html)

Andreas

Re: PATCH: non-Postfix processes in init mode

[Tamás Gérczei]

Hm.. Thanks to You both, I'll go take a look at this.

On 2019. 02. 17. 16:14, Wietse Venema wrote:
> Tam?s G?rczei:
>> Thanks Wietse, I'll definitely try this patch -? but this code didn't
>> change in quite a bit of time.
> If in doubt, look RTFM the Postfix 3.3.1 announcement.
>
>  *  Postfix did not support running as a PID=1 process, which
> complicated Postfix management in containers. The "postfix
> start-fg" command will now run the Postfix master daemon as a
> PID=1 process if possible. Thanks to inputs from Andreas Schulze,
> Eray Aslan, and Viktor Dukhovni.
>
>   Wietse

Re: PATCH: non-Postfix processes in init mode

[Wietse Venema]

Tam?s G?rczei:
> Thanks Wietse, I'll definitely try this patch -? but this code didn't
> change in quite a bit of time.

If in doubt, look RTFM the Postfix 3.3.1 announcement.

 *  Postfix did not support running as a PID=1 process, which
complicated Postfix management in containers. The "postfix
start-fg" command will now run the Postfix master daemon as a
PID=1 process if possible. Thanks to inputs from Andreas Schulze,
Eray Aslan, and Viktor Dukhovni.

Wietse

Re: Support for "Linux 5"

[Wietse Venema]

Scott Kitterman:
> I understand that the next Linux release will have a major version of 5.  
> This 
> doesn't portend any technical changes.  As has happened the last few times 
> linux 5 should be no different than 4 which was no different than 3.
> 
> It looks to me like the postfix 3.4 makedefs still have:
> 
>  Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR
> 
> Is it too late to add 5?

What distribution runs Linux 5 kernels? I would like to do a smoke
test for due diligence (does it build and run).

Wietse

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 16:10 schrieb Wietse Venema:

> How do those 'other' connections differ from what is shown above?
I don't see differences. This tlsproxy process handled a connection to gmail, 
outlook.com and some other destinations. All unverified because I did not 
configure the matching root certificates.
Interesting: it also handled later an other connection to an other destination 
that *could* be verified using DANE (verified connection established to ...)
 
> What I see is an SMTP client deferring delivery with a NEW TLS
> connection. That is different from your earlier report about a
> REUSED connection.
> 
> Can you confirm that the SMTP client will not deliver to this
> destination with NEW and REUSED tlsproxy connections?
cannot check that without bothering the receiver with annoying test messages.
Will ask for permission...

> The error message suggests a problem in the certificate trust chain,
> like an unknown root certificate.

that's the point I started with subject "DANE issue..."
The destination don't need any certificate chains. The destination can be 
validated using DANE.

> What is the output from:
> 
> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
smtp/unix/chroot = y
tlsproxy/unix/chroot = y

Andreas

Re: Support for "Linux 5"

[Scott Kitterman]

Debian doesn't have it in the distro yet, but I can ask the reporter to verify 
it works.  

There's no technical driver behind the version bump, so it might be best to 
consider such checks obsolete for Linux.

If there are new features introduced that need to be supported by specific 
changes in makedefs, they are going to have to be tied to a specific version 
(like epoll in Linux 2).  I don't think the major version will be a useful 
distinction.

Scott K

On February 17, 2019 3:41:47 PM UTC, Wietse Venema  wrote:
>Scott Kitterman:
>> I understand that the next Linux release will have a major version of
>5.  This 
>> doesn't portend any technical changes.  As has happened the last few
>times 
>> linux 5 should be no different than 4 which was no different than 3.
>> 
>> It looks to me like the postfix 3.4 makedefs still have:
>> 
>>  Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR
>> 
>> Is it too late to add 5?
>
>What distribution runs Linux 5 kernels? I would like to do a smoke
>test for due diligence (does it build and run).
>
>   Wietse

Re: DELIVERY issue with postfix 3.4.0-RC2

[Wietse Venema]

Wietse Venema:
> How do those 'other' connections differ from what is shown above?

A. Schulze:
> I don't see differences. This tlsproxy process handled a connection
> to gmail, outlook.com and some other destinations. All unverified
> because I did not configure the matching root certificates.

Conclusion: Postfix works as expected? I see no unexplained failures.

> Interesting: it also handled later an other connection to an other
> destination that *could* be verified using DANE (verified connection
> established to ...)

That is expected. DANE aims to lessen the dependency on PKI.

Wietse

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 18:23 schrieb Wietse Venema:
> Conclusion: Postfix works as expected?

hard to say...

delivery deferred if smtp_tls_connection_reuse = yes
delivery works if smtp_tls_connection_reuse = no

http://www.postfix.org/TLS_README.html#client_tls_reuse say "As of Postfix 3.4, 
TLS connection reuse is disabled by default."
As usual, you select good defaults :-)

I'll make some further test next week and report my findings...

Andreas

Re: DELIVERY issue with postfix 3.4.0-RC2

[Wietse Venema]

A. Schulze:
> 
> 
> Am 17.02.19 um 18:23 schrieb Wietse Venema:
> > Conclusion: Postfix works as expected?
> 
> hard to say...
> 
> delivery deferred if smtp_tls_connection_reuse = yes
> delivery works if smtp_tls_connection_reuse = no

Is the problem that certificate verification failure handling is
different depending on the smtp_tls_connection_reuse setting?

Are there other problems?

With smtp_tls_connection_reuse=yes, does certificate verification
failure handling differ for connection that is logged as "new" or
as "reused"?

Wietse

Re: smtp_tls_security_level = dane but have encrypt as fallback

[Andrey Repin]

Greetings, Viktor Dukhovni!

>>
>> But in cases where remote sites do not have published key material, the
>> fallback is may with dane, which is a step back in terms of security and
>> not wanted.
>> 
>> How can we specify:
>> 
>> 1, Always use at least encrypt
>> 2, When TLSA-records are found and valid, use only this to encrypt
>> 3, When no TLSA-records are found or the ones found can not be used, fall
>>back to encrypt, if not possible, fail.

> That requires new code.  Sorry about that.  The issue is in part
> whether a point-fix would be appropriate with a fallback level
> when DANE TLSA records are not found, or whether a more general
> mechanism should be implemented that can specify more complex
> policy:

A more general solution would be preferred, and will likely be more
future-proof.

>* dane or else encrypt or else fail
>* dane or else verify [match=...] or else fail
>* dane or warn and delivery anyway 
>* ...

> In Postfix, when we do something, we tend to skip half measures
> and do it "right", i.e. in a general way.  So the question is
> whether "DANE or else encrypt" is the right design or not.

Not necessarily. Practice of allowed downgrades had shown a bad track record
numerous times.

> One can certainly imagine specifying a "minimum" security
> level, and then fallback would never use anything weaker.

*_tls_security_level is working very close to desirable level already.
If it could be changed into a list, the configuration logic would be rather 
simple.
If only one value is set, use that or stronger level. Which one to start from
could be a compilation setting.
If a list of values is set, try only them in order from strongest to weakest,
fail if nothing match.

F.e. the default compiled-in order list could be "dane encrypt none",
abbreviated as "may" in configuration. When some "new" mechanism is developed
into postfix, the list remains unchanged for initial iterations, but for those
interested it could be enabled with "smtp_tls_security_level=new,may" or may
be "smtp_tls_security_level=new,encrypt".

One last issue is if you for some reason want to specify only one level and
never upgrade... but I'm not sure it worth the hassle, with the exception of
"none".


-- 
With best regards,
Andrey Repin
Sunday, February 17, 2019 21:15:16

Sorry for my terrible english...

Re: 3.3.0 -> 3.3.2 and sasl error

[Andrey Repin]

Greetings, Viktor Dukhovni!

> On Sat, Feb 16, 2019 at 11:46:12PM +0300, Andrey Repin wrote:

>> > submission inet n   -   n   -   -   smtpd
>> >   -o syslog_name=postfix/submission
>> >   -o smtpd_tls_security_level=encrypt
>> 
>> This is NOT right.
>> submission (port 587/tcp) is a plan connection. Unencrypted.
>> You should use default "may" here and leave "encrypt" for submissions (port
>> 465/tcp).

> The OP should ignore this erroneous advice.  The configuration is
> both correct and best current practice as written.

You're right, my apology for confusion.


-- 
With best regards,
Andrey Repin
Sunday, February 17, 2019 21:32:48

Sorry for my terrible english...

Re: DANE issue with postfix 3.4.0-RC2

[Viktor Dukhovni]

On Sun, Feb 17, 2019 at 02:41:27PM +0100, A. Schulze wrote:

> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse" Now
> I notice delivery problems to "gervers.com".

The DNS configuration for this domain is:

gervers.com. IN MX 10 sys1.mmini.de. ; NoError AD=1
sys1.mmini.de. IN A 5.9.100.168 ; NoError AD=1
sys1.mmini.de. IN  2a01:4f8:162:32ac::2 ; NoError AD=1
_25._tcp.sys1.mmini.de. IN TLSA 3 1 1 
69f3288e4797be2044e3cb6d0251e0fa28d986abcb4e2837863094d85d516161 ; NoError AD=1
_25._tcp.sys1.mmini.de. IN TLSA 2 1 1 
60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 ; NoError AD=1

But the live Let's Encrypt certificate chain does not match the
(presumably stale) "3 1 1" TLSA record, so it remains for the "2 1
1" record to match the issuing CA, and that's why Postfix is doing
"CA verification":

  sys1.mmini.de[5.9.100.168]: pass: TLSA match: depth = 1, name = sys1.mmini.de
TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384,P256
name = raketenstaffel.de
name = sys1.mmini.de
name = thegreendorf.de
name = www.raketenstaffel.de
name = www.thegreendorf.de
depth = 0
  Issuer CommonName = Let's Encrypt Authority X3
  Issuer Organization = Let's Encrypt
  notBefore = 2019-01-20T00:30:26Z
  notAfter = 2019-04-20T00:30:26Z
  Subject CommonName = raketenstaffel.de
  pkey sha256 [nomatch] <- 3 1 1 
d090d27c5a4b92dfd3b6b6b548e88aee92c8ce739eba6b529780fa923d3ffbcc
depth = 1
  Issuer CommonName = DST Root CA X3
  Issuer Organization = Digital Signature Trust Co.
  notBefore = 2016-03-17T16:40:46Z
  notAfter = 2021-03-17T16:40:46Z
  Subject CommonName = Let's Encrypt Authority X3
  Subject Organization = Let's Encrypt
  pkey sha256 [matched] <- 2 1 1 
60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

which, as you noted, generally works.  However:

> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25:
>   re-using session with untrusted certificate, look for details earlier in
>   the log
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection
>   established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher
>   ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Here, we see re-use of a cached TLS session to the destination that
failed to verify during the initial handshake.  This is a combination
of both connection re-use (via tlsproxy(8)) and TLS session resumption
in tlsproxy itself.

> But I did not found anything special "earlier in the log" ...
> 
> Message was delivered immediately as I disabled smtp_tls_connection_reuse:
> Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established 
> to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

If you performed a "reload" to get that to take effect, that would
also have flushed the TLS session cache.  And perhaps disabling
connection re-use is a distraction.  It may well have been sufficient
to just "postfix reload".

On Sun, Feb 17, 2019 at 03:38:19PM +0100, A. Schulze wrote:

> Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: 
> client=localhost[127.0.0.1]
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification
> failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected

This is more interesting.  What OpenSSL version is your Postfix
linked with?  The issuer certificate was *explicitly* rejected.  At
first glance, that should only happen when not using DANE, and your
trust store has an issuer certificate for the chain, that is augmented
with trust settings (purpose OIDs) that don't include fitness for
use by TLS servers.  That's rather uncommon.

Please post the outputs of "postconf -nf" and "postconf -Mf", and
information about the OpenSSL version, checking "ldd" to make sure
you're reporting the version of the correct library.

> the same tlsproxy process handled 5 other connections before this one. All
> logged as 'Untrusted TLS connection established to'

If you re-enable use of the proxy, does the problem come back?

On Sun, Feb 17, 2019 at 04:45:11PM +0100, A. Schulze wrote:

> > Can you confirm that the SMTP client will not deliver to this
> > destination with NEW and REUSED tlsproxy connections?
> cannot check that without bothering the receiver with annoying test messages.

> Will ask for permission...

You don't need to send messages that reach the recipient.  You can
send "delivery probes" via:

sendmail -f your-address -bv recipient-address

These drop the connection after "RCPT TO", without delivering a message.

> that's the point I started with subject "DANE issue..."
> The destination don't need any certificate chains. The destination can be 
> validated using DANE.

We might temporarily need to raise the TLS loglevel to 2 in the
proxy just before sending a delivery probe.  It should the

Re: DANE issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 21:24 schrieb Viktor Dukhovni:

Hello Viktor,

> If you performed a "reload" to get that to take effect, that would
> also have flushed the TLS session cache.  And perhaps disabling
> connection re-use is a distraction.  It may well have been sufficient
> to just "postfix reload".
no, also "postfix stop; postfix start; postfix flush" (it's a low volume system 
with only this message in the deferred queue) did not deliver the message.
but "smtp_tls_connection_reuse = no" did.

> This is more interesting.  What OpenSSL version is your Postfix
> linked with? 
a self-compiled openssl-1.1.1a (using a shlib_variant like you show me some 
years ago)

> Please post the outputs of "postconf -nf" and "postconf -Mf", and
> information about the OpenSSL version, checking "ldd" to make sure
> you're reporting the version of the correct library.
https://andreasschulze.de/tmp/postconf_nf.txt
https://andreasschulze.de/tmp/postconf_Mf.txt

https://andreasschulze.de/tmp/ldd_smtp.txt

> If you re-enable use of the proxy, does the problem come back?
yes

> You don't need to send messages that reach the recipient.  You can
> send "delivery probes" via:
> 
> sendmail -f your-address -bv recipient-address
> 
> These drop the connection after "RCPT TO", without delivering a message.
ok, so I start silent testing ...

https://andreasschulze.de/tmp/reuse_on.txt
https://andreasschulze.de/tmp/reuse_off.txt

> We might temporarily need to raise the TLS loglevel to 2 in the
> proxy just before sending a delivery probe.  It should then be
> possible to see more of the TLS handshake details.
tests above run with "smtp_tls_loglevel = 2"

>>> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
>> smtp/unix/chroot = y
>> tlsproxy/unix/chroot = y
> 
> You should make sure your DNS is correctly configured in the chroot
> jail.  Are any of the upstream resolvers perhaps not configured to
> do DNSSEC?
only one DNS resolver (@::1) is also configured inside the chroot jail.

Andreas

Re: DANE issue with postfix 3.4.0-RC2

[Wietse Venema]

A. Schulze:
> https://andreasschulze.de/tmp/reuse_on.txt
> https://andreasschulze.de/tmp/reuse_off.txt

These deliver to different server IP addresses, therefore the 
results may differ.

Wietse

Re: DANE issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 22:40 schrieb Wietse Venema:
> A. Schulze:
>> https://andreasschulze.de/tmp/reuse_on.txt
>> https://andreasschulze.de/tmp/reuse_off.txt
> 
> These deliver to different server IP addresses, therefore the 
> results may differ.

the destination MX has IPv4 and IPv6 working. Depends on what postfix selected 
first.

Andreas

Re: DANE issue with postfix 3.4.0-RC2

[Wietse Venema]

Wietse Venema:
> A. Schulze:
> > https://andreasschulze.de/tmp/reuse_on.txt
> > https://andreasschulze.de/tmp/reuse_off.txt
> 
> These deliver to different server IP addresses, therefore the 
> results may differ.

One is:

Feb 17 22:11:53 mail postfix/smtp[23428]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 chain is trust-anchor signed
Feb 17 22:11:53 mail postfix/smtp[23428]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 verify=1 
subject=/CN=raketenstaffel.de

The other is:

Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: 
depth=1 matched trust anchor public-key sha256 
digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: 
depth=0 chain is trust-anchor signed
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: 
depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: 
depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: 
depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: 
depth=0 verify=1 subject=/CN=raketenstaffel.de

I would call that different.

Wietse

Re: Support for "Linux 5"

[Scott Kitterman]

It (3.3.2, since that's what's in Debian) builds and runs with the attached 
patches using the Linux 5.0 kernel.

Scott K

On Sunday, February 17, 2019 03:51:45 PM Scott Kitterman wrote:
> Debian doesn't have it in the distro yet, but I can ask the reporter to
> verify it works.
> 
> There's no technical driver behind the version bump, so it might be best to
> consider such checks obsolete for Linux.
> 
> If there are new features introduced that need to be supported by specific
> changes in makedefs, they are going to have to be tied to a specific
> version (like epoll in Linux 2).  I don't think the major version will be a
> useful distinction.
> 
> Scott K
> 
> On February 17, 2019 3:41:47 PM UTC, Wietse Venema  
wrote:
> >Scott Kitterman:
> >> I understand that the next Linux release will have a major version of
> >
> >5.  This
> >
> >> doesn't portend any technical changes.  As has happened the last few
> >
> >times
> >
> >> linux 5 should be no different than 4 which was no different than 3.
> >> 
> >> It looks to me like the postfix 3.4 makedefs still have:
> >>  Linux.[34].*) SYSTYPE=LINUX$RELEASE_MAJOR
> >> 
> >> Is it too late to add 5?
> >
> >What distribution runs Linux 5 kernels? I would like to do a smoke
> >test for due diligence (does it build and run).
> >
> > Wietse
diff --git a/src/util/sys_defs.h b/src/util/sys_defs.h
index f4f53300..6a5da4fe 100644
--- a/src/util/sys_defs.h
+++ b/src/util/sys_defs.h
@@ -748,7 +748,7 @@ extern int initgroups(const char *, int);
  /*
   * LINUX.
   */
-#if defined(LINUX2) || defined(LINUX3) || defined(LINUX4)
+#if defined(LINUX2) || defined(LINUX3) || defined(LINUX4) || defined(LINUX5)
 #define SUPPORTED
 #define UINT32_TYPE	unsigned int
 #define UINT16_TYPE	unsigned short
diff --git a/makedefs b/makedefs
index 227fdd54..bd3ab32e 100644
--- a/makedefs
+++ b/makedefs
@@ -546,7 +546,7 @@ EOF
 		: ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"}
 		: ${PLUGIN_LD="${CC-gcc} -shared"}
 		;;
-  Linux.[34].*)	SYSTYPE=LINUX$RELEASE_MAJOR
+  Linux.[3456789].*)	SYSTYPE=LINUX3
 		case "$CCARGS" in
 		 *-DNO_DB*) ;;
 		 *-DHAS_DB*) ;;

Re: Support for "Linux 5"

[Peter]

On 18/02/19 04:41, Wietse Venema wrote:

What distribution runs Linux 5 kernels? I would like to do a smoke
test for due diligence (does it build and run).


Fedora Rawhide is on 5.0.0


Peter

Re: DANE issue with postfix 3.4.0-RC2

[Viktor Dukhovni]

On Sun, Feb 17, 2019 at 10:31:05PM +0100, A. Schulze wrote:

> ok, so I start silent testing ...
> 
> https://andreasschulze.de/tmp/reuse_on.txt
> https://andreasschulze.de/tmp/reuse_off.txt

Thanks, these get us much closer to the source of the problem.
Something about the way the way that chain verification is happening
in the proxy appears to cause the chain to be verified differently.
I'll try to investigate from here.  There's nothing at first blush
with the "postconf -nf" or "postconf -Mf" that would suggest any
relevant issues.

No proxy:

  DANE-use evidenced by use of normally disabled SNI, and
  "trust-anchor signed" status, verification succeeds with a TA
  public key match at depth 1:

Feb 17 22:11:53 mail postfix/smtp[23428]:
setting up TLS connection to sys1.mmini.de[2a01:4f8:162:32ac::2]:25
...
Feb 17 22:11:53 mail postfix/smtp[23428]:
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: SNI hostname: sys1.mmini.de
...
Feb 17 22:11:53 mail postfix/smtp[23428]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 matched trust anchor public-key 
sha256 
digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
Feb 17 22:11:53 mail postfix/smtp[23428]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 chain is trust-anchor signed
Feb 17 22:11:53 mail postfix/smtp[23428]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 verify=1 
subject=/CN=raketenstaffel.de
Feb 17 22:11:53 mail postfix/smtp[23428]: SSL_connect:SSLv3/TLS read server 
certificate
...
Feb 17 22:11:53 mail postfix/tlsmgr[23429]: write smtp TLS cache entry

smtp&gervers.com&sys1.mmini.de&2a01:4f8:162:32ac::2&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1:
time=1550437913 [data 1774 bytes]
Feb 17 22:11:53 mail postfix/smtp[23428]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25:
subject_CN=sys1.mmini.de, issuer_CN=Let's Encrypt Authority X3,
fingerprint=20:F4:59:CA:8C:7C:D7:21:21:43:16:54:F0:F1:24:35:85:75:00:D7,

pkey_fingerprint=86:53:E8:0E:7A:48:A1:C6:DC:1C:F6:81:16:A9:04:4B:80:EE:F4:2C
Feb 17 22:11:53 mail postfix/smtp[23428]: Verified TLS connection 
established to
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

With proxy:

Feb 17 22:08:45 mail postfix/tlsproxy[23261]: CONNECT to 
[2a01:4f8:162:32ac::2]:25
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: setting up TLS connection to 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: looking for session

smtp&gervers.com&sys1.mmini.de&2a01:4f8:162:32ac::2&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1
 in smtp cache

  Same session lookup key which hashes the TLS policy settings
  evidences the same TLS settings in both cases.

Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: SNI hostname: sys1.mmini.de

  Same IPv6 address and SNI name as without the proxy.

Feb 17 22:08:45 mail postfix/tlsproxy[23261]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 matched trust anchor public-key 
sha256 
digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 chain is trust-anchor signed

  So far, so good, the chain should now be verified.

Feb 17 22:08:45 mail postfix/tlsproxy[23261]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 verify=0 subject=/C=US/O=Let's 
Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 verify=0 subject=/C=US/O=Let's 
Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 verify=0 subject=/C=US/O=Let's 
Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 verify=1 
subject=/CN=raketenstaffel.de

  But suddenly, we're doing some sort of additional non-DANE
  certificate checks at depth 1.  Not yet clear why.  These fail.

Feb 17 22:08:45 mail postfix/tlsproxy[23261]: SSL_connect:SSLv3/TLS read 
server certificate
...
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: save session

smtp&gervers.com&sys1.mmini.de&2a01:4f8:162:32ac::2&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1
to smtp cache
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: CA certificate verification 
failed for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
...
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: Untrusted TLS connection 
established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

  Peer verification failed in the proxy.

F

Expires Header(RFC-5536) implementation

[azusa_tarola]

Hi,
I'm trying to implement "Expires" header (Defined by RFC-5536).
I want Postfix bounce the expired mails.
At first, I use content filter to check Expires date is valid.

However, content filtering can be done only one time when into the mail queue.
(It can't be done when Postfix resend deferred emails)

Is there someone who implement RFC-5536 to Postfix or have any solutions?

Thanks.

Azusa Taroura