Re: long_queue_ids

[Bastian Blank]

On Thu, May 27, 2021 at 11:50:14PM -0400, post...@ptld.com wrote:
> Is it possible for two different servers to have a same long_queue_ids ?
> Are the long queue ID's unique to the world or only unique to that postfix
> instance?

Queue ID are only unique to a single Postfix instance.  Why do you think
otherwise?

Bastian

-- 
There is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9

Re: long_queue_ids

[Bastian Blank]

On Thu, May 27, 2021 at 11:31:15AM -0400, post...@ptld.com wrote:
> Any other tips for parsing logs for queue ID?

Only contain alphanumeric characters, at least 11 characters long.

Bastian

-- 
You're too beautiful to ignore.  Too much woman.
-- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown

Relay denied - failed from WORLD 2 LAN

[Maurizio Caloro]

Hello

want to put this setup into operation and it failed. I have a Postfix server
with this setup and Spamassassin.

in the background there is an HCL Domino server. I was able to E-Mail from
(LAN) to myself (WORLD), but

E-mail that sending (WORLD) to (LAN INSIDE), never arrive.  

 

also didnt see the mechanisms from incomming mail that will send to HCL
Domino Server? try to put this

over submission so also will blocking may Spamers. thanks for help

-

mail_version = 3.4.14

 

log

May 27 22:17:57 srvcar010 postfix/smtpd[9596]: connect from
unknown[117.92.203.30]

May 27 22:17:58 srvcar010 postfix/smtpd[9596]: NOQUEUE: reject: RCPT from
unknown[117.92.203.30]: 450 4.7.25 Client host rejected: cannot find your
hostname, [117.92.203.30]; from=  euaq...@ulis.com
to=  usern...@domain.ch proto=ESMTP
helo=

May 27 22:17:58 srvcar010 postfix/smtpd[9596]: disconnect from
unknown[117.92.203.30] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4

May 27 22:18:01 srvcar010 postfix/postscreen[9582]: CONNECT from
[45.148.10.190]:41226 to [192.168.201.87]:25

--

ay 27 22:18:11 srvcar010 postfix/postscreen[9582]: CONNECT from
[ipaddress]:55328 to [192.168.201.87]:25

May 27 22:18:11 srvcar010 postfix/postscreen[9582]: PASS OLD
[ipaddress]:55328

May 27 22:18:11 srvcar010 postfix/smtpd[9596]: connect from smtp.mailer.ch
[ipaddress]

May 27 22:18:11 srvcar010 postfix/smtpd[9596]: Anonymous TLS connection
established from smtp.mailer.ch[ipaddress]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

May 27 22:18:11 srvcar010 postfix/smtpd[9596]: NOQUEUE: reject: RCPT from
smtp.mailer.ch[ipaddress]: 554 5.7.1  
usern...@domain.ch: Relay access denied; from= 
usern...@domain.ch to=  usern...@domain.ch
proto=ESMTP helo=

May 27 22:18:11 srvcar010 postfix/smtpd[9596]: disconnect from
smtp.mailer.ch [ipaddress] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1
quit=1 commands=6/8

May 27 22:18:14 srvcar010 postfix/postscreen[9582]: CONNECT from
[45.148.10.190]:39942 to [192.168.201.87]:25

--

root@s:/etc/postfix# postconf -n

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

append_dot_mydomain = no

biff = no

broken_sasl_auth_clients = yes

command_directory = /usr/sbin

compatibility_level = 2

daemon_directory = /usr/lib/postfix/sbin

data_directory = /var/lib/postfix

debug_peer_level = 2

debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5

disable_vrfy_command = yes

html_directory = no

inet_interfaces = all

inet_protocols = all

mailbox_size_limit = 0

mailq_path = /usr/bin/mailq

message_size_limit = 25428800

milter_connect_macros = "i j {daemon_name} v {if_name} _"

milter_default_action = accept

milter_mail_macros = i {auth_type} {auth_authen} {auth_author} {mail_addr}
{mail_host} {mail_mailer}

milter_protocol = 6

myhostname = mail.carag.com

mynetworks = 80.254.176.41/32, 192.168.201.0/24, 192.168.202.0/24,
127.0.0.0/8

newaliases_path = /usr/bin/newaliases

non_smtpd_milters = $smtpd_milters

postscreen_access_list = permit_mynetworks,

postscreen_bare_newline_action = ignore

postscreen_bare_newline_enable = yes

postscreen_blacklist_action = drop

postscreen_cache_cleanup_interval = 24h

postscreen_cache_map = btree:/var/lib/postfix/postscreen_cache

postscreen_dnsbl_action = enforce

postscreen_dnsbl_reply_map = pcre:/etc/postfix/dnsbl_reply_map.pcre

postscreen_dnsbl_sites = zen.spamhaus.org*3

postscreen_dnsbl_threshold = 3

postscreen_dnsbl_whitelist_threshold = -1

postscreen_greet_action = enforce

postscreen_greet_wait = 4s

postscreen_non_smtp_command_action = drop

postscreen_non_smtp_command_enable = yes

postscreen_pipelining_action = enforce

postscreen_pipelining_enable = yes

postscreen_whitelist_interfaces = 80.254.176.41 static:all

queue_directory = /var/spool/postfix

readme_directory = /usr/share/doc/postfix

relayhost = 192.168.201.117

sample_directory = /usr/share/doc/postfix

sendmail_path = /usr/sbin/sendmail

setgid_group = postdrop

smtp_address_preference = any

smtp_dns_support_level = dnssec

smtp_header_checks = regexp:/etc/postfix/header_checks

smtp_host_lookup = dns

smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

smtp_tls_cert_file = /etc/letsencrypt/live/mail.carag.com/fullchain.pem

smtp_tls_exclude_ciphers = aNULL, MD5

smtp_tls_key_file = /etc/letsencrypt/live/mail.carag.com/privkey.pem

smtp_tls_loglevel = 1

smtp_tls_mandatory_ciphers = high

smtp_tls_mandatory_exclude_ciphers = aNULL, MD5

smtp_tls_mandatory_protocols = !SSLv2, !TLSv1, !TLSv1.1

smtp_tls_note_starttls_offer = yes

smtp_tls_protocols = !SSLv2, !TLSv1, !TLSv1.1

smtp_tls_security_level = may

smtp_tls_session_cache_database =
btree:/var/lib/postfix/smtp_tls_session_cache

smtp_use_tls = yes

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)

smtpd_client_r

Re: Relay denied - failed from WORLD 2 LAN

[IL Ka]

On Fri, May 28, 2021 at 10:40 AM Maurizio Caloro  wrote:

> Hello
>
> want to put this setup into operation and it failed. I have a Postfix
> server with this setup and Spamassassin.
>
> in the background there is an HCL Domino server. I was able to E-Mail from
> (LAN) to myself (WORLD), but
>
> E-mail that sending (WORLD) to (LAN INSIDE), never arrive.
>

What is the name of the domain of your server? "carag.com"?

Postfix accepts emails to "mydestination" or "relay_domains" from the
"WORLD".
It seems that you didn't set any of them (I do not see em in your postconf
-n output)
Default values could be checked with "postconf -d".

You probably should set mydestination = $mydomain to accept mail
Or relay_domains= $mydomain and then configure transport(5) to send
email to the Domino


>
>
> also didnt see the mechanisms from incomming mail that will send to HCL
> Domino Server?
>
That could be done with "relay_domains"  and transport(5)
Or with "mydestination", "mailbox_transport" and lmtp if Domino supports it.

See http://www.postfix.org/BASIC_CONFIGURATION_README.html

Re: Relay denied - failed from WORLD 2 LAN

[postfix]

On 05-28-2021 3:39 am, Maurizio Caloro wrote:

May 27 22:17:58 srvcar010 postfix/smtpd[9596]: NOQUEUE: reject: RCPT 
from unknown[117.92.203.30]: 450 4.7.25 Client host rejected: cannot 
find your hostname, [117.92.203.30]; from=euaq...@ulis.com 
to=usern...@domain.ch proto=ESMTP helo=




This email was rejected by postfix because 
reject_unknown_client_hostname is set in smtpd_client_restrictions and 
there is no DNS ptr record setup for the IP (117.92.203.30) the email 
came from.





May 27 22:18:11 srvcar010 postfix/smtpd[9596]: NOQUEUE: reject: RCPT 
from smtp.mailer.ch[ipaddress]: 554 5.7.1 usern...@domain.ch: Relay 
access denied; from=usern...@domain.ch to=usern...@domain.ch 
proto=ESMTP helo=




And this email was rejected because postfix does not know it is supposed 
to accept mail for domain.ch.
There are a few ways to do that such as mydestination, relay_domains, 
virtual_mailbox_domains, etc.

haproxy mention in logs

[postfix]

postfix/smtpd[8568]: warning: hostname zg-0520a-211.stretchoid.com does 
not resolve to address 192.241.205.222: Name or service not known

postfix/smtpd[8568]: connect from unknown[192.241.205.222]
postfix/smtpd[8568]: lost connection after UNKNOWN from 
unknown[192.241.205.222]
postfix/smtpd[8568]: disconnect from unknown[192.241.205.222] 
unknown=0/1 commands=0/1


postfix/smtpd[8585]: warning: haproxy read: unexpected EOF
postfix/smtpd[8585]: connect from unknown[unknown]
postfix/smtpd[8585]: disconnect from unknown[unknown] commands=0/0


I would like a better understanding of what is happening when the logs 
include "warning: haproxy read:". Is that generated by postfix based on 
what? Or is it generated by haproxy and postfix just pass thru displays 
it?


Yes the server sits behind haproxy, but what has me curious is on most 
log entries like the first one above there is no mention of haproxy, so 
why is it on the second log entry? Whats the difference?


FYI: -o smtpd_upstream_proxy_protocol=haproxy is set under submission.

Re: haproxy mention in logs

[Wietse Venema]

post...@ptld.com:
> postfix/smtpd[8568]: warning: hostname zg-0520a-211.stretchoid.com does 
> not resolve to address 192.241.205.222: Name or service not known
> postfix/smtpd[8568]: connect from unknown[192.241.205.222]
> postfix/smtpd[8568]: lost connection after UNKNOWN from 
> unknown[192.241.205.222]
> postfix/smtpd[8568]: disconnect from unknown[192.241.205.222] 
> unknown=0/1 commands=0/1
> 
> postfix/smtpd[8585]: warning: haproxy read: unexpected EOF
> postfix/smtpd[8585]: connect from unknown[unknown]
> postfix/smtpd[8585]: disconnect from unknown[unknown] commands=0/0
> 
> 
> I would like a better understanding of what is happening when the logs 
> include "warning: haproxy read:". Is that generated by postfix based on 
> what? Or is it generated by haproxy and postfix just pass thru displays 
> it?

As documented HAPPROXY sends one message with the protocol and
remote/local endpoint information. If HAPROXY sends anything else
then that would be a HAPROXY bug.

Wietse

> Yes the server sits behind haproxy, but what has me curious is on most 
> log entries like the first one above there is no mention of haproxy, so 
> why is it on the second log entry? Whats the difference?
> 
> FYI: -o smtpd_upstream_proxy_protocol=haproxy is set under submission.
> 

Newbie question about transport_maps failing

[David Favor]

My goal is to limit allowed sender domains, to ensure no
mail config problem sends from a domain with no no SPF
authorization for sending IP.

What I've done...

1) Setup /etc/postfix/transport

# cat /etc/postfix/transport
davidfavor.com :
fixdeliver.com :
* discard:

# postmap /etc/postfix/transport

# postmap -s /etc/postfix/transport
*   discard:
davidfavor.com  :
fixdeliver.com  :

3) postfix reload

4) Send a test message...

echo test | mailx -r some...@foo.com -s "Test Message - $(date)" 
da...@davidfavor.com

5) inotifywait camped on /etc/postfix shows /etc/postfix/transport.db being 
read.

6) And... messages still delivers, rather than being blocked.

May 28 10:15:46 net17-david-favor-smtp postfix/qmgr[29555]: CE2801BA2030: 
from=, size=430, nrcpt=1 (queue active)
May 28 10:15:46 net17-david-favor-smtp postfix/smtp[29585]: CE2801BA2030: to=, relay=smtp.davidfavor.com[142.44.168.82]:25, delay=0.03, delays=0/0/0.02/0.01, dsn=2.0.0, 
status=sent (250 Queued)


7) Someone let me know how to fix this.

Thanks...

8) Dump of my entire config...

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 0
mydestination = localhost, localhost.localdomain
myhostname = mta1.davidfavor.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = davidfavor.com
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_bind_address = 144.217.229.104
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
defer_unauth_destination
smtpd_tls_cert_file = /etc/letsencrypt/live/mta1.davidfavor.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mta1.davidfavor.com/privkey.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
transport_maps = hash:/etc/postfix/transport

Re: Newbie question about transport_maps failing

[IL Ka]

On Fri, May 28, 2021 at 6:28 PM David Favor  wrote:

> My goal is to limit allowed sender domains, to ensure no
> mail config problem sends from a domain with no no SPF
> authorization for sending IP.
>

If you want to choose transport based on sender, you probably want
"sender_dependent_default_transport_maps"

http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps

Re: haproxy mention in logs

[postfix]

On 05-28-2021 11:00 am, Wietse Venema wrote:

As documented HAPPROXY sends one message with the protocol and
remote/local endpoint information. If HAPROXY sends anything else
then that would be a HAPROXY bug.


Im sorry for being "slow" but im not understanding and need further 
clarification.


HAPPROXY sends one message with the protocol and remote/local endpoint 
information


I assume that means always. Then im still confused why in one log entry 
there is no mention of haproxy and in the other log entry there is. What 
is the difference if that log message is a result of haproxy always 
sening one message on all connections?



If HAPROXY sends anything else then that would be a HAPROXY bug.


If? So is that the situation this time or not? Are you saying that log 
message *is* a result of a haproxy bug?

Re: Enforced TLS with Opportunistic DANE

[Matthew Richardson]

On Thu, 27 May 2021 13:07:39 -0400, Viktor Dukhovni wrote:-

>On Thu, May 27, 2021 at 05:42:34PM +0100, Matthew Richardson wrote:
>
>> and I am wanting to enhance this for certain specific domains to
>> require mandatory encryption, without neutering DANE if present.
>> Thus, the suggestion of an additional "dane-or-encrypt" level seems
>> like a very good idea!
>
>Presumably, in practice you'd use that only for specific destinations
>via the policy table, rather than globally.

Yes - correct - using "smtp_tls_policy_maps", or any other better way.

>The barrier to progress is deciding whether a point solution such as
>a new level like "dane-or-encrypt" is good enough, or whether the right
>way forward is a more general syntax for specifying what happends when
>a dynamic level like dane finds its preconditions missing.
>
>A more complete set of options might be:
>
>* "dane", or else "encrypt"
>
>* "dane", or else "secure" (equivalently "verify" with explicit
>  "match" patterns).
>
>* "dane", or else "mta-sts" (built-in "mta-sts" is not presently
>  supported or even planned, but perhaps some day...)
>
>* "dane", with an "on fail" override to deliver anyway, but the
>  possible MiTM is logged and is "tamper-evident".  (This
>  should/would be discouraged, except as a limited-duration
>  work-around).
>
>* "mta-sts", or ... (again if some day implemented)
>
>which requires some design.
>
>If a "dane-or-encrypt" feature is implemented it would have to be
>supported for a long time, and would need to have a clean mapping onto
>the long-term approach, allowing its implementation to be subsumed by
>any later more general solution.  So some care is required in deciding
>the path forward.

I would agree that this does require some care/consideration in the design.
Indeed, I had not spotted that some of the other higher security options
would also disable DANE.  It looks as if the existing options for
"smtp_tls_policy_maps" lack flexibility to work well with DANE.

Certainly, having to disable DANE checking to force encryption is not a
good thing!  :-(

If it helps (it may not!), another way to look at this is wanting to say
"no plaintext" on certain outgoing SMTP traffic.  This seems to be
analagous to the "reject_plaintext_session" which one can use as within
"check_sender_access" in "smtpd_recipient_restrictions" to control
incomming SMTP traffic.

Personally I think "dane-or-encrypt" is good enough (but I am biased
because that is what I am trying to get working!).  If this could be done,
without prejudicing being able to do the other options later, that would be
ideal.

Best wishes,
Matthew

Re: haproxy mention in logs

[Wietse Venema]

This is one SMTP session, with a host that has bad DNS.

Below is an SMTP session from a host that has bad DNS.

> postfix/smtpd[8568]: warning: hostname zg-0520a-211.stretchoid.com does 
> not resolve to address 192.241.205.222: Name or service not known
> postfix/smtpd[8568]: connect from unknown[192.241.205.222]
> postfix/smtpd[8568]: lost connection after UNKNOWN from 
> unknown[192.241.205.222]
> postfix/smtpd[8568]: disconnect from unknown[192.241.205.222] 
> unknown=0/1 commands=0/1

Below is a DIFFERENT SMTP session where Postfix receives an
incomplete HAPROXY message.

> postfix/smtpd[8585]: warning: haproxy read: unexpected EOF
> postfix/smtpd[8585]: connect from unknown[unknown]
> postfix/smtpd[8585]: disconnect from unknown[unknown] commands=0/0

Note that HAPROXY sends one message at the BEGINNING of an SMTP
session. There are no HAPROXY messages at any other point in time.

Wietse

Re: Enforced TLS with Opportunistic DANE

[Wietse Venema]

Viktor Dukhovni:
> The barrier to progress is deciding whether a point solution such as
> a new level like "dane-or-encrypt" is good enough, or whether the right
> way forward is a more general syntax for specifying what happends when
> a dynamic level like dane finds its preconditions missing.
> 
> A more complete set of options might be:
> 
> * "dane", or else "encrypt"
> 
> * "dane", or else "secure" (equivalently "verify" with explicit
>   "match" patterns).
> 
> * "dane", or else "mta-sts" (built-in "mta-sts" is not presently
>   supported or even planned, but perhaps some day...)
> 
> * "dane", with an "on fail" override to deliver anyway, but the
>   possible MiTM is logged and is "tamper-evident".  (This
>   should/would be discouraged, except as a limited-duration
>   work-around).
> 
> * "mta-sts", or ... (again if some day implemented)
> 
> which requires some design.

Indeed, if we want to support multiple acceptable TLS security
settings then it should not be just for DANE.

Victor and I started a discussion on multiple acceptable security
settings six years ago (I recall that I was looking for a way to
discover sites that supported stronger-than-opportunisic TLS, but
it could equally well be used to allow different forms of mandatory
TLS). Unfortunately any notes that I kept on paper or whiteboard
were lost in the shuffle as I changed jobs.

Postfix's opportunistic TLS is like an alias for {none, encrypt},
dane is like {none, encrypt, dane-only} while what you asked for
corresponds to something like {encrypt, dane-only} or maybe {verify,
dane-only}.

Wietse

Re: Newbie question about transport_maps failing

[IL Ka]

>
>
> > If you want to choose transport based on sender, you probably want
> > "sender_dependent_default_transport_maps"
> >
> >
> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> >
>
>
It seems that this option doesn't support wildcards.
It says
>The tables are searched by the envelope sender address and @domain.

So, I set "discard" as default transport, and did one exception with this
option.

main.cf:
sender_dependent_default_transport_maps = hash:/etc/postfix/map
default_transport=discard

map:
@example.orgsmtp

Sending mail from "example.org"
$ swaks --to u...@example.net --from r...@example.org -4 --server 127.0.0.1

Goes to SMTP:
postfix/smtp[4156]: 62D4D9F81D: to=, relay=none,
delay=0.04, delays=0.01/0.01/0.03/0, dsn=5.1.0, status=bounced (Domain
example.net does not accept mail (nullMX))

Sending mail from "example.net"
$ swaks --to u...@example.net --from r...@example.net -4 --server 127.0.0.1

Discard:
 postfix/discard[4162]: 2209D9F81D: to=, relay=none,
delay=0.01, delays=0.01/0/0/0, dsn=2.0.0, status=sent (example.net)

Re: Newbie question about transport_maps failing

[Wietse Venema]

IL Ka:
> >
> >
> > > If you want to choose transport based on sender, you probably want
> > > "sender_dependent_default_transport_maps"
> > >
> > >
> > http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> > >
> >
> >
> It seems that this option doesn't support wildcards.

Yes it does. Use a pcre: or regexp: table.


> It says
> >The tables are searched by the envelope sender address and @domain.

That's used when you DON'T specify pcre, regexp, etc.

Wietse

Re: Newbie question about transport_maps failing

[Viktor Dukhovni]

On Fri, May 28, 2021 at 10:27:29AM -0500, David Favor wrote:

> My goal is to limit allowed sender domains, to ensure no
> mail config problem sends from a domain with no no SPF
> authorization for sending IP.

The transport table is surely the wrong place to do that.  Instead, use
access(5) to refuse mail from unsupported sender addresses.

For local submission (often out of scope if the MTA in question
has no local submission users, b/c it a dedicated server, or
an outbound instance in a multi-instance setup, ...), Postfix 3.6
adds local_login_sender_maps which can be used to restrict the
allowed domains for local submission:

local_login_sender_maps =
inline:{ { root = *}, { postfix = * } },
static:{ @davidfavor.com, @fixdeliver.com }

If local submission is in fact in scope for you, because you have
untrusted users logged into the MTA, you can upgrade to Postfix 3.6,
or use a multi-instance configuration with local submission going to
a null-client instance which relays to the MTA instance, which can
use access(5) to reject relaying with non-local sender addresses.

-- 
Viktor.

Re: Enforced TLS with Opportunistic DANE

[Viktor Dukhovni]

On Fri, May 28, 2021 at 01:44:54PM -0400, Wietse Venema wrote:

> > The barrier to progress is deciding whether a point solution such as
> > a new level like "dane-or-encrypt" is good enough, or whether the right
> > way forward is a more general syntax for specifying what happends when
> > a dynamic level like dane finds its preconditions missing.
> > 
> > [...]
> > 
> > which requires some design.
> 
> Victor and I started a discussion on multiple acceptable security
> settings six years ago (I recall that I was looking for a way to
> discover sites that supported stronger-than-opportunisic TLS, but
> it could equally well be used to allow different forms of mandatory
> TLS). Unfortunately any notes that I kept on paper or whiteboard
> were lost in the shuffle as I changed jobs.

You probably still have what we happened to share in email, the thread
subject is "TLS user interface" from 2014-10-19 through 2014-10-24.

> Postfix's opportunistic TLS is like an alias for {none, encrypt},
> dane is like {none, encrypt, dane-only} while what you asked for
> corresponds to something like {encrypt, dane-only} or maybe {verify,
> dane-only}.

Yes, something like that, but with care about downgrades.  So it is
really:

dane =
if | MX host zone unsigned-> may
   | TLSA lookup fails-> next MX or defer
   | signed usable TLSA records   -> dane-only
   | signed all unusable TLSA records -> encrypt
   | no signed TLSA records   -> may

dane-only =
if | STARTTLS not offered -> next MX or defer
   | handshake fails  -> next MX or defer
   | TLSA records don't match -> next MX or defer

encrypt =
if | STARTTLS not offered -> next MX or defer
   | STARTTLS offered -> mustTLS

mustTLS =
if | handshake succeeds   -> send with unauthenticated TLS
   | otherwise-> next MX or defer

may = 
if | STARTTLS not offered -> none
   | STARTTLS offered -> tryTLS

tryTLS =
if | handshake succeeds   -> unauthenticated TLS
   | if message is fresh  -> next MX or defer
   | if message age > backoff time-> reconnect + none

none = try sending in the clear

... verify, fingerprint ...

Adding more conditional branches without introducing inadvertent
downgrades, and possibly allowing explicit downgrades, ... is
a bit of a challenge.

-- 
Viktor.

Re: Enforced TLS with Opportunistic DANE

[Wietse Venema]

Viktor Dukhovni:
> On Fri, May 28, 2021 at 01:44:54PM -0400, Wietse Venema wrote:
> 
> > > The barrier to progress is deciding whether a point solution such as
> > > a new level like "dane-or-encrypt" is good enough, or whether the right
> > > way forward is a more general syntax for specifying what happends when
> > > a dynamic level like dane finds its preconditions missing.
> > > 
> > > [...]
> > > 
> > > which requires some design.
> > 
> > Victor and I started a discussion on multiple acceptable security
> > settings six years ago (I recall that I was looking for a way to
> > discover sites that supported stronger-than-opportunisic TLS, but
> > it could equally well be used to allow different forms of mandatory
> > TLS). Unfortunately any notes that I kept on paper or whiteboard
> > were lost in the shuffle as I changed jobs.
> 
> You probably still have what we happened to share in email, the thread
> subject is "TLS user interface" from 2014-10-19 through 2014-10-24.

Thanks, I found some emails with that subject.

> > Postfix's opportunistic TLS is like an alias for {none, encrypt},
> > dane is like {none, encrypt, dane-only} while what you asked for
> > corresponds to something like {encrypt, dane-only} or maybe {verify,
> > dane-only}.
> 
> Yes, something like that, but with care about downgrades.  So it is
> really:

Yes, and that maze of implicit fallback logic will have to go if
we want to give the user more control, as in:

none = no encryption.
encrypt = encryption but no trusted server.
verify = the server certificate is PKI verified, and contains an expected name.
secure = ditto
dane = the server certificate (issuer) matches the TLSA record from secure DNS.

Instead of implicit fallback, just do what they say.  There will
need to be logging to justify why some the { ... } elements could
not be realized.

Wietse

Logging - Connect Order

[postfix]

Without recompiling postfix, is there a way to get the PTR hostname 
warning to come after the connect message in the logs?