On 9/28/20 1:27 PM, Viktor Dukhovni wrote:
> On Sun, Sep 27, 2020 at 11:31:43AM -0700, PGNet Dev wrote:
>
>> i've postfix + dovecot running on the same box; delivery between them
>> is via lmtp.
>
> The main thing that stands to me is the timeout connecing to the
> Dovecot submission port.
that _is_ postfix connecting "back" to dovecot via lmtp relay, _after_
receiving the redirected message from the sieve filter action, correct?
i suspect i may be incorrectly assuming that the chronology in postfix+dovecot
logs is meaningfu :-/
>> ( this is a reproducible, exactly 30-second delay ... )
>>
>> ==> /var/log/dovecot/dovecot.log <==
>> 2020-09-27 10:15:49
>> lmtp(us...@example1.net)<uHZDHy/IcF8APAAA+IOfAw>: Error: smtp-client: conn
>> internal.mx.example.com:60465 (10.0.1.17:60465) [1]:
>> connect(internal.mx.example.com:60465) failed: Connection timed out after 30
>> seconds
> ------------------ PROBLEM LIKELY HERE --->
>> 2020-09-27 10:15:49
>> lmtp(us...@example1.net)<uHZDHy/IcF8APAAA+IOfAw>: Error: sieve:
>> msgid=<4bzsg33hvqzw...@mx.example.com>: redirect action: failed to redirect
>> message to <us...@example2.net>: smtp(internal.mx.example.com:60465): RCPT
>> TO failed: Connect timed out (temporary failure)
> ------------------ <---
>
i saw that's where/when the Error: is occurring; wasn't clear whether it's the
result of some message- &/or ssl- munging 'during' the sieve -> postfix ->
dovecot circuit.
will look more closely here.
> However, ...
>
>> 2020-09-27 10:15:49 submission-login: Debug: SSL error:
>> SSL_accept() failed: error:1408F10B:SSL routines:ssl3_get_record:wrong
>> version number
> The above again looks like cleartext (e.g. "QUIT<CRLF>") sent to a port that
> expects TLS.
>
>
>> ==> /var/log/dovecot/dovecot-debug.log <==
>> 2020-09-27 10:15:49 submission-login: Debug: SSL error:
>> SSL_accept() syscall failed: Invalid argument
>
> And the above may be the reason why connections are timing out...
i'm pausing at that 'however' ...
couple of questions:
i typically turn ON implicit TLS, with cert verification, for any all TCP
transports, local or not.
when a postfix/dovecot, same-machine setup 'share' an lmtp socket, e.g.,
@ dovecot
...
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0600
user = postfix
group = postfix
}
...
@ postfix
...
virtual_transport = lmtp:unix:private/dovecot-lmtp
...
iiuc, there's no security need/benefit for any TLS/SSL in that
handshake/transport, and can (should?) be disabled.
is that correct?
and,
re: the "port that expects TLS", that appears to be the dovecot
'submission-port'.
to be clear, do I understand your comment
> Since both the server and the client here are Dovecot
correctly that -- by that point -- postfix is out of the picutre completely, &
no longer involved, and it's all a dovecot 'issue'?
> you might have better luck on the Dovecot list.
already posted; waiting on any interest/reply there.
useful to know that this is completely !postfix, if indeed the case.
