Issue with LMTP proxying and port number

[Stephan Bosch]

Op 12/01/2019 om 23:08 schreef Stephan Bosch:
>
>
> Op 06/01/2019 om 17:05 schreef Stephan Bosch:
>>
>> Op 31/12/2018 om 06:32 schreef Laz C. Peterson:
>>> Hello Sami, yes, see below.
>>>
>>> We run Dovecot at a different versions, mainly 2.2.10 (CentOS), 
>>> 2.2.22 (Ubuntu) and now 2.2.36 (CentOS).  The issue is weird, 
>>> because it only happened after the update from 2.2.10->36.  Just to 
>>> understand it would be great.
>>>
>>> I'm actually checking out the configs now ... Our SQL userdb does 
>>> not specify port.  So I'm guessing this may be to blame?
>>>
>>> (This was by design, though -- we don't want to specify one port for 
>>> different client protocols.  Though, I do recall seeing some hack 
>>> online using CASE in SQL query ...)
>>>
>>> These servers run LMTP as a unix socket as well as a TCP port 24 
>>> serving all IP sources.  The internal servers are running LMTP on 
>>> TCP port 24 (as well as unix socket, but that's irrelevant), but no 
>>> LMTP comm happens between directors and backend mail servers after 
>>> the 2.2.10->36 update on the directors with our config.  I do 
>>> apologize that I can't get more specific than those versions ...
>>>
>>> The backend mail servers function the same in our environment on 
>>> both versions 2.2.10 and 2.2.36.
>>>
>>> We are good now, as we changed the config to go to the TCP port 
>>> instead of unix socket.  But we had a good jolt of fun this morning. 
>>> :-)
>>>
>>> Would love to understand what we have done wrong, or how we 
>>> misunderstood the configuration directives -- in either version.
>>
>> I can reproduce it here, even with master.
>>
>> We'll get back to you.
>>
>> BTW, similar thread here:
>>
>> https://www.dovecot.org/pipermail/dovecot/2019-January/114071.html
>
> Hmm, did you try returning a protocol=lmtp field from passdb? This is 
> ignored by services other than lmtp and the code tells me it will then 
> default to port 24. That should be a workaround.

Oh, right, this is v2.2. There, this apparently doesn't apply :/

Regards,

Stephan.