Re: Patch: acl list from ldap must be possible to have multiple values, that combined in one comma separated list
On 23.08.2017 09:45, DaLiV wrote: > diff to dovecot-2.2.31 > hardcoded userdb_acl_groups /as currently not seeing any other fields that > need similar way/ > in ldap using dynlist - labeledURIObject - some attribute > labeledURI :: > ldap:///ou=DovecotGroups,dc=DOMAIN,dc=TLD,dc=root?specName?sub?(&(objectclass=posixgroup)(memberuid=X)) > that returns groupnames for each user that he belongs, but as multiple > values of same field ... must combine all in one CSV list > > > diff -upbBr src/auth/passdb-ldap.c src/auth/passdb-ldap.c > --- src/auth/passdb-ldap.c 2017-06-26 13:29:36.0 +0200 > +++ src/auth/passdb-ldap.c 2017-08-22 09:56:59.697420441 +0200 > @@ -52,13 +52,27 @@ ldap_query_save_result(struct ldap_conne > auth_request_set_null_field(auth_request, name); > continue; > } > + if (strcmp(name,"userdb_acl_groups")==0) { > + int i = 1; > + while (values[i] != NULL) { > + strcat(values[0],","); > + strcat(values[0],values[i]); > + i++; > + } > + auth_request_log_warning(auth_request,AUTH_SUBSYS_DB, > + "Multiple values found for '%s', " > + "using combined value '%s'", name, > values[0]); > + auth_request_set_field(auth_request, name, values[0], > + conn->set.default_pass_scheme); > + } else { > if (values[1] != NULL) { > auth_request_log_warning(auth_request, > AUTH_SUBSYS_DB, >"Multiple values found for '%s', " > "using value '%s'", name, values[0]); > } > auth_request_set_field(auth_request, name, values[0], >conn->set.default_pass_scheme); > } > + } > db_ldap_result_iterate_deinit(&ldap_iter); > } Can you please open this as a pull request on https://github.com/dovecot/core ? Aki Tuomi Dovecot OY
Patch: acl list from ldap must be possible to have multiple values, that combined in one comma separated list
diff to dovecot-2.2.31 hardcoded userdb_acl_groups /as currently not seeing any other fields that need similar way/ in ldap using dynlist - labeledURIObject - some attribute labeledURI :: ldap:///ou=DovecotGroups,dc=DOMAIN,dc=TLD,dc=root?specName?sub?(&(objectclass=posixgroup)(memberuid=X)) that returns groupnames for each user that he belongs, but as multiple values of same field ... must combine all in one CSV list diff -upbBr src/auth/passdb-ldap.c src/auth/passdb-ldap.c --- src/auth/passdb-ldap.c 2017-06-26 13:29:36.0 +0200 +++ src/auth/passdb-ldap.c 2017-08-22 09:56:59.697420441 +0200 @@ -52,13 +52,27 @@ ldap_query_save_result(struct ldap_conne auth_request_set_null_field(auth_request, name); continue; } + if (strcmp(name,"userdb_acl_groups")==0) { + int i = 1; + while (values[i] != NULL) { + strcat(values[0],","); + strcat(values[0],values[i]); + i++; + } + auth_request_log_warning(auth_request,AUTH_SUBSYS_DB, + "Multiple values found for '%s', " + "using combined value '%s'", name, values[0]); + auth_request_set_field(auth_request, name, values[0], + conn->set.default_pass_scheme); + } else { if (values[1] != NULL) { auth_request_log_warning(auth_request, AUTH_SUBSYS_DB, "Multiple values found for '%s', " "using value '%s'", name, values[0]); } auth_request_set_field(auth_request, name, values[0], conn->set.default_pass_scheme); } + } db_ldap_result_iterate_deinit(&ldap_iter); }
Re: user data transfer when migrating to new server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 23 Aug 2017, voy...@sbt.net.au wrote: I;m setting up new server, what are the options for transferring user's mail ? do you change the mail storage backend? If not, rsync all the mailbox 1:1 to the new server, including all auxiliary file of Dovecot. I've tried imapsync, that seems to work well, but, what options do I have for doing accounts or domains where I don't know user's password ? last time I've done, some users had lengthy period of re downloading 'old' mails from new server, is there a way to overcome this ? Prevent the login to the old server while the files are copied to the new server. If you use POP, ensure you have the same UID format. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBWZ0dMHz1H7kL/d9rAQLwhgf/eUpf8C4fVPQBrcQ97hVLqvvX3A2/xLHC UPfHCCIVZW9oMVjyqE8hCLIxknxpRywwEps4VVlvYzn5CQV2/4883Y9O4WzltyBN WtowDknEZng68d2+yJs8pe5r0VgH2KCvGh0M0Y7tuSCm51ljM+vVBSPsP6TO5AFH oRTymjufbfAy7yofMk8qrUX43gmhzh1VtFIFYALQ2m4eW07eMLc+3zwD4TZMH7HB MFVT9sL8IWfJ1erp9xckqs5zXs3tamJqQjYoVXNwPMVY4j1tWiHJoyhK103AeGnV B90jMwc0tRoytKTq7cdHjAC29nOmnGBPIeDxI1wGvqJYEZcbAyh65A== =QGnw -END PGP SIGNATURE-
Re: v2.2.32 release candidate 2 released
On 23.08.2017 03:17, Marcus Rueckert wrote: > On 2017-08-22 21:50:52 +0200, Arkadiusz Miśkiewicz wrote: >>> A couple of changes since rc1: >>> >>> + Added apparmor plugin. See https://wiki2.dovecot.org/Plugins/Apparmor >> Oh so no way to set separate hat for each user? (based on sql query for >> example etc) > have your userdb query return an apparmor_hat column. > I think dict lookups can be used as well? > > HTH > > darix > Hi! I've updated the wiki documentation to reflect various configuration modes. Aki
Re: pop 110/995, imap 143/993 ?
On 23/08/17 11:13, Joseph Tam wrote: > You don't need plaintext to use CRAM-MD5: there's no problem have *both* > CRAM-MD5 and SSL (it's overkill, but works). And mail data is worth > protecting too. The problem is, as I already pointed out, that using CRAM-MD5 or any other form of challenge-response password mechanism requires that the password be stored on the server in plain text. Furthermore just the advertisement of CRAM-MD5 in a response advertises to an attacker that you do indeed store the passwords as plain text. I would much rather store the password as a hash on the server and only offer up the PLAIN and LOGIN types on an encrypted connection. > No argument here about using end-to-end encryption, but protecting mail > data and metadata is important too. Don't forget also, it's not just > about the privacy (reading) of mail data, but it's also important to > guarantee the authenticity of mail data from tampering. Right, the most common means of doing that is to properly authenticate to the submission server and check TLS validity, then the submission server DKIM signs the message. Of course, this implies trust of the submission server. > By the way, if we assume a hostile network where MITM is possible, then > even closing STARTTLS ports will not guarantee confidential transport: > the MITM attacker can merely open up a fake plaintext-only service port, > then proxy that to the target server. The client must deny non-secured > transport to be fully protected. Yes, exactly! If the client accepts a non-secure connection then it doesn't matter what the server does. It's the client that must be vigilant here. That said, a client that is configured to port 465 would require a config change in order to accept a plaintext connection, but then so would a client that is configured to port 587 and mandatory encryption. Peter
Re: v2.2.32 release candidate 2 released
On 2017-08-22 21:50:52 +0200, Arkadiusz Miśkiewicz wrote: > > A couple of changes since rc1: > > > > + Added apparmor plugin. See https://wiki2.dovecot.org/Plugins/Apparmor > > Oh so no way to set separate hat for each user? (based on sql query for > example etc) have your userdb query return an apparmor_hat column. I think dict lookups can be used as well? HTH darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Re: pop 110/995, imap 143/993 ?
Robert Wolf wrote: else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you have enabled something like cram-md5. Hi, exactly, this is the reason, why plain-text is still needed. You don't need encryption for authentication, if you have secure authentication. Without knowing original password, the MITM cannot generate correct hash for login, so the connection can be plain-text. You don't need plaintext to use CRAM-MD5: there's no problem have *both* CRAM-MD5 and SSL (it's overkill, but works). And mail data is worth protecting too. Of cource, if you then download your emails, the MITM can still read these emails too, if these emails are plain-text (not encrypted using e.g. SMIME or GPG). But he cannot misuse your login. No argument here about using end-to-end encryption, but protecting mail data and metadata is important too. Don't forget also, it's not just about the privacy (reading) of mail data, but it's also important to guarantee the authenticity of mail data from tampering. By the way, if we assume a hostile network where MITM is possible, then even closing STARTTLS ports will not guarantee confidential transport: the MITM attacker can merely open up a fake plaintext-only service port, then proxy that to the target server. The client must deny non-secured transport to be fully protected. Joseph Tam
Re: user data transfer when migrating to new server
Hi, I did with imapsync for one server but I had all the login / passwords. The following I did with rsync transfer from one server to another, but the mails where stored in files. Can't tell if you use any other method of mail storage. And if someone knows a trick about not redownloading the emails I'd also like to know. Cheers, Cedric 2017-08-22 16:57 GMT-04:00 : > I;m setting up new server, what are the options for transferring user's > mail ? > > I've tried imapsync, that seems to work well, but, what options do I have > for doing accounts or domains where I don't know user's password ? > > last time I've done, some users had lengthy period of re downloading 'old' > mails from new server, is there a way to overcome this ? > > thanks, V >
user data transfer when migrating to new server
I;m setting up new server, what are the options for transferring user's mail ? I've tried imapsync, that seems to work well, but, what options do I have for doing accounts or domains where I don't know user's password ? last time I've done, some users had lengthy period of re downloading 'old' mails from new server, is there a way to overcome this ? thanks, V
Re: pop 110/995, imap 143/993 ?
On 22/08/17 20:07, Robert Wolf wrote: > On Tue, 22 Aug 2017, Aki Tuomi wrote: > >> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you >> have enabled something like cram-md5. > > exactly, this is the reason, why plain-text is still needed. You don't need > encryption for authentication, if you have secure authentication. Without > knowing original password, the MITM cannot generate correct hash for login, > so > the connection can be plain-text. In order to support non plain-text login types the passwords themselves have to be stored in plain-text. If you use PLAIN but only allow authentication over a secure channel then you get the best of both worlds, you can store your passwords as a hash and they are not transmitted as plain text over the internet. Peter
Re: pop 110/995, imap 143/993 ?
On 22/08/17 18:24, Aki Tuomi wrote: > Dovecot, by default, requires STARTTLS before accepting plaintext > authentication when SSL is configured and you are not connecting from > localhost. You can verify this by telnetting to port 143 from somewhere > else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you > have enabled something like cram-md5. > > I think postfix, by default, will also prevent authentication without > transport security. No: $ postconf -d smtpd_tls_auth_only smtpd_tls_auth_only = no The commented submission service in master.cf contains it, though, so if you uncomment the service as a whole it will be set: # -o smtpd_tls_auth_only=yes > Also, you should probably using 587/tcp (submission) for sending mail, > instead of 25. Some reputable ISPs prevent connecting to random MX > servers to port 25 to make life harder for spambots. Right, you should never use port 25 for submission, for several reasons. Peter
Re: v2.2.32 release candidate 2 released
On Tuesday 22 of August 2017, Timo Sirainen wrote: > https://dovecot.org/releases/2.2/rc/dovecot-2.2.32.rc2.tar.gz > https://dovecot.org/releases/2.2/rc/dovecot-2.2.32.rc2.tar.gz.sig > > A couple of changes since rc1: > > + Added apparmor plugin. See https://wiki2.dovecot.org/Plugins/Apparmor Oh so no way to set separate hat for each user? (based on sql query for example etc) -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
unexpected delivery location
Hi, We're running dovecot 2.2.13, virtual users, with postfix. We have an olddomain and a new domainname. To 'translate' *@olddomain into *@newdomain, I have configured: cat /etc/postfix/canonical @olddomain.com @newdomain.com While this seems to work, lately we have noticed that dovecot occasionally creates mailboxes for non-existent users, like: /var/vmail/...username /var/vmail/20username This only seems to be happening for mails sent to *olddomain* Looking at the source of these mails, they are indeed sent to 20usern...@olddomain.com and ...usern...@olddomain.com Mail headers sample: Delivered-To: 20usern...@newdomain.com Received: from server1.newdomain.com (server2.newdomain.com [x.y.z.q]) by server3.newdomain.com (Postfix) with ESMTPS id 067B4812CF29E for <20usern...@olddomain.com>; Thu, 13 Jul 2017 19:05:02 +0200 (CEST) Why doesn't the emailadress 20usern...@newdomain.com in the above generate an error, but instead are delivered to a newly created mailbox? My feeling is that something is wrong with the way I created the alias for olddomain -> newdomain with the canonical-file . Does that make sense? Our goal is to accept *@olddomain.com like it was sent to *@newdomain.com, including delivery failures for nonexistent mailboxes like 20username We configured postfix like: canonical_maps = hash:/etc/postfix/canonical virtual_alias_maps = ldap:/etc/postfix/ad-mailboxes.cf, ldap:/etc/postfix/ad-groups.cf virtual_uid_maps = static:5000 virtual_gid_maps = static:5000 virtual_transport = dovecot Verified that this config works for newdomain, using: root@mail:/etc/postfix# postmap -q al...@newdomain.com ldap:/etc/postfix/ad-mailboxes.cf use...@newdomain.com root@mail:/etc/postfix# postmap -q al...@olddomain.com ldap:/etc/postfix/ad-mailboxes.cf root@mail:/etc/postfix# olddomain gives no result. Then, from master.cf: dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -a ${recipient} -d ${user}@${nexthop} Finally, the mail location as defined in dovecot: mail_location = maildir:/var/vmail/%Ln/Maildir:LAYOUT=fs:DIRNAME=mAildir So, can anyone explain why for mails to olddomain, dovecot creates new mailboxes, instead of simply generating an error?
Error: mdbox .../storage: Duplicate GUID
Hi! When I force-resync a mailbox of mine, I see following output: # doveadm force-resync -u $USER $PATH doveadm($USER): Warning: mdbox .../storage: Inconsistency in map index ($X,$Y2 != $X,$Y2) doveadm($USER): Warning: fscking index file .../storage/dovecot.map.index doveadm($USER): Warning: mdbox .../storage: rebuilding indexes doveadm($USER): Error: mdbox .../storage: Duplicate GUID $G in m.$N1:$N2 (size=$N3) and m.$N1:$N2 (size=$N3) doveadm($USER): Warning: fscking index file .../storage/dovecot.map.index doveadm($USER): Warning: mdbox .../storage: Inconsistency in map index ($X,$Y1 != $X,$Y3) doveadm($USER): Warning: fscking index file .../storage/dovecot.map.index doveadm($USER): Warning: fscking index file .../storage/dovecot.map.index Different numbers are represented by different $variables, e.g. $N3 != $M3 and $Y2 != $Y3. How can I fix this? Since the two messages are not the same (they have different sizes), I would expect a cleanup operation to give each message a unique GUID and write both GUIDs into all places where the old GUID was referenced. I am using Dovecot 2.2.31. Please CC me, since I am not on the list. Best regards, Dennis signature.asc Description: This is a digitally signed message part.
Re: store into mailbox 'Junk' aborted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Aug 2017, kenneth topp wrote: Aug 21 19:43:59 lmtp(toppk): Debug: $MAILDIR/Junk: Mailbox opened because: lib-lda delivery sieve: info: started log at Aug 21 19:43:59. error: msgid=: failed to store into mailbox '$MAILDIR/Junk': Mailbox doesn't exist: $MAILDIR/Junk. What is $MAILDIR and where do you use it? $MAILDIR is /home/toppk/mail (for clarity, it was printing $MAILDIR) Another thing I need to be clear on. This sieve moves are working 99% of the time, just once in a while it fails. Are you sure? if header :matches "Subject" "*junktest*" { fileinto "Junk"; ^^ No $MAILDIR } #if header :matches "Subject" ["*money*","*Viagra*","Cialis"] { #fileinto "Junk"; ^^ Neither #} if header :contains "X-Spam-Flag" "YES" { fileinto "Junk"; ^^ No $MAILDIR } if header :comparator "i;octet" :contains "X-Spam-Flag" "YES" { fileinto "$MAILDIR/Junk"; ^^ Why here?? copy the fileinto of the other rules. } - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBWZwzgXz1H7kL/d9rAQK5TQgAkT7OcnKJv6b8BtF1OcuV8HHDjXX8Vh9a WUJud3cC2gR2jewmTzQn+RuOLuHQp5+NQO7jFunTdK63Kls6l3bT8QkyYmv/DleG 9kFIZ4PEzS5wqfvE2GPIaVqwu6GwCxpFCc65GTqQ6GzNzl53zAdHRkbyJkK0SPOa bAKv8RFWF0PQd9e5ZvQquj/keOlayl/fH8lcNMY/PcdF0ilQJRyKkuFd25XJ5k4U LvJjq8vGQBGQkrM76TRBmU5nWk4NxFY9un5v41TVU9Rp2YIMadvoUJrcELOQG90D mgIK9KxOgeDQirL7ESGIKFeGDBoTQQudWE60Vv+euTohPeCLUHZ8UQ== =YUpK -END PGP SIGNATURE-
Re: LMTP and Postfix
> I am setting up a new system that will be using Dovecot with Postifx. I am > planning on using LMTP. I read the wiki and and found the > settings I need to make in Dovecot and the Postfix main.cf file. However, > I > saw nothing about the Postfix master.cf file. Do I need to make and > changes to > it also? > > Thanks > > -- > Jerry > There are several ways of telling postfix to use lmtp to deliver to dovecot. I went with a method that was setting just the *_transport variable in main.cf to a unix pipe, so I didn't need to setup a service in master.cf. Here are two methods (for mailbox, not virtual mailbox), that show that depending on what you put in main.cf, you may or may not need to update master.cf === method 1 === main.cf - mailbox_transport=dovecot dovecot_destination_recipient_limit=1 - master.cf - dovecot unix n n pipe flags=DRhu user=mail:mail argv=/usr/lib/dovecot/dovecot-lda -f ${sender} -d ${recipient} - === method 2 === main.cf - mailbox_transport = lmtp:unix:private/dovecot-lmtp - HTH, Ken
Re: store into mailbox 'Junk' aborted
> > > Am 22. August 2017 02:29:30 MESZ schrieb kenneth topp : >>Hi, >> >>I've just switch from procmail to pigeonhole, and I'm seeing an issue >>(twice in six hours). >> >>I have spamassisn running via postfix milter, and dropping off via >>main.cf >>"mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp" >> >>The issue is that I get a sequence of these log messages: >> >> >>Aug 21 19:43:59 lmtp(toppk): Debug: Junk: Mailbox opened because: >>lib-lda >>delivery >>Aug 21 19:43:59 lmtp(toppk): Debug: $MAILDIR/Junk: Mailbox opened >>because: >>lib-lda delivery >>Aug 21 19:43:59 lmtp(toppk): Debug: Mailbox : Opened mail >>UID=1 >>because: copying >>Aug 21 19:43:59 lmtp(toppk): Debug: Mailbox : Opened mail >>UID=1 >>because: virtual size (Cache file is unusable) >>Aug 21 19:43:59 lmtp(toppk): Info: YK1SNj9wm1kMaQAAjC58EQ: sieve: >>msgid=: store into mailbox 'Junk' >>aborted >>Aug 21 19:43:59 lmtp(toppk): Debug: INBOX: Mailbox opened because: >>lib-lda >>delivery >>Aug 21 19:43:59 lmtp(toppk): Debug: Mailbox : Opened mail >>UID=1 >>because: copying >>Aug 21 19:43:59 lmtp(toppk): Info: YK1SNj9wm1kMaQAAjC58EQ: sieve: >>msgid=: stored mail into mailbox >>'INBOX' >>Aug 21 19:43:59 lmtp(toppk): Info: YK1SNj9wm1kMaQAAjC58EQ: sieve: >>Execution of script /home/toppk/.dovecot.sieve failed, but implicit >>keep >>was successful (user logfile /home/toppk/.dovecot.sieve.log may reveal >>additional details) >> >>and in /home/toppk/.dovecot.sieve.log I get this: >> >>sieve: info: started log at Aug 21 19:43:59. >>error: msgid=: failed to store into >>mailbox '$MAILDIR/Junk': Mailbox doesn't exist: $MAILDIR/Junk. > What is $MAILDIR and where do you use it? > The error message says that the path can't be found. > I suspect the problem is in your sieve script. You probably have to use > the full path in there. > Oil > Please show the contents of your sieve script. $MAILDIR is /home/toppk/mail (for clarity, it was printing $MAILDIR) Another thing I need to be clear on. This sieve moves are working 99% of the time, just once in a while it fails. here is my /home/toppk/.dovecot.sieve. I notice that I have confusing (overlapping) rules. Could that be the issue? Thanks for any response, Ken # Sieve Filter require ["fileinto","regex","envelope","vacation","reject"]; if header :matches "Subject" "*rejecttest*" { reject "rejecttest"; discard; stop; } if header :matches "List-Id" "Dovecot Mailing List " { fileinto "lists/dovecot"; } if header :matches "Subject" "*junktest*" { fileinto "Junk"; } #if header :matches "Subject" ["*money*","*Viagra*","Cialis"] { #fileinto "Junk"; #} if header :contains "X-Spam-Flag" "YES" { fileinto "Junk"; } if header :comparator "i;octet" :contains "X-Spam-Flag" "YES" { fileinto "$MAILDIR/Junk"; } > >>So instead of the email going into mbox /home/toppk/mail/Junk it goes >>into >>INBOX (/var/mail/toppk). >> >>I'm watching the Junk to see if is removed for even a split second and >>I >>don't see that. I'm not sure how to further track this down, or if >>there >>is a more optimal configuration (i'd prefer to stay mbox if possible). >> >>I was thinking of turning on mailbox_list_index. >> >>Below is the full doveadm -n output. >> >>Any guidance or suggestions welcome. >> >>Ken >> >> >># 2.2.31 (65cde28): /etc/dovecot/dovecot.conf >># Pigeonhole version 0.4.19 (e5c7051) >># OS: Linux 4.12.4-300.fc26.x86_64 x86_64 Fedora release 26 (Twenty >>Six) >>auth_debug = yes >>auth_username_format = %Ln >>log_path = /var/log/dovecot.log >>mail_debug = yes >>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 >>mbox_write_locks = fcntl >>namespace inbox { >> inbox = yes >> location = >> mailbox Drafts { >>special_use = \Drafts >> } >> mailbox Junk { >>special_use = \Junk >> } >> mailbox Sent { >>special_use = \Sent >> } >> mailbox "Sent Messages" { >>special_use = \Sent >> } >> mailbox Trash { >>special_use = \Trash >> } >> prefix = >>} >>passdb { >> driver = pam >>} >>plugin { >> sieve = file:~/sieve;active=~/.dovecot.sieve >> sieve_default = /etc/dovecot/sieve/default.sieve >>} >>protocols = imap lmtp sieve >>service auth { >> unix_listener auth-client { >>group = postfix >>mode = 0660 >>user = postfix >> } >> unix_listener auth-master { >>group = mail >>mode = 0660 >>user = mail >> } >> user = root >>} >>service lmtp { >> unix_listener /var/spool/postfix/private/dovecot-lmtp { >>group = postfix >>mode = 0600 >>user = postfix >> } >>} >>service managesieve-login { >> inet_listener sieve { >>port = 4190 >> } >>} >>service managesieve { >> process_limit = 1024 >>} >>ssl = required >>ssl_cert = >
v2.2.32 release candidate 2 released
https://dovecot.org/releases/2.2/rc/dovecot-2.2.32.rc2.tar.gz https://dovecot.org/releases/2.2/rc/dovecot-2.2.32.rc2.tar.gz.sig A couple of changes since rc1: + Added apparmor plugin. See https://wiki2.dovecot.org/Plugins/Apparmor - director: v2.2.31 caused rapid reconnection loops to directors that were down. Also this was already in rc1's list of changes, but wasn't actually in rc1 yet: - dict-ldap: %variable values used in the LDAP filter weren't escaped. Plus a few other smaller fixes.
Disconnected in APPEND depends on service_count?
Hello, we have quite odd behaviour of dovecot under new OS. We use dovecot 2.2.18 for years under Ubuntu12 and Ubuntu14. Now we use Ubuntu16 and notice some strange errors. dovecot 2.2.18 is rather old, but runs reliable and we dont need newest features, so we packaged it again on Ubuntu16. For explanation: We use some own patches for dovecot and insert some functions in deb packages, so we want to reuse our code to minimize effort. Under ubuntu16 we see a lot of messages like this on high load servers: Aug 22 08:28:15 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 0 secs, 8192/136342 bytes) in=8379 out=830 Aug 22 08:28:16 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 0 secs, 8192/136342 bytes) in=8985 out=2931 Aug 22 08:42:58 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 29 secs, 13139969/42801634 bytes) in=13140054 out=404 Aug 22 08:43:01 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 3 secs, 1286145/42801634 bytes) in=1286230 out=404 Aug 22 08:43:29 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 2 secs, 704476/42801634 bytes) in=704561 out=404 Aug 22 08:44:29 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 60 secs, 27402241/42801634 bytes) in=27402326 out=404 Aug 22 08:45:30 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 3 secs, 1458177/42801634 bytes) in=1458262 out=404 Aug 22 08:46:15 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 45 secs, 20594652/42801634 bytes) in=20594737 out=404 Aug 22 08:47:38 hostname dovecot: imap(username): Disconnected in APPEND (1 msgs, 11 secs, 4907009/42801634 bytes) in=4907094 out=404 Error occured after sending a mail, when client tries to save sent mail in sent-messages folder. (mbox) Typically this is a client problem caused by firewall/virusguard or network erros. But we saw that many different users are effected and we could reproduce this behaviour on clean clients. In our logs and systemd journal we had no hints leading to other error-messages, no dovecot message which tells that limit xy was reached. Also no hints for other malfunctioning services. No helpful lines with mail_debug=yes We tried a lot and it seems that changing "service_count = 0" to "service_count = 1" is part of solution. After changing and restarting the behaviour is like expected. old: service imap-login { executable = /usr/lib/dovecot/imap-login process_min_avail = 1 service_count = 0 user = dovecot } new: service imap-login { executable = /usr/lib/dovecot/imap-login process_min_avail = 1 service_count = 1 user = dovecot process_limit = 1 } service_count switches between number of handled client-connections. i dont see a relation between service_count and the permanent disconnects but it seems to be part of problem. Can anybody explain this behaviour or give some handy tips? Thanks, Hajo
Re: imapsieve: failed to read mailbox attribute
On Tue, Aug 22, 2017 at 01:55:45PM +0300, Aki Tuomi wrote: On 22.08.2017 13:37, Darac Marjal wrote: Hello all, Hopefully this is something fairly simple. I've been trying to set up the Sieve Antispam system as detailed at https://wiki2.dovecot.org/HowTo/AntispamWithSieve, but at the moment, whenever I change mailboxes I get the following message logged: Aug 22 09:30:45 remy dovecot: imap(da...@darac.org.uk): Error: imapsieve: mailbox INBOX: Failed to read /shared/imapsieve/script mailbox attribute and my script does not run when I move files between folders. My sieve files are chmod'ed 0644 and the shell script used to pipe into spamassassin is 0755, so it *should* work, shouldn't it? Is there something I've missed? Can you show doveconf -n and your sieve scripts? Aki Certainly: ---8<--- doveconf -n ---8<--- # 2.2.31 (65cde28): /etc/dovecot/dovecot.conf # Pigeonhole version 0.4.19 (e5c7051) # OS: Linux 4.9.0-1-686-pae i686 Debian buster/sid xfs auth_mechanisms = digest-md5 cram-md5 plain auth_verbose = yes imap_id_log = * info_log_path = /var/log/dovecot.info lda_mailbox_autosubscribe = yes log_timestamp = "%Y-%m-%d %H:%M:%S " login_log_format_elements = service=%s user=<%u> session=%{session} method=%m rip=%r lip=%l mpid=%e %c %k mail_access_groups = mail users mail_gid = vmail mail_home = /var/mail/%u mail_location = mdbox:/var/mail/%u/Mail mail_max_userip_connections = 50 mail_plugins = " zlib fts fts_lucene stats fts fts_lucene stats" mail_privileged_group = mail mail_uid = vmail 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 imapsieve vnd.dovecot.imapsieve vnd.dovecot.pipe vnd.dovecot.execute namespace { hidden = no ignore_on_failure = yes inbox = no list = children location = mbox:~/archive:INDEX=~/archive-indexes prefix = _ARCHIVE/ subscriptions = no } namespace { hidden = no inbox = no list = yes location = mdbox:/var/mail/%u/Mail:MAILBOXDIR=expunged prefix = .EXPUNGED/ subscriptions = no } namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { args = /etc/dovecot/passwd driver = passwd-file } plugin { antispam_backend = pipe antispam_crm_binary = /bin/false antispam_debug_target = syslog antispam_pipe_program = /usr/bin/sa-learn-pipe.sh antispam_pipe_program_notspam_arg = --ham antispam_pipe_program_spam_arg = --spam antispam_pipe_tmpdir = /tmp antispam_spam_pattern_ignorecase = SPAM antispam_trash_pattern_ignorecase = trash;Deleted * fts = lucene fts_lucene = whitespace_chars=@. imapsieve_mailbox1_before = file:/usr/lib/dovecot/sieve/learn-spam.sieve imapsieve_mailbox1_causes = COPY imapsieve_mailbox1_name = Spam imapsieve_mailbox2_before = file:/usr/lib/dovecot/sieve/learn-spam.sieve imapsieve_mailbox2_causes = COPY imapsieve_mailbox2_name = spam imapsieve_mailbox3_before = file:/usr/lib/dovecot/sieve/learn-ham.sieve imapsieve_mailbox3_causes = COPY imapsieve_mailbox3_from = Spam imapsieve_mailbox3_name = * imapsieve_mailbox4_before = file:/usr/lib/dovecot/sieve/learn-ham.sieve imapsieve_mailbox4_causes = COPY imapsieve_mailbox4_from = spam imapsieve_mailbox4_name = * imapsieve_url = sieve://mail.darac.org.uk lazy_expunge = .EXPUNGED/ sieve = file:~/sieve;active=~/.dovecot.sieve sieve_execute_bin_dir = /usr/lib/dovecot/sieve sieve_extensions = +vnd.dovecot.pipe +vnd.dovecot.execute sieve_pipe_bin_dir = /usr/lib/dovecot/sieve sieve_plugins = sieve_imapsieve sieve_extprograms sieve_spamtest_max_header = X-Spam-Score: score=-?[[:digit:]]+\.[[:digit:]].*required=([[:digit:]]+\.[[:digit:]]) sieve_spamtest_status_header = X-Spam-Score: score=(-?[[:digit:]]+\.[[:digit:]]).* sieve_spamtest_status_type = score stats_refresh = 30 secs stats_track_cmds = yes zlib_save = lz4 zlib_save_level = 2 } postmaster_address = postmas...@darac.org.uk protocols = " imap lmtp sieve" service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { group = vmail mode = 0777 user = vmail } } service lmtp { inet_listener lmtp { address = 192.168.101.8 port = 20024 } unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0666 user = postfix } } service managesieve-login { inet_listener sieve { port = 4190 } inet_listener sieve_deprecated { port = 2000 } } service stats { fifo_listener stats-mail { mode = 0600 user = vmail } } ssl_cert = signature.asc Description: PGP signature
Re: imapsieve: failed to read mailbox attribute
On 22.08.2017 13:37, Darac Marjal wrote: > Hello all, > > Hopefully this is something fairly simple. > > I've been trying to set up the Sieve Antispam system as detailed at > https://wiki2.dovecot.org/HowTo/AntispamWithSieve, but at the moment, > whenever I change mailboxes I get the following message logged: > > Aug 22 09:30:45 remy dovecot: imap(da...@darac.org.uk): Error: > imapsieve: mailbox INBOX: Failed to read /shared/imapsieve/script > mailbox attribute > > and my script does not run when I move files between folders. > > My sieve files are chmod'ed 0644 and the shell script used to pipe > into spamassassin is 0755, so it *should* work, shouldn't it? Is there > something I've missed? > Can you show doveconf -n and your sieve scripts? Aki
Re: pop 110/995, imap 143/993 ?
On Tue, 22 Aug 2017, Ivan Warren wrote: > Le 8/22/2017 à 10:03 AM, Robert Wolf a écrit : > > > > WRONG!!! The email is stored plain-text on the first server and then it can > > be > > sent to other few MX servers over plain-text connection. I.e. encrypted > > connection does not protect emails, but the authentication credentials. > > > > > Indeed. > > Encrypted (SSL/TLS) SMTP/IMAP/POP3 sessions only server 1 purpose : To encrypt > authentication. Once a message is sent through a MTA, there is no guarantee of > privacy whatsoever. > > End to End privacy can only be achieved through actual e-mail signing and > encryption (PGP, S/MIME) (but only the message body is encrypted, not the > headers). Hello Ivan yes, headers are not encrypted in plain-text SMTP, the same way as TCP and IP and DNS Requests are not encrypted. One can only hide behind some anonymization system (TOR, Proxy, VPN for TCP, IP, DNS) or some non-presonal mail system to anonymize mail headers to not be able to connect real persones with mail sender/recipient. Regards, Robert.
Re: LMTP and Postfix
On 22.08.2017 12:10, Jerry wrote: > I saw nothing about the Postfix master.cf file. Do I need to make > and changes to it also? No need. Assuming that you use a socket, the following combination should suffice: # Dovecot service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { user = postfix group = postfix mode = 0660 } } # Postfix mailbox_transport = lmtp:unix:private/dovecot-lmtp If you have further questions or a more exotic setup, you might want to consider asking on the Postfix mailing list. -Ralph
imapsieve: failed to read mailbox attribute
Hello all, Hopefully this is something fairly simple. I've been trying to set up the Sieve Antispam system as detailed at https://wiki2.dovecot.org/HowTo/AntispamWithSieve, but at the moment, whenever I change mailboxes I get the following message logged: Aug 22 09:30:45 remy dovecot: imap(da...@darac.org.uk): Error: imapsieve: mailbox INBOX: Failed to read /shared/imapsieve/script mailbox attribute and my script does not run when I move files between folders. My sieve files are chmod'ed 0644 and the shell script used to pipe into spamassassin is 0755, so it *should* work, shouldn't it? Is there something I've missed? -- For more information, please reread. signature.asc Description: PGP signature
LMTP and Postfix
I am setting up a new system that will be using Dovecot with Postifx. I am planning on using LMTP. I read the wiki and and found the settings I need to make in Dovecot and the Postfix main.cf file. However, I saw nothing about the Postfix master.cf file. Do I need to make and changes to it also? Thanks -- Jerry
Re: pop 110/995, imap 143/993 ?
On Tue, 22 Aug 2017, Aki Tuomi wrote: > else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you > have enabled something like cram-md5. Hi, exactly, this is the reason, why plain-text is still needed. You don't need encryption for authentication, if you have secure authentication. Without knowing original password, the MITM cannot generate correct hash for login, so the connection can be plain-text. Of cource, if you then download your emails, the MITM can still read these emails too, if these emails are plain-text (not encrypted using e.g. SMIME or GPG). But he cannot misuse your login. Regards, Robert Wolf.
Re: pop 110/995, imap 143/993 ?
On Mon, 21 Aug 2017, Gary wrote: > If I read this correctly, starttls will fail due to the MITM attack. That is > the client knows security has been compromised. Using SSL/TLS, the MITM can > use SSL stripping. Since most Postifx conf use "may" for security, the > message would go though unencrypted. Correct??? Hi, many people think, the email is encrypted (secured), because it is sent through encrypted submission connection to client's smtp/submission server. I know some case, where one users sends credit card numbers over encrypted channel to SMTP server and he thinks the card numbers are protected! WRONG!!! The email is stored plain-text on the first server and then it can be sent to other few MX servers over plain-text connection. I.e. encrypted connection does not protect emails, but the authentication credentials. Users should know, that they have to encrypt the email itself, if they want protect it. Regards, Robert Wolf.
Re: Re: pop 110/995, imap 143/993 ?
On 08/22/2017 12:42 AM, Gary wrote: > If I read this correctly, starttls will fail due to the MITM attack. That > is the client knows security has been compromised. [...] Since most Postifx > conf use "may" for security, the message would go though unencrypted. > Correct??? Yup. FWIW, one doesn't need to be a large provider or do full traffic analysis to play this kind of game. A couple years back, my MUA failed to send e-mails while I was using the wifi of a Belgian camping ground. Looking into it, I found that SMTP was transparently redirected to an entirely different server - which did not offer the STARTTLS that I had my MUA insist on, either. Kind regards, -- Jochen Bern Systemingenieur Fon:+49 6151 9067-231 Fax:+49 6151 9067-290 E-Mail: jochen.b...@binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 Binect GmbH Robert-Koch-Straße 9, 64331 Weiterstadt, DE Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. smime.p7s Description: S/MIME Cryptographic Signature
Re: pop 110/995, imap 143/993 ?
On 22/08/17 01:56, Peter wrote: Lest anyone think STARTTLS MITM doesn't happen, https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ Right, the attack does happen, but it can be prevented by properly configuring the server and client. Not only for security, I prefer port 993/995 as it's just plain simpler to initiate SSL from the get-go rather than to do some handshaking that gets you to the same point. Simpler from a protocol perspective, yes, but not from a configuration perspective. A separate port requires more firewall configuration, requires listening on more one port if you need to accept both plain text and encrypted connections and requires that port to be allocated by IANA. Seriously? So one more port to allow through the firewall is somehow more complex than making sure the server and/or the client is configured to refuse falling back to plaintext communication - and testing various clients and server flavours to make absolutely sure that they do what they are supposed to be doing and don't fall for a MITM attack? At least with plain SSL/TLS ports, you know for sure that if you are connected, it is definitely encrypted. It would appear that STARTTLS is significantly more vulnerable to MITM attacks than plain SSL/TLS for all the above protocols. Is the slight extra convenience of opportunistic encryption really worth the substantial loss in security? I would not say significantly. If the client is configured to require encryption and to validate the resulting cert from the server then any MITM vulnerability of STARTTLS is fully mitigated. A MITM attack is only an issue if the client is configured for opportunistic encryption. Note that the server side should be configured to require encryption on as well, but the important thing is that the client requires it. Yes - and you have a lot of "if's" above - and that is exactly what makes it more vulnerable in practice - where you have to make absolutely sure that your particular version of your particular software definitely behaves like that - while with plain SSL/TLS it just works and there is no checking needed or "if's". In real life, that makes STARTTLS less secure.