Postings by Andreas Schulze

unknown tls_ssl_options value "tlsext_padding"


postfix-3.4.4 linked with openssl-1.1.1b

$ postconf tls_ssl_options
tls_ssl_options = no_compression, tlsext_padding

produce such log:
Mar 30 21:04:12 danube postfix/smtpd[9075]: warning: unknown tls_ssl_options value "tlsext_padding" in "no_compression, tlsext_padding"

while it does make no sense, I placed all options [1] and still get only errors regarding tlsext_padding:
Mar 30 21:10:48 danube postfix/smtpd[9222]: warning: unknown tls_ssl_options value "TLSEXT_PADDING" in "ENABLE_MIDDLEBOX_COMPAT, LEGACY_SERVER_CONNECT, NO_TICKET, NO_RENEGOTIATION, NO_SESSION_RESUMPTION_ON_RENEGO

documentation of mnaillog_file


<a href="" title=""></a> say
"A non-empty value selects logging to syslogd"

I think it should say
"A empty value selects logging to syslogd"


Uhm... next bug or my faulty configuration?


updated from 3.4.1 to 3.4.3 and at the same time dovecot-2.2 to dovecot-2.3 ( + pigeonhole)
I assume the changes behavior is dovecot/pigeonhole now using the advertised "CHUNKING" extension.

Now an echo service (dovecot-2.3-pigeonhole) don't send messages anymore.
Reason: "Data command rejected: Multi-recipient bounce" while there is clearly only one recipient.

the relevant debug logs:

Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: >[]: 220 ESMTP
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: < signing-milter

DANE issue with postfix 3.4.0-RC2


I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
Now I notice delivery problems to "". DANE setup looks OK. <a href="" title=""></a>

"posttls-finger" also show
posttls-finger: Verified TLS connection established to[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.

postfix & TLS1.3 problems


today I noticed a significant amount of TLS failures in my postfix log.

Oct 11 17:43:35 mta postfix/smtpd[23847]: SSL_accept error from
client.example[]:34152: -1

I traced some sessions and found the problematic client is announcing
the special cipher "TLS_FALLBACK_SCSV"
in a TLSv1.2 ClientHello message.

TLS1.3 only


postfix-3.3.1 + openssl-1.1.1pre8

For fun I tried to disable all TLS protocol versions other then TLS1.3
submission.local inet n - - - - smtpd
-o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1,!TLSv1.2

but I'm still able to connect using TLS1.2

$ openssl version
OpenSSL 1.1.1-pre8 (beta) 20 Jun 2018

$ openssl s_client -connect submission.local:587 -starttls smtp -tls1_2
Start Time: 1531425453
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
Shouldn't that fail like this one?

$ openssl

SMTP session caching


I like to ask about a documented limitation (<a href="" title=""></a>)

"For this reason, the Postfix smtp(8) client always closes the connection after completing an attempt to deliver mail over TLS."

I'm concerned becaus I see increasing traffic delivered via TLS.
It is true that now /every single message/ require TCP connect, TLS Handshake, message transmission and TCP close?
So SMTP Session caching don't happen anymore?

Given a sending server handle 3000 messages per hour to a specific destination that use DANE.
Virtually every 1-2 seconds th

smtp-sink on ipv4 and ipv6?


postfix usually listen on both protocols if contain "inet_protocols = all" and myhostname is setup properly.
May I expect that also for smtp-sink?

$ host has address has IPv6 address 2001:db8::25

$ smtp-sink &

now I've only a listener on 2001:db8::25 but not on, but I would like smtp-sink listen on ipv4 AND ipv6.
is that possible?


address verification and tarpitting


we're facing the following problem:
postfix is configured to verify recipient addresses. The backend servers are mostly Exchange in various versions.
Many of them use tarpitting. We guess that are default values.
The address probe sent by postfix receive a result after 5 seconds delay. reason: tarpitting.
Meanwhile postfix accept the message and we generate bounces later :-/
The next message to a - now known undeliverable - address is directly rejected by postfix.

verification levels and Milter


postfix smtp server may classify incoming TLS sessions as anonymous, untrusted and trusted.
(<a href="" title=""></a>)

Is it possible to access this information from within a milter?

I did not found such funktionallity on <a href="" title=""></a>
so I expect "not documented -> not implemented" but I would like to be sure. Maybe I've overseen it...


connection caching - limitations


that's my (legacy) setup:

a script generate 10k message files, same sender, different receiver.
they are injected using "sendmail -t -f sender < messagefile" in the local MTA
The MTA is configured to forward all messages to a central MSA.

This MSA require authentication and STARTTLS
All works fine, except speed.

The MTA uses one SMTP-Session per message.

cosmetics: authentication success not logged


we implemented a submission server with SASL authentication.

Howto avoid 8BITMIME


again I struggled about the 8BITMIME SMTP-Extension. The RFC - initial
version published in 1993 -
is not as widely adopted as one may expect. In fact even largest
mailprovider do not announce 8BITMIME.
That forces any RFC conforming MTA to reject or convert the message
into valid 7-bit MIME
( <a href="" title=""></a> )

The problem occur in a usual combination of common software packages:
postfix and OpenDKIM.
OpenDKIM as signer is implemented as milter.

send to ESP with broken STARTTLS


I hit an MX-Server with weak DH:

# SLES-Host
# posttls-finger
posttls-finger: Connected to[]:25
posttls-finger: < 220 kath-5.0.3 ESMTP Ready
posttls-finger: > EHLO
posttls-finger: < says Hello []
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250 OK
posttls-finger: > STARTTLS
posttls-finger: < 220 Ready to start TLS
posttls-finger: SSL_connect error to

documentation error


the descriptive text for lmtp_address_verify_target
(<a href="" title=""></a>)
looks simply wrong...


Re: RC4 in live email servers?

Viktor Dukhovni:


my dataset doesn't completely fit but maybe it help.

I have a submission server used by ~1500 different clients.

smtpd: no logging on "message to big"


usually I expect any smtp connection to be logged. That way I may find
any sender or recipient addresses
a user may know if complaining about missing messages. This is not
true if a message is rejected because it's to big.

SMTP-Reply is "552 5.3.4 Error: message file too big".

OT: is down


for whatever reasons Proofpoint (the current owner of sendmail)
decided to shut down the website.
Unfortunately the API documentation is unavailable now, too.

An Proofpoint employee suggested to download the public available
source distribution.
( <a href="" title=""></a> )
It contain the documentation in libmilter/docs/ ...


logjam & SMTP


the crypto weakness of the month is named "logjam".
If you could connect to <a href="" title=""></a> your SSL-Client /
Browser support weak crypto.
What does that mean for postfix?

We setup a postfix smtp server with

smtpd_tls_dh1024_param_file = /path/to/dh_512.pem
smtpd_tls_exclude_ciphers = ECDH
smtpd_tls_ciphers = high
smtpd_tls_protocols = TLSv1.2

and connect to that server

posttls-finger -g high -c -p TLSv1.2 $testserver

There is no warning about the weak DH key used by the server nor is
the connection rejected.

Next we replaced the RSA Key + cert

Re: wrong transport after error ?

A. Schulze:

OK, found *my* fault, sorry for the noise.


wrong transport after error ?


I have a setup where all messages for a domain is forwarded to a
remote SMTP server.
Except one address is delivered by lmtp.

domain smtp:remote
user@domain lmtp:remote

that worked till remote died yesterday.
After remote came up again, message to user@domain where delivered by smtp.

The only unusual on the mta are recipient_bcc_maps copy all messages
to a second backup place.


Any hints where I should start searching (my?) misconfiguration?


trusted vs. verified TLS connection


while checking TLS to a destination domain I noticed a difference.

nice reject


a smtpd_recipient_restrictions for a submission service usually end
with explicit "reject".

warnings about symlinks in /etc/postfix/


I use to have symlinks in /etc/postfix to include files from other
sources while building
the local configuration.

postconf question

Hi all,

while reading the COMPATIBILITY_README I asked me

is '-e' a default action to edit did I missed an update?

"postconf mumble" display the value
"postconf mumble=foo" set the variable and is exactly the same as
"postconf -e mumble=foo"

is that right?


postfix-2.12 BC-warnings: confusing linenumbers

Hello Wietse,

I just installed 2.12-20140911 and got multiple BC warnings.
The linenumbers are confusing...

$ head -n 3 /etc/postfix/
relay unix - - - - - smtp
-o smtp_fallback_relay=
# line with comment
flush unix n - y 1000?



I'm looking for an alternative solution for smtp_fallback_relay that
I'm currently forced to use.

Mostly I hit servers also running postscreen or postgrey.
postfix could deliver direct if it would get a second chance.
But smtp_fallback_relay=... catch all deliveries after first fail.
Yes, that's the job.

suggestion / log improvent


the last day I had to search messages in our "poor man's second
chance" storage.
( an always_bcc solution ). *finding* messages was painful.
using my logging I could follow any message by its queueid.

CCERT autorization


Abstract problem:
allow a external third party to relay messages with
one fixed envelope sender.