Viktor Dukhovni via Postfix-users:
> > > Aug 15 12:22:18 flopster postfix/cleanup[9839]: 5058916E081A:
> > > message-id=<20230815092218.5058916e0...@flopster.at.encryp.ch>
> > > Aug 15 12:22:18 flopster postfix/qmgr[11478]: 5058916E081A:
> > > from=<address.verif...@at.encryp.ch>, size=316, nrcpt=1 (queue active)
> > > Aug 15 12:22:21 flopster postfix/smtp[9437]: 5058916E081A: Cannot start
> > > TLS: handshake failure
> > > Aug 15 12:22:23 flopster postfix/smtp[9437]: 5058916E081A:
> > > to=<l...@east.ru>, relay=mail.east.ru[195.170.62.138]:25, delay=5.1,
> > > delays=0.01/0/5.1/0, dsn=4.7.5, status=undeliverable (Cannot start TLS:
> > > handshake failure)
> > > Aug 15 12:22:23 flopster postfix/qmgr[11478]: 5058916E081A: removed
>
> Indeed, so long as the TCP connection succeeds, address verification
> probes may not queue to retry a cleartext delivery. Queueing probes
> for a cleartext retry may expose your queue to greater risk of
> congestion. But perhaps it is a risk that one should be prepared to
> take when enabling sender or recipient verification.
>
> Wietse likely has more to say on this topic. I haven't looked very
> closely at the address verification machinery.
Address verificatiopn is largely orthogonal to errro handling except
when there is an error.
The code in question is:
if (PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE)
RETRY_AS_PLAINTEXT;
return (smtp_misc_fail(state, state->tls->level == TLS_LEV_MAY ?
SMTP_NOTHROTTLE : SMTP_THROTTLE,
DSN_BY_LOCAL_MTA,
SMTP_RESP_FAKE(&fake, "4.7.5"),
"Cannot start TLS: handshake failure"));
Where PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE is defined as:
#define PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE \
(session->tls_context == 0 \
&& state->tls->level == TLS_LEV_MAY \
&& PREACTIVE_DELAY >= var_min_backoff_time \
&& !HAVE_SASL_CREDENTIALS)
#define PREACTIVE_DELAY \
(session->state->request->msg_stats.active_arrival.tv_sec - \
session->state->request->msg_stats.incoming_arrival.tv_sec)
#define DEF_MIN_BACKOFF_TIME DEF_QUEUE_RUN_DELAY
#define DEF_QUEUE_RUN_DELAY "300s"
With that, the condition evaluates to:
1: session->tls_context == 0 true
2: state->tls->level == TLS_LEV_MAY presumably true
3: PREACTIVE_DELAY >= var_min_backoff_time false
4: !HAVE_SASL_CREDENTIALS ?
Condition 4 is easy: Postfix will not fall back to plaintext when
the destination has SASL credientials. This is safe for plaintext
SASL logins which are the most common. Falling back to plaintext
would fail (message returned to sender) with servers that announce
AUTH only for encrypted sessions.
Condition 3 may need more nuance. The code is OK for non-probe
messages; it prefers to retry later with TLS, over immediately
falling back to plaintext. When the later retry also fails in the
TLS handhake, then Postfix will immediately fall back to plaintext.
However, probes don't retry, so maybe we should skip condition 3
for probes.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
