Using attachment_dir with plugin zlib corrupt mails

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Using attachment_dir with plugin zlib corrupt mails

Dovecot mailing list
Hello:
 
  I have found the same problem reported above by Patrick Cernko affecting our system and corrupting our messages. Even worse, Outlook 2016 will no synchronize and the clients cannot see any message, even if there is only one corrupted mail per mailbox.
 
  I cannot figure out a feasible workaround for our system, and I can see that in new version 2.38 the bug is not fixed.
 
 Will this issue be treated soon?
 
 Thanks a lot
 
     Maren Zubizarreta

 

WARNING: using attachment_dir with plugin zlib can corrupt mails

Patrick Cernko [hidden email]
Fri Jul 19 17:52:37 EEST 2019


Hello list, hello Dovecot developers,
 
this week, I discovered a serious bug in Dovecot, that lead to several 
broken mails on our servers. The bug corrupts the first few characters 
of the mail header during saving. On our setup, it was almost always 
only the very first line of text, that was corrupted.
 
Depending on the IMAP client (they seem to request different header 
fields, ... during mail access), the bug causes the imap process to hang 
up the TCP connection and log errors like this:
 
> imap(USERNAME)<4767><TeQP4ASOTK5/AAAB>: Error: Corrupted record in index cache file /IMAP/mail/mailboxes/USERNAME/mdbox/mailboxes/Trash/dbox-Mails/dovecot.index.cache: UID 489113: Broken fields in mailbox Trash: read(attachments-connector(zlib(/IMAP/mail/mailboxes/USERNAME/mdbox/storage/m.813))): FETCH BODY[HEADER.FIELDS (RETURN-PATH SUBJECT)] got too little data: 2 vs 122
 
In our case that finally grabbed my attention, the client was the users 
iphone that did not display any new messages but his Thunderbird did.
 
The bug seems to be triggered by a bad "interaction" of attachment_dir 
option and zlib plugin. If you use both, you most likely are affected, 
too, except you only use zlib plugin for reading previously compressed 
stored mails. That's also the workaround we use now: zlib plugin only 
enabled in mail_plugins but no plugin/zlib_save set.
 
The bug occurs on very specific mails. Due to privacy reasons I could 
not provide sample mails here. Storing such mails seems to trigger the 
bug reproducible.
 
 
I attached a very minimal doveconf -n config, that can be used to 
trigger the bug. If one of the developers is interested, I can try to 
generate an "anonymized" version of such a specific mail that still 
causes the issue. I discovered the bug on our productive systems, 
running latest Dovecot 2.2 release, but the latest 2.3 I used during 
debugging is affected, too.
 
During debugging, I also found one hint, that might help find the bug: 
If you store a problematic mail with zlib_save=gz (or zlib_save=bz2) and 
then disable the zlib plugin in mail_plugins, you can call
 
doveadm fetch -u test hdr all | grep -v ^hdr: | gzip --decompress
 
on test's mailbox with only that one broken mail.
This will display the beginning of the rfc822 mail text until gzip 
terminates with "gzip: stdin: unexpected end of file", approximately 
after twice the length of the mail HEADER. This might indicate, that 
dovecot stores the uncompressed size of the header in it's data 
structures although the mail is stored compressed.
 
 
I also found a very efficient way to find all affected mails in our setup:
 
doveadm -f flow fetch -A 'user guid mailbox uid seq flags hdr' all | \
   grep -a "^[^ ]+ user=" | \
   grep -avF ' hdr=Return-path: ' | \
   grep -av '.* hdr=[[:print:][:space:]]*$'
(runtime for ~6M mails on our servers was 20-30min)
 
This can be even more optimized if you have a powerful storage system 
with GNU parallel:
> doveadm user '*' | parallel "doveadm -f flow fetch -u '{}' 'user guid mailbox uid seq flags hdr' all | grep -a '^user=' | grep -avF ' hdr=Return-path: ' | grep -av '.* hdr=[[:print:][:space:]]*$' || true"
(runtime for ~6M mails on our servers was ~4min)
 
The command will give you a list of mails that possibly are affected, 
check the full output of
 
doveadm fetch -u USERNAME hdr guid GUID | less
 
to verify that the header is really broken.
 
On our systems I found 39 mails within ~12M mails.
 
I was able to recover these mails "manually" by reconstructing the 
Return-Path header line, importing the fixed mails and expunging the 
corrupt ones. Before importing, I had to disable zlib_save option obviously.
 
Best regards,
-- 
Patrick Cernko <pcernko at mpi-klsb.mpg.de> +49 681 9325 5815
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme
-------------- next part --------------
# 2.3.6.1 (d124cc84b): /etc/dovecot/dovecot.conf
# OS: Linux 4.14.127.1.amd64-smp x86_64 Debian 9.9 
# Hostname: adove.mpi-klsb.mpg.de
listen = *
mail_attachment_dir = /var/vmail/attachments
mail_attachment_fs = posix
mail_gid = nogroup
mail_home = /var/vmail/%u
mail_location = mdbox:~/mdbox
mail_plugins = " zlib"
mail_uid = nobody
passdb {
  args = /etc/dovecot/userdb
  driver = passwd-file
}
plugin {
  zlib_save = gz
}
protocols = imap
userdb {
  args = /etc/dovecot/userdb
  driver = passwd-file
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5324 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://dovecot.org/pipermail/dovecot/attachments/20190719/3da620ad/attachment-0001.p7s>

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Using attachment_dir with plugin zlib corrupt mails

Dovecot mailing list
Can you test if https://github.com/dovecot/core/commit/5068b11e594ad7cc1f7cedf2bd9280520e0e534d.patch fixes it for you?

On 10 Oct 2019, at 11.34, MAREN ZUBIZARRETA via dovecot <[hidden email]> wrote:

Hello:
 
  I have found the same problem reported above by Patrick Cernko affecting our system and corrupting our messages. Even worse, Outlook 2016 will no synchronize and the clients cannot see any message, even if there is only one corrupted mail per mailbox.
 
  I cannot figure out a feasible workaround for our system, and I can see that in new version 2.38 the bug is not fixed.
 
 Will this issue be treated soon?
 
 Thanks a lot
 
     Maren Zubizarreta

 

WARNING: using attachment_dir with plugin zlib can corrupt mails

Patrick Cernko [hidden email]
Fri Jul 19 17:52:37 EEST 2019

Hello list, hello Dovecot developers,
 
this week, I discovered a serious bug in Dovecot, that lead to several 
broken mails on our servers. The bug corrupts the first few characters 
of the mail header during saving. On our setup, it was almost always 
only the very first line of text, that was corrupted.
 
Depending on the IMAP client (they seem to request different header 
fields, ... during mail access), the bug causes the imap process to hang 
up the TCP connection and log errors like this:
 
> imap(USERNAME)<4767><TeQP4ASOTK5/AAAB>: Error: Corrupted record in index cache file /IMAP/mail/mailboxes/USERNAME/mdbox/mailboxes/Trash/dbox-Mails/dovecot.index.cache: UID 489113: Broken fields in mailbox Trash: read(attachments-connector(zlib(/IMAP/mail/mailboxes/USERNAME/mdbox/storage/m.813))): FETCH BODY[HEADER.FIELDS (RETURN-PATH SUBJECT)] got too little data: 2 vs 122
 
In our case that finally grabbed my attention, the client was the users 
iphone that did not display any new messages but his Thunderbird did.
 
The bug seems to be triggered by a bad "interaction" of attachment_dir 
option and zlib plugin. If you use both, you most likely are affected, 
too, except you only use zlib plugin for reading previously compressed 
stored mails. That's also the workaround we use now: zlib plugin only 
enabled in mail_plugins but no plugin/zlib_save set.
 
The bug occurs on very specific mails. Due to privacy reasons I could 
not provide sample mails here. Storing such mails seems to trigger the 
bug reproducible.
 
 
I attached a very minimal doveconf -n config, that can be used to 
trigger the bug. If one of the developers is interested, I can try to 
generate an "anonymized" version of such a specific mail that still 
causes the issue. I discovered the bug on our productive systems, 
running latest Dovecot 2.2 release, but the latest 2.3 I used during 
debugging is affected, too.
 
During debugging, I also found one hint, that might help find the bug: 
If you store a problematic mail with zlib_save=gz (or zlib_save=bz2) and 
then disable the zlib plugin in mail_plugins, you can call
 
doveadm fetch -u test hdr all | grep -v ^hdr: | gzip --decompress
 
on test's mailbox with only that one broken mail.
This will display the beginning of the rfc822 mail text until gzip 
terminates with "gzip: stdin: unexpected end of file", approximately 
after twice the length of the mail HEADER. This might indicate, that 
dovecot stores the uncompressed size of the header in it's data 
structures although the mail is stored compressed.
 
 
I also found a very efficient way to find all affected mails in our setup:
 
doveadm -f flow fetch -A 'user guid mailbox uid seq flags hdr' all | \
   grep -a "^[^ ]+ user=" | \
   grep -avF ' hdr=Return-path: ' | \
   grep -av '.* hdr=[[:print:][:space:]]*$'
(runtime for ~6M mails on our servers was 20-30min)
 
This can be even more optimized if you have a powerful storage system 
with GNU parallel:
> doveadm user '*' | parallel "doveadm -f flow fetch -u '{}' 'user guid mailbox uid seq flags hdr' all | grep -a '^user=' | grep -avF ' hdr=Return-path: ' | grep -av '.* hdr=[[:print:][:space:]]*$' || true"
(runtime for ~6M mails on our servers was ~4min)
 
The command will give you a list of mails that possibly are affected, 
check the full output of
 
doveadm fetch -u USERNAME hdr guid GUID | less
 
to verify that the header is really broken.
 
On our systems I found 39 mails within ~12M mails.
 
I was able to recover these mails "manually" by reconstructing the 
Return-Path header line, importing the fixed mails and expunging the 
corrupt ones. Before importing, I had to disable zlib_save option obviously.
 
Best regards,
-- 
Patrick Cernko <pcernko at mpi-klsb.mpg.de> +49 681 9325 5815
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme
-------------- next part --------------
# 2.3.6.1 (d124cc84b): /etc/dovecot/dovecot.conf
# OS: Linux 4.14.127.1.amd64-smp x86_64 Debian 9.9 
# Hostname: adove.mpi-klsb.mpg.de
listen = *
mail_attachment_dir = /var/vmail/attachments
mail_attachment_fs = posix
mail_gid = nogroup
mail_home = /var/vmail/%u
mail_location = mdbox:~/mdbox
mail_plugins = " zlib"
mail_uid = nobody
passdb {
  args = /etc/dovecot/userdb
  driver = passwd-file
}
plugin {
  zlib_save = gz
}
protocols = imap
userdb {
  args = /etc/dovecot/userdb
  driver = passwd-file
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5324 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://dovecot.org/pipermail/dovecot/attachments/20190719/3da620ad/attachment-0001.p7s>

Reply | Threaded
Open this post in threaded view
|

Re: Using attachment_dir with plugin zlib corrupt mails

Dovecot mailing list

at least for me it didn't fix. still see in logs:
        Error: lzma.read(/var/spool/mail/telsch/storage/m.11800): corrupted
data at 110015

before i upgrade from 2.3.4.1 to 2.3.8 + your patch i noticed i can
access the mails with alpine and roundcube but not with thunderbird.

On 10.10.19 11:38, Timo Sirainen via dovecot wrote:

> Can you test if
> https://github.com/dovecot/core/commit/5068b11e594ad7cc1f7cedf2bd9280520e0e534d.patch fixes
> it for you?
>
>> On 10 Oct 2019, at 11.34, MAREN ZUBIZARRETA via dovecot
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Hello:
>>   I have found the same problem reported above by Patrick Cernko
>> affecting our system and corrupting our messages. Even worse, Outlook
>> 2016 will no synchronize and the clients cannot see any message, even
>> if there is only one corrupted mail per mailbox.
>>   I cannot figure out a feasible workaround for our system, and I can
>> see that in new version 2.38 the bug is not fixed.
>> Will this issue be treated soon?
>> Thanks a lot
>>      Maren Zubizarreta
>>
>>
>>   WARNING: using attachment_dir with plugin zlib can corrupt mails
>>
>> *Patrick Cernko*pcernko at mpi-klsb.mpg.de
>> <mailto:dovecot%40dovecot.org?Subject=Re:%20Re%3A%20WARNING%3A%20using%20attachment_dir%20with%20plugin%20zlib%20can%20corrupt%20mails&In-Reply-To=%3C1ab8edcc-bef4-3b41-d09a-c523674a5031%40mpi-klsb.mpg.de%3E>
>> /Fri Jul 19 17:52:37 EEST 2019/
>>
>>   * Previous message: index worker 2.3.7 undefined symbol errors
>>     <https://dovecot.org/list/dovecot/2019-July/116617.html>
>>   * Next message: Address family not supported by protocol
>>     <https://dovecot.org/list/dovecot/2019-July/116571.html>
>>   * *Messages sorted by:*[ date ]
>>     <https://dovecot.org/list/dovecot/2019-July/date.html#116570>[
>>     thread ]
>>     <https://dovecot.org/list/dovecot/2019-July/thread.html#116570>[
>>     subject ]
>>     <https://dovecot.org/list/dovecot/2019-July/subject.html#116570>[
>>     author ]
>>     <https://dovecot.org/list/dovecot/2019-July/author.html#116570>
>>
>> ------------------------------------------------------------------------
>> Hello list, hello Dovecot developers,
>> this week, I discovered a serious bug in Dovecot, that lead to several
>> broken mails on our servers. The bug corrupts the first few characters
>> of the mail header during saving. On our setup, it was almost always
>> only the very first line of text, that was corrupted.
>> Depending on the IMAP client (they seem to request different header
>> fields, ... during mail access), the bug causes the imap process to hang
>> up the TCP connection and log errors like this:
>> >/imap(USERNAME)<4767><TeQP4ASOTK5/AAAB>: Error: Corrupted record in
>> index cache file
>> /IMAP/mail/mailboxes/USERNAME/mdbox/mailboxes/Trash/dbox-Mails/dovecot.index.cache:
>> UID 489113: Broken fields in mailbox Trash:
>> read(attachments-connector(zlib(/IMAP/mail/mailboxes/USERNAME/mdbox/storage/m.813))):
>> FETCH BODY[HEADER.FIELDS (RETURN-PATH SUBJECT)] got too little data: 2
>> vs 122/
>> In our case that finally grabbed my attention, the client was the users
>> iphone that did not display any new messages but his Thunderbird did.
>> The bug seems to be triggered by a bad "interaction" of attachment_dir
>> option and zlib plugin. If you use both, you most likely are affected,
>> too, except you only use zlib plugin for reading previously compressed
>> stored mails. That's also the workaround we use now: zlib plugin only
>> enabled in mail_plugins but no plugin/zlib_save set.
>> The bug occurs on very specific mails. Due to privacy reasons I could
>> not provide sample mails here. Storing such mails seems to trigger the
>> bug reproducible.
>> I attached a very minimal doveconf -n config, that can be used to
>> trigger the bug. If one of the developers is interested, I can try to
>> generate an "anonymized" version of such a specific mail that still
>> causes the issue. I discovered the bug on our productive systems,
>> running latest Dovecot 2.2 release, but the latest 2.3 I used during
>> debugging is affected, too.
>> During debugging, I also found one hint, that might help find the bug:
>> If you store a problematic mail with zlib_save=gz (or zlib_save=bz2) and
>> then disable the zlib plugin in mail_plugins, you can call
>> doveadm fetch -u test hdr all | grep -v ^hdr: | gzip --decompress
>> on test's mailbox with only that one broken mail.
>> This will display the beginning of the rfc822 mail text until gzip
>> terminates with "gzip: stdin: unexpected end of file", approximately
>> after twice the length of the mail HEADER. This might indicate, that
>> dovecot stores the uncompressed size of the header in it's data
>> structures although the mail is stored compressed.
>> I also found a very efficient way to find all affected mails in our setup:
>> doveadm -f flow fetch -A 'user guid mailbox uid seq flags hdr' all | \
>>    grep -a "^[^ ]+ user=" | \
>>    grep -avF ' hdr=Return-path: ' | \
>>    grep -av '.* hdr=[[:print:][:space:]]*$'
>> (runtime for ~6M mails on our servers was 20-30min)
>> This can be even more optimized if you have a powerful storage system
>> with GNU parallel:
>> >/doveadm user '*' | parallel "doveadm -f flow fetch -u '{}' 'user guid
>> mailbox uid seq flags hdr' all | grep -a '^user=' | grep -avF '
>> hdr=Return-path: ' | grep -av '.* hdr=[[:print:][:space:]]*$' || true"/
>> (runtime for ~6M mails on our servers was ~4min)
>> The command will give you a list of mails that possibly are affected,
>> check the full output of
>> doveadm fetch -u USERNAME hdr guid GUID | less
>> to verify that the header is really broken.
>> On our systems I found 39 mails within ~12M mails.
>> I was able to recover these mails "manually" by reconstructing the
>> Return-Path header line, importing the fixed mails and expunging the
>> corrupt ones. Before importing, I had to disable zlib_save option
>> obviously.
>> Best regards,
>> --
>> Patrick Cernko <pcernko at mpi-klsb.mpg.de
>> <https://dovecot.org/mailman/listinfo/dovecot>> +49 681 9325 5815
>> Joint Administration: Information Services and Technology
>> Max-Planck-Institute fuer Informatik & Softwaresysteme
>> -------------- next part --------------
>> # 2.3.6.1 (d124cc84b): /etc/dovecot/dovecot.conf
>> # OS: Linux 4.14.127.1.amd64-smp x86_64 Debian 9.9
>> # Hostname: adove.mpi-klsb.mpg.de <http://adove.mpi-klsb.mpg.de/>
>> listen = *
>> mail_attachment_dir = /var/vmail/attachments
>> mail_attachment_fs = posix
>> mail_gid = nogroup
>> mail_home = /var/vmail/%u
>> mail_location = mdbox:~/mdbox
>> mail_plugins = " zlib"
>> mail_uid = nobody
>> passdb {
>>   args = /etc/dovecot/userdb
>>   driver = passwd-file
>> }
>> plugin {
>>   zlib_save = gz
>> }
>> protocols = imap
>> userdb {
>>   args = /etc/dovecot/userdb
>>   driver = passwd-file
>> }
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: smime.p7s
>> Type: application/pkcs7-signature
>> Size: 5324 bytes
>> Desc: S/MIME Cryptographic Signature
>> URL:
>> <https://dovecot.org/pipermail/dovecot/attachments/20190719/3da620ad/attachment-0001.p7s>
>
Reply | Threaded
Open this post in threaded view
|

Dovecot mangesieve proxy - internal failure

Dovecot mailing list
In reply to this post by Dovecot mailing list
Hello list,

i'm running an internal dovecot instance with working managesieve. But
on my external dovecot-proxy instance i got an internal error. Nothing
logs on internal dovecot.


Nov 06 14:55:12 managesieve-login: Error: proxy: Remote sent invalid
response: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE
IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN AUTH=GSSAPI] Dovecot (Ubuntu)
ready.??: user=<user>, method=PLAIN, rip=remote_ip, lip=local_ip, TLS,
session=</G/K5a2WzMFNDVcl>
Nov 06 14:55:12 managesieve-login: Debug: server.intra.lan: SSL alert:
close notify
Nov 06 14:55:12 managesieve-login: Info: Aborted login (internal
failure, 1 successful auths): user=<user>, method=PLAIN, rip=remote_ip,
lip=local_ip, TLS, session=</G/K5a2WzMFNDVcl>


# 2.3.4.1 (f79e8e7e4): /etc/dovecot-proxy/dovecot-proxy.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 4.15.0-66-generic x86_64 Ubuntu 18.04.3 LTS
# Hostname: server.lan
auth_username_format = %Ln
base_dir = /var/run/dovecot-proxy/
instance_name = dovecot-proxy
listen = <myip>
log_path = /var/log/dovecot/dovecot-proxy.log
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date index ihave duplicate mime foreverypart extracttext
passdb {
   args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
   default_fields = proxy=y host=server.intra.lan port=993 ssl=yes
master=proxy pass=#hidden_use-P_to_show#
   driver = ldap
}
protocols = imap sieve
service auth {
   unix_listener /var/spool/postfix/private/proxy-auth {
     mode = 0666
   }
}
service imap-login {
   inet_listener imap {
     port = 0
   }
   inet_listener imaps {
     port = 993
     ssl = yes
   }
}
ssl = required
ssl_ca = </etc/ssl/mycacert.pem
ssl_cert = </etc/ssl/mycert.pem
ssl_cipher_list = ALL:!SSLv2:!ADH:!LOW:!MEDIUM:!aNULL:!EXP
ssl_dh = # hidden, use -P to show it
ssl_key = # hidden, use -P to show it
ssl_min_protocol = TLSv1.2
ssl_require_crl = no
userdb {
   args = /etc/dovecot-proxy/dovecot-ldap-userdb.conf.ext
   driver = ldap
}
protocol imap {
   mail_max_userip_connections = 20
   ssl_cert = </etc/ssl/letsencrypt.ca-bundle
   ssl_key = # hidden, use -P to show it
}
protocol sieve {
   ssl_cert = </etc/ssl/letsencrypt.ca-bundle
   ssl_key = # hidden, use -P to show it
}
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list

> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
>
>  
> Hello list,
>
> i'm running an internal dovecot instance with working managesieve. But
> on my external dovecot-proxy instance i got an internal error. Nothing
> logs on internal dovecot.
>
>


It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.

Aki
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
If i change it to:

passdb {
   args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
   default_fields = proxy=y host=server.intra.lan port=143 starttls=yes
master=proxy pass=#hidden_use-P_to_show#
   driver = ldap
}

I still got the same error for mangesieve. IMAP login works with both
SSL/STARTTLS.

On 11/6/19 3:19 PM, Aki Tuomi via dovecot wrote:

>
>> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
>>
>>
>> Hello list,
>>
>> i'm running an internal dovecot instance with working managesieve. But
>> on my external dovecot-proxy instance i got an internal error. Nothing
>> logs on internal dovecot.
>>
>>
>
>
> It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.
>
> Aki
>
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
You are hardcoding the port. I'm pretty sure your managesieve is not listening on 143 =)

Aki

> On 06/11/2019 16:46 telsch via dovecot <[hidden email]> wrote:
>
>  
> If i change it to:
>
> passdb {
>    args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
>    default_fields = proxy=y host=server.intra.lan port=143 starttls=yes
> master=proxy pass=#hidden_use-P_to_show#
>    driver = ldap
> }
>
> I still got the same error for mangesieve. IMAP login works with both
> SSL/STARTTLS.
>
> On 11/6/19 3:19 PM, Aki Tuomi via dovecot wrote:
> >
> >> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
> >>
> >>
> >> Hello list,
> >>
> >> i'm running an internal dovecot instance with working managesieve. But
> >> on my external dovecot-proxy instance i got an internal error. Nothing
> >> logs on internal dovecot.
> >>
> >>
> >
> >
> > It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.
> >
> > Aki
> >
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
Also those variables can't be returned from passdb as they are needed pre-auth.

Sami


> On 6 Nov 2019, at 16.51, Aki Tuomi via dovecot <[hidden email]> wrote:
>
> You are hardcoding the port. I'm pretty sure your managesieve is not listening on 143 =)
>
> Aki
>
>> On 06/11/2019 16:46 telsch via dovecot <[hidden email]> wrote:
>>
>>
>> If i change it to:
>>
>> passdb {
>>   args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
>>   default_fields = proxy=y host=server.intra.lan port=143 starttls=yes
>> master=proxy pass=#hidden_use-P_to_show#
>>   driver = ldap
>> }
>>
>> I still got the same error for mangesieve. IMAP login works with both
>> SSL/STARTTLS.
>>
>> On 11/6/19 3:19 PM, Aki Tuomi via dovecot wrote:
>>>
>>>> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
>>>>
>>>>
>>>> Hello list,
>>>>
>>>> i'm running an internal dovecot instance with working managesieve. But
>>>> on my external dovecot-proxy instance i got an internal error. Nothing
>>>> logs on internal dovecot.
>>>>
>>>>
>>>
>>>
>>> It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.
>>>
>>> Aki
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
I need a more detailed hint. Dovecot proxy IMAP is running fine, but how
to add to the same proxy managesieve support?

I thougt it's activated in the proxy:
        protocols = imap sieve

In the passdb proxy to the backends SSL or STARTTLS port successfully
for IMAP. What exactly missing for managesieve?

Thanks!

On 11/6/19 3:52 PM, Sami Ketola via dovecot wrote:

> Also those variables can't be returned from passdb as they are needed pre-auth.
>
> Sami
>
>
>> On 6 Nov 2019, at 16.51, Aki Tuomi via dovecot <[hidden email]> wrote:
>>
>> You are hardcoding the port. I'm pretty sure your managesieve is not listening on 143 =)
>>
>> Aki
>>
>>> On 06/11/2019 16:46 telsch via dovecot <[hidden email]> wrote:
>>>
>>>
>>> If i change it to:
>>>
>>> passdb {
>>>    args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
>>>    default_fields = proxy=y host=server.intra.lan port=143 starttls=yes
>>> master=proxy pass=#hidden_use-P_to_show#
>>>    driver = ldap
>>> }
>>>
>>> I still got the same error for mangesieve. IMAP login works with both
>>> SSL/STARTTLS.
>>>
>>> On 11/6/19 3:19 PM, Aki Tuomi via dovecot wrote:
>>>>
>>>>> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> Hello list,
>>>>>
>>>>> i'm running an internal dovecot instance with working managesieve. But
>>>>> on my external dovecot-proxy instance i got an internal error. Nothing
>>>>> logs on internal dovecot.
>>>>>
>>>>>
>>>>
>>>>
>>>> It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.
>>>>
>>>> Aki
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
As mentioned on earlier email, are you sure you are connecting to port 4190 and not 143 for ManageSieve?

Aki

> On 06/11/2019 17:48 telsch via dovecot <[hidden email]> wrote:
>
>  
> I need a more detailed hint. Dovecot proxy IMAP is running fine, but how
> to add to the same proxy managesieve support?
>
> I thougt it's activated in the proxy:
> protocols = imap sieve
>
> In the passdb proxy to the backends SSL or STARTTLS port successfully
> for IMAP. What exactly missing for managesieve?
>
> Thanks!
>
> On 11/6/19 3:52 PM, Sami Ketola via dovecot wrote:
> > Also those variables can't be returned from passdb as they are needed pre-auth.
> >
> > Sami
> >
> >
> >> On 6 Nov 2019, at 16.51, Aki Tuomi via dovecot <[hidden email]> wrote:
> >>
> >> You are hardcoding the port. I'm pretty sure your managesieve is not listening on 143 =)
> >>
> >> Aki
> >>
> >>> On 06/11/2019 16:46 telsch via dovecot <[hidden email]> wrote:
> >>>
> >>>
> >>> If i change it to:
> >>>
> >>> passdb {
> >>>    args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
> >>>    default_fields = proxy=y host=server.intra.lan port=143 starttls=yes
> >>> master=proxy pass=#hidden_use-P_to_show#
> >>>    driver = ldap
> >>> }
> >>>
> >>> I still got the same error for mangesieve. IMAP login works with both
> >>> SSL/STARTTLS.
> >>>
> >>> On 11/6/19 3:19 PM, Aki Tuomi via dovecot wrote:
> >>>>
> >>>>> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
> >>>>>
> >>>>>
> >>>>> Hello list,
> >>>>>
> >>>>> i'm running an internal dovecot instance with working managesieve. But
> >>>>> on my external dovecot-proxy instance i got an internal error. Nothing
> >>>>> logs on internal dovecot.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.
> >>>>
> >>>> Aki
> >>>>
> >
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
Ah ok thanks, now i got it!

I need to change
        default_fields = proxy=y host=server.intra.lan port=993 ssl=yes
master=proxy pass=#hidden_use-P_to_show#

to
        default_fields = proxy=y host=server.intra.lan starttls=yes
master=proxy pass=#hidden_use-P_to_show#

and enable STARTTLS for IMAP on the backend.

Thanks!


On 11/6/19 5:05 PM, Aki Tuomi via dovecot wrote:

> As mentioned on earlier email, are you sure you are connecting to port 4190 and not 143 for ManageSieve?
>
> Aki
>
>> On 06/11/2019 17:48 telsch via dovecot <[hidden email]> wrote:
>>
>>
>> I need a more detailed hint. Dovecot proxy IMAP is running fine, but how
>> to add to the same proxy managesieve support?
>>
>> I thougt it's activated in the proxy:
>> protocols = imap sieve
>>
>> In the passdb proxy to the backends SSL or STARTTLS port successfully
>> for IMAP. What exactly missing for managesieve?
>>
>> Thanks!
>>
>> On 11/6/19 3:52 PM, Sami Ketola via dovecot wrote:
>>> Also those variables can't be returned from passdb as they are needed pre-auth.
>>>
>>> Sami
>>>
>>>
>>>> On 6 Nov 2019, at 16.51, Aki Tuomi via dovecot <[hidden email]> wrote:
>>>>
>>>> You are hardcoding the port. I'm pretty sure your managesieve is not listening on 143 =)
>>>>
>>>> Aki
>>>>
>>>>> On 06/11/2019 16:46 telsch via dovecot <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> If i change it to:
>>>>>
>>>>> passdb {
>>>>>     args = /etc/dovecot-proxy/dovecot-ldap-passdb.conf.ext
>>>>>     default_fields = proxy=y host=server.intra.lan port=143 starttls=yes
>>>>> master=proxy pass=#hidden_use-P_to_show#
>>>>>     driver = ldap
>>>>> }
>>>>>
>>>>> I still got the same error for mangesieve. IMAP login works with both
>>>>> SSL/STARTTLS.
>>>>>
>>>>> On 11/6/19 3:19 PM, Aki Tuomi via dovecot wrote:
>>>>>>
>>>>>>> On 06/11/2019 16:15 telsch via dovecot <[hidden email]> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hello list,
>>>>>>>
>>>>>>> i'm running an internal dovecot instance with working managesieve. But
>>>>>>> on my external dovecot-proxy instance i got an internal error. Nothing
>>>>>>> logs on internal dovecot.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> It seems you are trying to connect to STARTTLS port using SSL. You should probably tell in your passdb that the connection needs to use STARTTLS security, or configure the backend listener with ssl=yes.
>>>>>>
>>>>>> Aki
>>>>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Dovecot mangesieve proxy - internal failure

Dovecot mailing list
telsch via dovecot skrev den 2019-11-06 17:49:

> Ah ok thanks, now i got it!
>
> I need to change
> default_fields = proxy=y host=server.intra.lan port=993 ssl=yes
> master=proxy pass=#hidden_use-P_to_show#
>
> to
> default_fields = proxy=y host=server.intra.lan starttls=yes
> master=proxy pass=#hidden_use-P_to_show#
>
> and enable STARTTLS for IMAP on the backend.

imap is not yet managesieve port 4190

port 4190 needs also starttls imho

sorry if i did not know that default_fields is reused for all ports of
dovecot