- dovecot - dovecot.org

Re: [Dovecot] SSL only for external connections
by Michael M Slusarz 30 Sep '11

30 Sep '11

Quoting Simon Brereton <simon.brereton(a)buongiorno.com>: > But the question remains - if only because it's now there - how does > one limit services effectively in Dovecot. In Courier it was fairly > easy and well documented. There's no reason for me to offer IMAPS > or POP3S to localhost (because of the certificate issue) and there's > also no reason for me to offer POP3 to localhost either. > > For posterity and for my own edification it would be nice to know > how to do that. At a minimum, you can't disable TLS. If you disable TLS support in dovecot, the server is no longer IMAP 4rev1 compliant (see RFC 3501 [6.1.1] - STARTTLS MUST be supported by server). michael

1 0

[Dovecot] SSL only for external connections
by Terry Carmen 30 Sep '11

30 Sep '11

If SSL/TLS works from the outside, but not the inside, you should probably find out why and fix that instead. What is the actual error text? Terry -- Terry Carmen CNY Support, LLC https://www.cnysupport.com

3 3

Re: [Dovecot] SSL only for external connections
by Stan Hoeppner 30 Sep '11

30 Sep '11

On 9/30/2011 12:34 PM, Simon Brereton wrote: >> -----Original Message----- >> From: dovecot-bounces(a)dovecot.org [mailto:dovecot- >> bounces(a)dovecot.org] On Behalf Of Terry Carmen > >> >> If SSL/TLS works from the outside, but not the inside, you should >> probably find out why and fix that instead. > > You'd think so - but since I don't actually need TLS from the inside, and given my skill level - disabling it seems easier :) You don't need TLS/SSL from the outside either, if this is strictly a webmail box. In this case, configure Apache/lighttpd+Horde to only accept HTTPS connections from the outside, and configure Horde to connect via the Dovecot localhost:143 listener. This is how I've been doing it with Roundcube for years. Works like a champ. With encrypted sessions between browser and web server, and both Horde and Dovecot running on the same host, you don't need to, nor want to, use IMAPS. -- Stan

2 1

[Dovecot] SSL only for external connections
by Simon Brereton 30 Sep '11

30 Sep '11

Hi I'm running dovecot 1:1.2.15-7 and php webmail application is throwing errors when connecting to IMAP with TLS. Is there away to disable SSL/TLS for localhost connections? I googled, but didn't see anything specific. Can I assume that it's as simple as setting ssl_listen = to the external IP address(es) and leaving listen = * as it is? Thanks. Simon

1 0

[Dovecot] Panic: file lmtp-proxy.c: line 370 (lmtp_proxy_output_timeout): assertion failed: (proxy->data_input->eof)
by mailing lists 30 Sep '11

30 Sep '11

Hello all, today I got this crash from dovecot (2.0.14) Sep 29 14:09:32 imap1 dovecot: lmtp(17693): Panic: file lmtp-proxy.c: line 370 (lmtp_proxy_output_timeout): assertion failed: (proxy->data_input->eof) Sep 29 14:09:32 imap1 dovecot: lmtp(17693): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0(+0x3f9aa) [0x7f18f10299aa] -> /usr/lib64/dovecot/libdovecot.so.0(+0x3f9f6) [0x7f18f10299f6] -> /usr/lib64/dovecot/libdovecot.so.0(i_fatal+0) [0x7f18f1003211] -> dovecot/lmtp(+0x7a4f) [0x7f18f1982a4f] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handle_timeouts+0xcb) [0x7f18f103590b] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x5b) [0x7f18f103680b] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x28) [0x7f18f1035768] -> /usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f18f1023423] -> dovecot/lmtp(main+0x183) [0x7f18f197fa93] -> /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f18f0ca8b7d] -> dovecot/lmtp(+0x4819) [0x7f18f197f819] Sep 29 14:09:32 imap1 dovecot: master: Error: service(lmtp): child 17693 killed with signal 6 (core dumps disabled) /-----------------/ # dovecot -n -c /etc/dovecot-director/dovecot.conf # 2.0.14: /etc/dovecot-director/dovecot.conf # OS: Linux 2.6.34.7-0.7-xen x86_64 openSUSE 11.3 (x86_64) auth_debug = yes auth_verbose = yes base_dir = /var/run/dovecot-director/ director_mail_servers = 100.1.245.101 100.1.245.105 director_servers = 100.1.245.101:9091 100.1.245.105:9091 100.1.241.204:9091 disable_plaintext_auth = no doveadm_proxy_port = 24245 lmtp_proxy = yes mail_debug = yes mail_fsync = always mail_gid = 5000 mail_nfs_index = yes mail_nfs_storage = yes mail_plugins = acl mail_uid = 5000 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 mmap_disable = yes passdb { args = proxy=y nopassword=y driver = static } plugin { acl = vfile sieve = ~/.dovecot.sieve sieve_dir = ~/sieve } protocols = imap lmtp pop3 service auth { unix_listener auth-userdb { group = vmail mode = 0666 user = vmail } } service director { fifo_listener login/proxy-notify { mode = 0666 } inet_listener { port = 9091 } unix_listener director-userdb { mode = 0666 } unix_listener login/director { mode = 0666 } } service doveadm { inet_listener { port = 24245 } } service imap-login { executable = imap-login director inet_listener imap { port = 10143 } } service lmtp { inet_listener lmtp { port = 1024 } } service pop3-login { executable = pop3-login director inet_listener pop3 { port = 10110 } } ssl = no verbose_proctitle = yes protocol lmtp { auth_socket_path = director-userdb passdb { args = proxy=y nopassword=y port=24 driver = static } } protocol imap { mail_max_userip_connections = 100 } local 100.1.245.101/28/28 { doveadm_password = secret }

2 1

[Dovecot] Error message in log
by Knute Johnson 30 Sep '11

30 Sep '11

I'm getting the following message in my log; dovecot: IMAP(knute): fchown(/home/knute/mail/.imap/INBOX/dovecot.index.cache.lock, -1, 8(mail)) failed: Operation not permitted (egid=1000(knute), group based on /var/mail/knute): 1 Time(s) dovecot: IMAP(knute): fchown(/home/knute/mail/.imap/INBOX/dovecot.index.log.newlock, -1, 8(mail)) failed: Operation not permitted (egid=1000(knute), group based on /var/mail/knute): 2 Time(s) dovecot: IMAP(knute): fchown(/home/knute/mail/.imap/INBOX/dovecot.index.tmp, -1, 8(mail)) failed: Operation not permitted (egid=1000(knute), group based on /var/mail/knute): 4 Time(s) I got these once before on the /var/mail/user files and changed the permissions to 600. /home/knute/mail/.imap/INBOX is 770 and the index files are 600. Is this a problem with the directory privilege? Thanks, -- Knute Johnson knute2011(a)knutejohnson.com

1 0

[Dovecot] Broken mail clients? [MIME] Long attachment encoded filenames (for non-ASCII characters etc)
by Andrew Richards 30 Sep '11

30 Sep '11

Hi, I've noticed a possible minor issue with long encoded filenames for attachments where these filenames are split across multiple lines. My understanding of character encoding and MIME is not as good as it should be, so I may easily have got this all mixed up, in which case sorry for the noise... Although I understand the preferred method for handling filenames split across multiple lines (because they're too long to fit on one line in the message) is that suggested in RFC2184/2231, so for example, filename*0*=iso-8859-1''accented_characters_here_%EA%CA%E6 filename*1=etc%2Epdf I find that some mail clients do this instead, filename="=?ISO-8859-1?Q?accented_characters_here_=EA=CA=E6?= =?ISO-8859-1?Q?etc=2Epdf?=" In Dovecot this results in, 0 fetch 25 body * 25 FETCH (BODY (("text" "plain" ("charset" "ISO-8859-1") NIL NIL "7bit" 239 8)("application" "pdf" ("name" "=?ISO-8859-1?Q?accented_characters_here_=EA=CA=E6?= =?ISO-8859-1?Q?etc=2Epdf?=") NIL NIL "base64" 219130) "mixed")) esp. note the unwanted space - or in fact the sequence ?= =? between the two sections of the filename. I think a possible tweak for Dovecot would be to combine the filename parts in this situation to remove the ?= =?. I'm not sure if an IMAP client should know to combine the parts in their current format. FWIW I see that Courier does the same as Dovecot in this situation. I think the 'alternative' method of splitting filenames I'm raising breaks RFC2047 (details below), but unfortunately this method is used by some large email generators like gmail - also details below. Key bits from RFC2047 section 5 part (3) re. only a single encoded-word ('phrase') being allowed for a MIME Content-Type / Content-Disposition: phrase = 1*( encoded-word / word ) An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. Here are the mail clients I noted this issue with (original filenames destroyed because I've been examining my client's emails for this issue - with their permission), (AOL) X-Mailer: Webmail 33953-STANDARD Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?Q?abcde?= =?utf-8?Q?abcde=C3=A9abcde.jpg?=" Content-Type: image/jpeg; name="=?utf-8?Q?abcde?= =?utf-8?Q?abcde=C3=A9abcde.jpg?=" Gmail: Content-Type: application/pdf; name="=?ISO-8859-1?Q?with_a_=EA=CA=E6_super=2Dlong_name_that=27s_bound?= =?ISO-8859-1?Q?_to_overflow_a_line_boundary_to_test_gmail=2Epdf?=" Content-Disposition: attachment; filename="=?ISO-8859-1?Q?with_a_=EA=CA=E6_super=2Dlong_name_that=27s_bound?= =?ISO-8859-1?Q?_to_overflow_a_line_boundary_to_test_gmail=2Epdf?=" X-Mailer: YahooMailWebService/0.8.113.313619 Content-Type: application/vnd.openxmlformats- officedocument.wordprocessingml.document; name="=?utf-8?B?base64encodedstring?= =?utf-8?B?base64encodedstring?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?base64encodedstring?= =?utf-8?B?base64encodedstring?=" X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005: Content-type: application/pdf; name="=?ISO-8859-1?Q?abcde=E9abcde=E9abcde=E9?= =?ISO-8859-1?Q?abcde=2Cl=2Epdf?=" Content-Disposition: attachment; filename="=?ISO-8859-1?Q?abcde=E9abcde=E9_abcde=E9?= =?ISO-8859-1?Q?abcde=2Cl=2Epdf?=" Content-ID: <20__=snip> Content-transfer-encoding: base64 X-Mailer: Lotus Domino Web Server Release 6.5.5FP1 HF551 November 27, 2007: Content-type: application/pdf; name="=?windows-1252?Q?abcde_=28=E9?= =?windows-1252?Q?=29=2Epdf?=" Content-Disposition: attachment; filename="=?windows-1252?Q?abcde_=28=E9?= =?windows-1252?Q?=29=2Epdf?=" Content-transfer-encoding: base64 Timo also noted the same style of filename encoding in Apple Mail in the previous thread I started, it would be interesting to try Apple Mail with a very long filename to cause it to split across multiple lines and see how it encodes the filename then, > Looks like Apple Mail also sends: > > Content-Type: application/octet-stream; > > name="=?iso-8859-1?Q?p=E4=E4?=" Best regards, Andrew.

2 2

[Dovecot] Long attachment encoded filenames (for non-ASCII characters etc) in MIME headers & corresponding Dovecot behaviour
by Andrew Richards 30 Sep '11

30 Sep '11

(Correction: Subject was confused) Hi, I've noticed a possible minor issue with long encoded filenames for attachments where these filenames are split across multiple lines. My understanding of character encoding and MIME is not as good as it should be, so I may easily have got this all mixed up, in which case sorry for the noise... Although I understand the preferred method for handling filenames split across multiple lines (because they're too long to fit on one line in the message) is that suggested in RFC2184/2231, so for example, filename*0*=iso-8859-1''accented_characters_here_%EA%CA%E6 filename*1=etc%2Epdf I find that some mail clients do this instead, filename="=?ISO-8859-1?Q?accented_characters_here_=EA=CA=E6?= =?ISO-8859-1?Q?etc=2Epdf?=" In Dovecot this results in, 0 fetch 25 body * 25 FETCH (BODY (("text" "plain" ("charset" "ISO-8859-1") NIL NIL "7bit" 239 8)("application" "pdf" ("name" "=?ISO-8859-1?Q?accented_characters_here_=EA=CA=E6?= =?ISO-8859-1?Q?etc=2Epdf?=") NIL NIL "base64" 219130) "mixed")) esp. note the unwanted space - or in fact the sequence ?= =? between the two sections of the filename. I think a possible tweak for Dovecot would be to combine the filename parts in this situation to remove the ?= =?. I'm not sure if an IMAP client should know to combine the parts in their current format. FWIW I see that Courier does the same as Dovecot in this situation. I think the 'alternative' method of splitting filenames I'm raising breaks RFC2047 (details below), but unfortunately this method is used by some large email generators like gmail - also details below. Key bits from RFC2047 section 5 part (3) re. only a single encoded-word ('phrase') being allowed for a MIME Content-Type / Content-Disposition: phrase = 1*( encoded-word / word ) An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. Here are the mail clients I noted this issue with (original filenames destroyed because I've been examining my client's emails for this issue - with their permission), (AOL) X-Mailer: Webmail 33953-STANDARD Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?Q?abcde?= =?utf-8?Q?abcde=C3=A9abcde.jpg?=" Content-Type: image/jpeg; name="=?utf-8?Q?abcde?= =?utf-8?Q?abcde=C3=A9abcde.jpg?=" Gmail: Content-Type: application/pdf; name="=?ISO-8859-1?Q?with_a_=EA=CA=E6_super=2Dlong_name_that=27s_bound?= =?ISO-8859-1?Q?_to_overflow_a_line_boundary_to_test_gmail=2Epdf?=" Content-Disposition: attachment; filename="=?ISO-8859-1?Q?with_a_=EA=CA=E6_super=2Dlong_name_that=27s_bound?= =?ISO-8859-1?Q?_to_overflow_a_line_boundary_to_test_gmail=2Epdf?=" X-Mailer: YahooMailWebService/0.8.113.313619 Content-Type: application/vnd.openxmlformats- officedocument.wordprocessingml.document; name="=?utf-8?B?base64encodedstring?= =?utf-8?B?base64encodedstring?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?base64encodedstring?= =?utf-8?B?base64encodedstring?=" X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005: Content-type: application/pdf; name="=?ISO-8859-1?Q?abcde=E9abcde=E9abcde=E9?= =?ISO-8859-1?Q?abcde=2Cl=2Epdf?=" Content-Disposition: attachment; filename="=?ISO-8859-1?Q?abcde=E9abcde=E9_abcde=E9?= =?ISO-8859-1?Q?abcde=2Cl=2Epdf?=" Content-ID: <20__=snip> Content-transfer-encoding: base64 X-Mailer: Lotus Domino Web Server Release 6.5.5FP1 HF551 November 27, 2007: Content-type: application/pdf; name="=?windows-1252?Q?abcde_=28=E9?= =?windows-1252?Q?=29=2Epdf?=" Content-Disposition: attachment; filename="=?windows-1252?Q?abcde_=28=E9?= =?windows-1252?Q?=29=2Epdf?=" Content-transfer-encoding: base64 Timo also noted the same style of filename encoding in Apple Mail in the previous thread I started, it would be interesting to try Apple Mail with a very long filename to cause it to split across multiple lines and see how it encodes the filename then, > Looks like Apple Mail also sends: > > Content-Type: application/octet-stream; > > name="=?iso-8859-1?Q?p=E4=E4?=" Best regards, Andrew.

1 0

[Dovecot] Dovecot failing to parse some UTF-8 encoded attachment filenames, returning empty string instead
by Andrew Richards 30 Sep '11

30 Sep '11

Hi, I'm seeing a strange problem with some attachment filenames that are UTF-8 encoded. The problem seems to be related to spaces and/or unusual characters in filenames, like accented characters (or perhaps just to filenames if UTF-8 encoded; I've not explored that fully). These filenames are shown as empty strings in IMAP using Dovecot. I've attached a sample message that exhibits this problem, trimmed down to fairly bare essentials. By comparison I find that (for example) Courier happily returns the filename (still encoded). Although I suspect the problem lies within Dovecot, it may be an underlying Unicode or other component that's at the root of the problem. I can replicate this by putting the attached message in a mailbox (I'm using Maildir format mailboxes, so I just drop the raw file in Maildir/new and change the ownership of the file to match the mailbox owner). Then a pretend IMAP session to show the problem, $ telnet localhost 143 Trying ::1... Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready. 0 login some.one(a)test.domain password 0 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] Logged in 0 select inbox * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 4 EXISTS * 0 RECENT * OK [UNSEEN 1] First unseen. * OK [UIDVALIDITY 1316621730] UIDs valid * OK [UIDNEXT 8] Predicted next UID * OK [HIGHESTMODSEQ 1] Highest 0 OK [READ-WRITE] Select completed. 0 fetch 4 body * 4 FETCH (BODY (("text" "html" ("charset" "iso-8859-15") NIL NIL "base64" 278 5)("application" "octet-stream" ("name" "") NIL NIL "base64" 18) "mixed")) 0 OK Fetch completed. 0 logout * BYE Logging out 0 OK Logout completed. Connection closed by foreign host. $ especially note the ("name" "") part showing a supposedly empty filename. I've observed this behaviour on the following versions of Dovecot, - 1.2.9 on Ubuntu 10.04LTS (pre-compiled version) - 1.2.17 on Fedora 13 (pre-compiled version) - 2.0.15 on Fedora 13 (from source) I don't think the Dovecot configuration is relevant, but I've put it below for good measure for the 2.0.15 setup. Any ideas on what might be causing this? Best regards, Andrew. # dovecot -n # 2.0.15: /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.34.9-69.fc13.i686.PAE i686 Fedora release 13 (Goddard) auth_debug = yes default_login_user = nobody log_path = /var/log/dovecot.log passdb { args = /usr/local/bin/checkcdb driver = checkpassword } protocols = imap pop3 service auth { user = root } service imap-login { inet_listener imap { ssl = no } } service pop3-login { inet_listener pop3 { ssl = no } } ssl = no userdb { driver = prefetch }

2 4

[Dovecot] Virtual Folder configuration problem. [FIXED]
by Terry Carmen 29 Sep '11

29 Sep '11

Well, it took a ton of time and research, but I finally have a working Unread virtual mailbox on Dovecot 2.x on Centos 6.0. I have no idea if it's optimal or correct, but it works perfectly and doesn't raise any errors or warnings. Here's what I ended up with: dovecot.conf: Add the following: mail_plugins = $mail_plugins virtual namespace { type = private prefix = virtual. separator = . location = virtual:~/Maildir/virtual } 10-mail.conf: Add the following: # default namespace namespace { separator = . prefix = inbox = yes } 20-imap.conf: Add the following: protocol imap { mail_plugins = $mail_plugins virtual } 15-lda.conf: Add the following: protocol lda { mail_plugins = $mail_plugins virtual } Restart dovecot. Reload your mail client. Dovecot will create ~/Maildir/virtual cd ~/Maildir/virtual mkdir Unread Use your favorite editor and create a file named "dovecot-virtual" contaiing: # ~/Maildir/virtual/unseen/dovecot-virtual INBOX INBOX.* -INBOX.Trash unseen Save the file and restart your mail client. Go to "Subscriptions" in your mail client and subscribe to the Unseen folder. You should now have a virtual folder that contains all your unread mail, except for the contents of the Trash folder. Enjoy! -- Terry Carmen CNY Support, LLC https://www.cnysupport.com

1 0