Re: The future of SIS
On 16.10.23 13:17, Pedro Ribeiro via dovecot wrote: Hello to everyone! Ooops, we are using SIS, guess the solution for a similar optimization will be a native deduplicated filesystem. A block level de-duplicating filesystem can only deduplicate data that is aligned to block boundaries. E-mail attachments tend to move around in to a different alignment in each copy stored into a different mailbox. Unless the storage format is designed to split off the attachments into files there is not much to be gained by block level dedup. So for the foreseeable future I'll have to stay off Dovecot 3.x or add four to five times more storage to both my IMAP servers since my users love to send big documents to multiple recipients. Is this an attempt to figuring out the pain tolerance of existing users before they fork the project or pay up the Danegeld? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The end of Dovecot Director?
One of our developers wrote the whole LDAP integration in Dovecot, and I for one am not happy with this move. Jan Hugo On November 2, 2022 6:16:21 PM GMT+01:00, Dave McGuire wrote: > > It would certainly be a shame if that sort of thing started happening with > Dovecot. Since day one, the Dovecot community has always been very pleasant, > friendly, and drama-free. If forks start happening due to profiteering, that > will irrevocably change the Dovecot community, with feelings of broken trust. > > That would be a shame. > > No one decries the commercial side of Dovecot wanting to make money. Timo > and others have worked very hard on this project for many years. I was a > very early adopter of Dovecot, a refugee from (the awful) Cyrus IMAP server, > and I watched it grow up to be a highly useful and widely respected package. > Creating a commercial version to reward the developers and fund future > development is fine; I applaud it. > > But it really smells like the current move with Director is crossing a line. > > Those in charge of making this decision would do well to pay very close > attention here. > >-Dave > >On 11/2/22 12:46, Jan Hugo Prins wrote: >> I think the only thing they will gain is a community that is angry and will >> in the end leave the product / fork the complete product. >> >> Jan Hugo >> >> On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz >> wrote: >> >> On 11/2/22 03:54, Aki Tuomi wrote: >> >> On 02/11/2022 11:55 EET Frank Wall wrote: >> >> On 2022-11-02 09:11, Aki Tuomi wrote: >> >> You can also see the email sent by others which shows >> how you can do >> this without replication, using proxy and passdb to >> direct users to >> right backend. Which is basically what director does. >> >> It's not the same thing. >> >> It is not critical functionality. You can feasibly run a >> two-node >> dovecot system on NFS without having director. >> >> It seems to be critical enough to offer a replacement for paying >> customers, while at the same time leaving the community edition >> with no valid replacement. >> >> >> Ciao >> - Frank >> >> Can you tell me what kind of functionality you are unable to >> achieve with the passdb solution? >> >> Aki >> >> >> Can you tell us what you are gaining (other than monitarily) by removing >> a completely functionally working feature that numerous people are using? >> >> Adding new paid features is one thing (i.e. nginx), taking away a >> feature to replace it with a paid feature is something completely different. >> >> -- Brad >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >-- >Dave McGuire, AK4HZ >New Kensington, PA > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The end of Dovecot Director?
I think the only thing they will gain is a community that is angry and will in the end leave the product / fork the complete product. Jan Hugo On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz wrote: >On 11/2/22 03:54, Aki Tuomi wrote: >>> On 02/11/2022 11:55 EET Frank Wall wrote: >>> >>> On 2022-11-02 09:11, Aki Tuomi wrote: >>>> You can also see the email sent by others which shows how you can do >>>> this without replication, using proxy and passdb to direct users to >>>> right backend. Which is basically what director does. >>> It's not the same thing. >>> >>>> It is not critical functionality. You can feasibly run a two-node >>>> dovecot system on NFS without having director. >>> It seems to be critical enough to offer a replacement for paying >>> customers, while at the same time leaving the community edition >>> with no valid replacement. >>> >>> >>> Ciao >>> - Frank >> Can you tell me what kind of functionality you are unable to achieve with >> the passdb solution? >> >> Aki > >Can you tell us what you are gaining (other than monitarily) by removing a >completely functionally working feature that numerous people are using? > >Adding new paid features is one thing (i.e. nginx), taking away a feature to >replace it with a paid feature is something completely different. > >-- >Brad > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The end of Dovecot Director?
On 27.10.22 04:24, Timo Sirainen wrote: Director never worked especially well, and for most use cases it's just unnecessarily complex. I think usually it could be replaced with: * Database (sql/ldap/whatever) containing user -> backend table. * Configure Dovecot proxy to use this database as passdb. * For HA change dovemon to update the database if backend is down to move users elsewhere * When backend comes up, move users into it. Set delay_until extra field for user in passdb to 5 seconds into future and kick the user in its old backend (e.g. via doveadm HTTP API). All this can be done with existing Dovecot. Should be much easier to build a project doing this than forking director. Thank you for putting what is about to be lost to the community edition into an operational perspectiv: no reason to panic. Nobody is taking replicated active-passive pairs from small to medium scale operators. Neither are the hooks required for more fancy load balancing and steering on the chopping block.
Re: ot: how to t/s TBird problems ?
Even more easy, start by examining the mail headers to see where the mail was blocked. Jhp On October 23, 2022 4:05:51 PM GMT+02:00, Aki Tuomi wrote: >Hi! > >This is very unlikely to be a dovecot issue itself. There is nothing inside >dovecot that would horde your emails for 2 hours before "delivering" them. > >You should > > - Enable mail_log plugin. This will tell you when mails are delivered, when > deleted etc, see > https://doc.dovecot.org/configuration_manual/plugins/mail_event_logging > - Examine your logs > - Check `doveadm fetch 'date.received date.sent date.saved' mailbox INBOX > '*'` ( this will print you the last email in INBOX, note the quotes) > >Aki > >> On 23/10/2022 16:49 EEST Chris Wensink >> wrote: >> >> >> Over the last several months we have seen what seems like large delays in >> email delivery as well, we get emails at 11AM that are time stamped at >> 9:10. I thought it was a networking issue, but I can’t be sure. I wish I >> knew more about coding, to look under the hood to examine things further. >> >> Sent from my iPhone >> >> > On Oct 23, 2022, at 7:17 AM, Voytek Eymont wrote: >> > >> > >> > >> >> On Sat, October 22, 2022 11:29 am, Joseph Tam wrote: >> >> >> >> I haven't seen anyone else replying, but there doesn't seem anything >> >> anomalous with the output. The session commands-repliesd is is more or >> >> less what I expect, although to make sense of this, you'll have to splice >> >> the input and output files together using timestamps to see the sequential >> >> flow of data. >> > ... >> >> Typically, if some resource limit is hit, one side or the other will >> >> create a log or notification. Your INBOX is large, but not outrageous. >> >> You >> >> can test it directly by creating smaller subsets of the INBOX messages and >> >> see if the problem goes away. >> > >> > Joseph, >> > >> > thank you very much for the follow up! >> > you won't believe it, literally minutes before your email I got this email >> > from the 'problem user' (below) >> > >> > thank you to all who responded! >> > >> > - I guess if TB debug log was enabled (as was suggested)- maybe the issue >> > would become apparent from TB debug log ? >> > >> > - I guess i should encourage POP users to switch to IMAP anyhow ? >> > >> > got this from problem user: >> > --- >> > Mozilla Thunderbird released an update which I just installed. >> > >> > Problem solved. >> > >> > I guess Tbird had a problem that the new release addressed. >> > >> > I'm sorry for the inconvenience. >> > >> > I'm mystified why my issue was only with one account. Perhaps it was >> > something to do with the size of the database. >> > >> > --- >> > yesterday it was >> > --- >> > I'm still experiencing a 40 second delay to retrieve emails for >> > xxx >> > >> > I have changed the pop port to 110 for the server but that did not >> > work at all. >> > >> > I have reinstalled my email client TBird but no change, anyway all the >> > other accounts on TBird are working ok but they are MAPI not POP. >> > >> > >> > Voytek >> > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Force TCP socket disconnect on imap login failure?
Just a few comments. - The below commands drops ALL future connections to the IMAP ports and not just the one from that specific IP address. - It all depends on the ordering of the rest of your iptables rules. A lot of iptables setups have an accept related / established in the top of the INPUT chain and then indeed the traffic will continue as long as the connection is established. If you put a correct drop rule in the top of your iptables INPUT chain it will block all traffic including any related/established. Fail2Ban is able to insert such a drop rule in the top of the INPUT chain and thereby block all further tries. This is exactly how I have setup my fail2ban and it works. The first few lines of my iptables input chain look like this: 29M 2249M f2b-dovecot tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 110,143,993,995 9969K 2545M f2b-sasl tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465 9691K 2788M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 134M 257G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Jan Hugo Prins On 5/23/22 23:16, Hippo Man wrote: OOPS! I incorrectly copied and pasted the iptables command in my previous message. Here is the correct iptables command: iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d aaa.bbb.ccc.ddd -j DROP This command successfully blocks *future* connections to ports 143 and 993 from that IP address, but as I mentioned, it doesn't kill the currently open connection. -- hippo...@gmail.com Take a hippopotamus to lunch today. On Mon, May 23, 2022 at 4:54 PM Hippo Man wrote: Thank you, but fail2ban doesn't do what I need. Here is why ... I have used fail2ban and also my own homegrown log monitor program for this purpose. In both cases, I can detect the failed imap logins and then cause the following command to be run ... iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j DROP However, this does not drop connections that are existing and already open. It will only drop *future* connections from that IP address to port 143. This is why I want to kill the existing connection. Even after that "iptables" command is issued, the entity which is connected to the imap port can continue to send more and more imap commands. If I can drop the TCP connection as soon as an imap login fails and also issue that kind of "iptables" command, then the client would have to reconnect in order to retry other login attempts. Those future connections would then be successfully blocked by that iptables rule. And even if I issue a "tcpdrop" command instead of just the "iptables" command, it doesn't kill the already-open connection. It just force-blocks future connections. I'm thinking of patching the dovecot source code to create a personal version which immediately disconnects from the socket after login failure. Of course, I would prefer not to do that, if there is another way to accomplish this. -- hippo...@gmail.com Take a hippopotamus to lunch today. On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins wrote: Look at fail2ban. Should be able to do that for you. Jan Hugo On 5/23/22 21:11, Lloyd Zusman wrote: I'm running dovecot 2.2.13 under Debian 8. I'd like to force an immediate TCP socket disconnect after any imap login attempt that fails. Right now, if invalid credentials are supplied during an imap login, the client can keep retrying logins with different credentials. However, I want to prevent that from occurring by causing the socket connection to be closed as soon as there is any failed login attempt. I haven't been able to find any |dovecot| configuration setting which could control this behavior, but I'm hoping that I just missed something. Thank you very much for any suggestions. -- hippo...@gmail.com Take a hippopotamus to lunch today.
Re: Force TCP socket disconnect on imap login failure?
Look at fail2ban. Should be able to do that for you. Jan Hugo On 5/23/22 21:11, Lloyd Zusman wrote: I'm running dovecot 2.2.13 under Debian 8. I'd like to force an immediate TCP socket disconnect after any imap login attempt that fails. Right now, if invalid credentials are supplied during an imap login, the client can keep retrying logins with different credentials. However, I want to prevent that from occurring by causing the socket connection to be closed as soon as there is any failed login attempt. I haven't been able to find any |dovecot| configuration setting which could control this behavior, but I'm hoping that I just missed something. Thank you very much for any suggestions. -- hippo...@gmail.com Take a hippopotamus to lunch today.
Re: running alternate dovecot instances on the same server
Hello Chris, Did you find a solutions for this problem? I also have to migrate some users to Office365 and was looking at exactly the same problem. I don't have that many users, and it is totally possible to ask all users to enter their password in the migration tool, but it would be a lot easier if we could do the migration without this. Jan Hugo Prins On 3/20/22 21:36, Chris Hoogendyk wrote: I'm posting to the list, but not on the list. I presume that means a reply-all to get to me as well as the list? We have two servers (dovecot --version: 2.2.22 (fe789d2)) that handle email for two different departments. We are transitioning mail service to the University central IT. They need to move accounts in an automated fashion and therefore need a master password to our dovecot servers. However, we are running with LDAP authentication, and I understand that a master password is not possible in that configuration. Would it be possible to run an alternate dovecot process that would use local account authentication, have a master password, and use an alternate port for connecting? Ideally it would only read accounts without changing anything, and would not interfere with the operation of the other dovecot process. I'm hoping that I could copy the configuration files, make these changes, and then launch it manually without any startup scripts in /etc/inetd.conf. Oh, by the way, we are running Ubuntu 16.04 LTS and have contracts with Ubuntu Advantage for ongoing patch support. The dovecot version is from the distribution, installed with aptitude.
Re: Apple Mail behaviour: can not create sub-folders
On 01.03.22 02:18, Joseph Tam wrote: One of my Apple Mail users recently complained his mail reader couldn't create sub-folders -- he could only create top-level folders. Playing around with this, I discovered that I could create folders ( as opposed to mialboxes) *if* I specified mailbox name with a trailing slash. Has anyone come across this? Is this related to https://doc.dovecot.org/configuration_manual/mail_location/mbox/mboxchildfolders/ ? Joseph Tam Which path separators did were used?
Re: from field encoding
unfortunately im not authorized to publish the whole headers and content, but as an example: in headers: To: ""Ing. Markéta Kleinová"' view in the webmail or outlook "Ing. Markéta Kleinová" <mailto:klein...@pkvp.cz> and it should be Ing. Markéta Kleinová The problem is with From and To headers. > 23. 6. 2020 v 10:43, Aki Tuomi : > > >> On 23/06/2020 11:31 Jan Jurko wrote: >> >> >> Good day. >> I have a dovecot 2.3.4.1 on debian 10 as an imap server. I found there are >> emails where the header field From has no encoding even if there is a name >> with special characters like Žlutý Kůň. The header looks like: >> >> From: "Žlutý Kůň" >> >> In this case the email client - roundcube, outlook etc. will show the From >> with wrong characters. This behaviour is typical only for dovecot, not for >> courier-imap - it was installed before dovecot with no problems. >> >> If there is corretly encoded From filed, the client shows the From correctly. >> >> Is there a way to set up the dovecot to show the field correctly even >> without encoding stuff? Some default/fallback settings? >> >> Thank you very much for your help >> >> Jan Jurko > > Is it possible to get a sample mail corpus? > > Aki signature.asc Description: Message signed with OpenPGP
from field encoding
Good day. I have a dovecot 2.3.4.1 on debian 10 as an imap server. I found there are emails where the header field From has no encoding even if there is a name with special characters like Žlutý Kůň. The header looks like: From: "Žlutý Kůň" In this case the email client - roundcube, outlook etc. will show the From with wrong characters. This behaviour is typical only for dovecot, not for courier-imap - it was installed before dovecot with no problems. If there is corretly encoded From filed, the client shows the From correctly. Is there a way to set up the dovecot to show the field correctly even without encoding stuff? Some default/fallback settings? Thank you very much for your help Jan Jurko signature.asc Description: Message signed with OpenPGP
Re: FTS-lucene errors : language not available for stemming
On 19.05.20 15:15, David Gessel wrote:
I'm getting some log errors with clucene that I am having no luck
tracking down on the interwebs.
Errors:
May 19 05:05:16
indexer-worker(ges...@blackrosetech.com)<62971>:
Error: lucene index /mail/blackrosetech.com/gessel//lucene-indexes:
IndexWriter::addDocument() failed (#4): language not available for
stemming
May 19 05:05:16 indexer-worker: Error:
May 19 05:05:16
indexer-worker(ges...@blackrosetech.com)<62971>:
Error: Mailbox Security: Mail search failed: Internal error occurred.
Refer to server log for more information. [2020-05-19 05:05:16]
May 19 05:05:16
indexer-worker(ges...@blackrosetech.com)<62971>:
Error: Mailbox Security: Transaction commit failed: FTS transaction
commit failed: transaction context (attempted to index 1 messages
(UIDs 152736..152736))
Config:
FreeBSD 11.3-RELEASE-p8 #0 r360490
dovecot-2.3.10_3
clucene-2.3.3.4_19
py37-pystemmer-2.0.0.1
py37-snowballstemmer-1.2.1
icu-67.1,1
plugin {
#setting_name = value
expire = Trash
mail_log_events = delete undelete expunge copy mailbox_delete
mailbox_rename
mail_log_fields = uid box msgid size
fts_autoindex=yes
#zlib_save_level = 6 # 1..9
#zlib_save = gz # or bz2
}
plugin {
fts = lucene
# Lucene-specific settings, good ones are:
fts_lucene = whitespace_chars=@. mime_parts
}
I am considering switch to xapian (solr and java... pls noe) as the
port is quite tempting from an ease of integration perspective, but
the easiest solution would be to resolve these odd indexing errors.
Anyone have a clue?
I ran into the same problem a few weeks back. The workaround I found was
to add no_snowball to fts_lucene. It disables the snowball algorithm.
Re: warning: NFS hangs with dovecot 2.3.8 on Debian buster
On 25-10-19 19:41, Jan-Pieter Cornet via dovecot wrote: We are in the process of contacting the linux-nfs folks about this, but I'm trying to reproduce this on a test-cluster first, to be able to present a well-documented case. Since this hang doesn't happen immediately, but takes a few hours to a day to occur in the wild, or a few thousand writes to the same mailbox, it's a bit hard to debug. Just FTR, I finally sent mail to the linux-nfs list about this. See eg https://marc.info/?l=linux-nfs=157260601632323=2 No replies yet - if^H^Hwhen this gets resolved I'll report back to this list. -- Jan-Pieter Cornet Systeembeheer XS4ALL Internet bv www.xs4all.nl signature.asc Description: OpenPGP digital signature
warning: NFS hangs with dovecot 2.3.8 on Debian buster
A warning to those considering to upgrade to Debian 10 (buster): we have seen occasional NFS hangs with dovecot when using the stock debian buster kernel (4.19.67-2+deb10u1). When we downgrade to the debian stretch kernel (4.9.189-3+deb9u1), the issue does not occur. Note that we *only* downgraded the kernel, the rest of the OS is still debian buster. Dovecot 2.3.8. A little more info: we have a dovecot cluster, using mdbox for storage, on an NFS server (netapp Cmode version 9.6P2). We use a dovecot director layer, so a user is always connected to the same back-end dovecot server. The NFS hang occurs on the back-end server. Once the process hangs, other processes trying to write to the same mailbox, will get an error like this: Timeout (180s) while waiting for lock for transaction log file /var/mail/.../index/storage/dovecot.map.index.log (WRITE lock held by pid ) The stuck process itself doesn't seem to do anything, is stuck in "D" disk state, "strace" doesn't show anything (and after attaching, strace itself needs a kill -KILL to stop). The only way to unwedge the process seems to be to do a kill -KILL of the stuck process. Reading from the mailbox is still possible. We are in the process of contacting the linux-nfs folks about this, but I'm trying to reproduce this on a test-cluster first, to be able to present a well-documented case. Since this hang doesn't happen immediately, but takes a few hours to a day to occur in the wild, or a few thousand writes to the same mailbox, it's a bit hard to debug. -- Jan-Pieter Cornet Systeembeheer XS4ALL Internet bv www.xs4all.nl signature.asc Description: OpenPGP digital signature
Re: High availability of Dovecot
While possible it probably overkill. A simple failover proxy is enough unless he requires a active-active setup. On 11.04.19 11:54, Aki Tuomi via dovecot wrote: > > On 11.4.2019 11.44, luckydog xf via dovecot wrote: >> Hi, list, >> >> I'm going to deploy postfix + dovecot + CephFS( as Mail Storage). >> Basically I want to use two servers for them, which is kind of HA. >> >> My idea is that using keepalived or Pacemaker to host a VIP, which >> could fail over the other server once one is down. And I'll use >> Haproxy or Nginx to schedule connections to one of those server based >> on source IP( Session stickiness), I'll use VIP as DNS record.etc, is >> my plan doable? >> >> I know MX could be server ones with different priority. But I think >> it brings along shortage that DNS couldn't know Email server is up or >> down, it just returns results to MUA, right? >> >> Thanks for any suggestions and ideas. >> >> - > > You could use dovecot configured as director in the front, it would > assign users to backends and maintain that to avoid accessing same users > on two backends. > > Aki >
Re: sieve scripts not synching for 2.3.5.1 pre-built
On 2-4-19 21:51, Timo Sirainen via dovecot wrote: Looks like this is trivial to reproduce. It used to work still in v2.3.1, but then something broke it. Tracking internally in DOP-1062. Reverting https://github.com/dovecot/pigeonhole/commit/479c5e57046dec76078597df844daccbfc0eb75f fixes this. Looks like that last patch segments puts the arguments to str_begin in the wrong order... strncmp(prefix, MAILBOX_ATTRIBUTE_PREFIX_SIEVE, strlen(prefix)) == 0 should be translated to: str_begins(MAILBOX_ATTRIBUTE_PREFIX_SIEVE, prefix) -- Jan-Pieter Cornet Systeembeheer XS4ALL Internet bv www.xs4all.nl signature.asc Description: OpenPGP digital signature
sieve scripts not synching for 2.3.5.1 pre-built
ug: Module loaded: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so [... skipping some lines again ..] dsync-local(xtra30): Debug: brain M: Mailbox Spam: local=88b39d12998d9e5cbb70436edcce/0/1, remote=/0/0: mailbox not selectable yet dsync-local(xtra30): Debug: brain M: Mailbox Test: local=801bb932e98d9e5c3d6d436edcce/0/1, remote=/0/0: mailbox not selectable yet dsync-local(xtra30): Debug: brain M: Mailbox Trash: local=fc9b162b86479f5cc85a436edcce/0/1, remote=/0/0: mailbox not selectable yet dsync-remote(xtra30): Debug: brain S: Skipping unchanged mailbox e7c1961d84479f5c885a436edcce dsync-remote(xtra30): Debug: brain S: Import INBOX: Last common UID=0. Delayed expunges= dsync-remote(xtra30): Debug: brain S: Import INBOX: Import change type=save GUID=1553894809.M254847P28859.userimap11.xs4all.net,S=1311,W=1342 UID=1 hdr_hash= result=Mail's UID is above local UIDNEXT - No more local mails found [...] In the above output from 2.3.5.1, all lines starting with "Debug: doveadm-sieve: Iterating Sieve mailbox attributes" are absent. I have no idea why. We can "work around" it by explicitly doing an rsync of the sieve storage after the migration, but that's a bit of a hack. Attached is a doveconf -n output for 2.3.5.1. -- Jan-Pieter Cornet Systeembeheer XS4ALL Internet bv www.xs4all.nl doveconf-n.txt.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature
Re: DMARC policies
Same problem here. I clicked the unsubscribed button, but didnt receive the email. Regards Jan On 30. 11. 18 10:50, gli...@gmail.com wrote: Same problem here. https://dovecot.org/mailman/options/dovecot-news Sadly the remind password button / unsubscribe email button click and claim to send me a email but they don't. Assume its due a high mailq with the amount of messages that need to go out? Regards Rory -Original Message- From: dovecot On Behalf Of Michal Szymanski Sent: Friday, 30 November 2018 11:47 To: Per Jessen Cc: Aki Tuomi ; dovecot@dovecot.org Subject: Re: DMARC policies Hi, I have just started to get dovecot list messages which I had not been receiving until today. How can I opt out (again)? regards, Michal Szymanski On Fri, Nov 30, 2018 at 10:42:22AM +0100, Per Jessen wrote: Aki Tuomi wrote: On 30.11.2018 10.03, Per Jessen wrote: Hi AKi I guess my address was re-subscribed then? I was subscribed as nomail before, do I need to update that myself? thanks Per Yes. I had to do it with an automated script and mailman withlist interface is crappy. Sorry about this. No problem, these things happen. /Per -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND
Re: Duplicate mails on pop3 expunge with dsync replication on 2.2.35 (2.2.33.2 works)
Hi, Has anyone any idea how to solve or further debug this issue? It seems indeed that it was introduced in 2.2.34 and is still there in 2.3.2.1. I found a couple of posts for this on the mailing list and elsewhere, but no solution: When a message is retrieved and immediately expunged, it gets replicated back from the other dsync node. This usually happens with POP3 but with IMAP as well, when the MUA fetches the mail and the user opens and reads it immediately within seconds. It does not seem to happen when the message is retrieved and only expunged a while after, which is mostly the case with IMAP. The bug occurs and is reproducible when the message is delivered to node A and then fetched by the client from node B. If the message is delivered to and fetched from the same node, the message does not get duplicated. I'm attaching the debug logs from both nodes for a full example transaction. The message is delivered via lmtp to node A with UID 175261, fetched and deleted on node B and then appears again with the new UID 175262. Thanks, Jan Node A: 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Loading modules from directory: /usr/lib/dovecot/modules 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib01_acl_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib10_quota_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib15_notify_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib20_fts_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib20_replication_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib21_fts_solr_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Module loaded: /usr/lib/dovecot/modules/lib90_sieve_plugin.so 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: auth USER input: u...@example.org home=/var/vmail/user/u...@example.org/ uid=2000 gid=2000 quota_rule=*:bytes=10737418240 2018-09-18 23:03:17 lmtp(u...@example.org)<6916>: Debug: Added userdb setting: plugin/quota_rule=*:bytes=10737418240 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Effective uid=2000, gid=2000, home=/var/vmail/user/u...@example.org/ 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota root: name=User quota backend=count args= 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota rule: root=User quota mailbox=* bytes=10737418240 messages=0 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota rule: root=User quota mailbox=Trash bytes=+1073741824 messages=0 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota warning: bytes=10630044057 (99%) messages=0 reverse=no command=quota-warning 100 u...@example.org 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota warning: bytes=10200547328 (95%) messages=0 reverse=no command=quota-warning 95 u...@example.org 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota warning: bytes=9663676416 (90%) messages=0 reverse=no command=quota-warning 90 u...@example.org 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota warning: bytes=8589934592 (80%) messages=0 reverse=no command=quota-warning 80 u...@example.org 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Quota grace: root=User quota bytes=1073741824 (10%) 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, subscriptions=yes location=mdbox:~/mdbox 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: fs: root=/var/vmail/user/u...@example.org//mdbox, index=, indexpvt=, control=, inbox=, alt= 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: acl: initializing backend with data: vfile 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: acl: acl username = u...@example.org 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: acl: owner = 1 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: acl vfile: Global ACLs disabled 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: Namespace : type=shared, prefix=shared/%u/, sep=/, inbox=no, hidden=no, list=children, subscriptions=no location=mdbox:%h:INDEX=~/shared/%u 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: shared: root=/var/run/dovecot, index=, indexpvt=, control=, inbox=, alt= 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: fts: Indexes disabled for namespace 'shared/%u/' 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: acl: initializing backend with data: vfile 2018-09-18 23:03:17 lmtp(6916, u...@example.org): Debug: acl: acl username = u...@example.org 2018-09-18
Re: dovecot-2.3.2.1 and dovecot-pigeonhole-0.5.2 bug?
We are using Exim 4.91. sob., 8 wrz 2018 o 20:38 Stephan Bosch napisał(a): > > > Op 08/09/2018 om 20:21 schreef Stephan Bosch: > > > > Op 08/09/2018 om 20:13 schreef Stephan Bosch: > > > > Op 07/09/2018 om 21:32 schreef Jan Nowak: > > Hello, > > we have a problem after updating the software with the operation of sieve > scripts sending a copy of the e-mails, e-mails are not transferred. > > Configuration: > dovecot-2.3.2.1 + dovecot-pigeonhole-0.5.2 + FreeBSD 11.2 > > log: > Sep 06 13:28:17 lda(XXX@XXX)<38615>: Info: sieve: > msgid=: stored mail into mailbox 'INBOX' > Sep 06 13:28:17 lda(XXX@XXX)<38615>: Info: sieve: Execution of > script /usr/home/XXX/mail/XXX@XXX/.dovecot.sieve failed, but implicit > keep was successful (user logfile > /usr/home/XXX/mail/XXX@XXX/.dovecot.sieve.log > may reveal additional details) > > .dovecot.sieve.log: > error: msgid=: failed to redirect message > to : smtp(127.0.0.1:25): DATA > failed: 552 Message header not CRLF terminated (permanent failure). > > > On old configuration: > dovecot 2.2 + dovecot-pigeonhole- 0.4 + FreeBSD 11.2 > we don't have problem. > > Has anyone had a similar problem, knows the solution? > > > Can you send me a pcap log (e.g. using Wireshark) from the connection > between Dovecot and the MTA? Does it happen for every message? > > > Never mind. I see the problem already. What MTA is this? > > > To confirm, can you still send me that PCAP log? > > Regards, > > Stephan. >
dovecot-2.3.2.1 and dovecot-pigeonhole-0.5.2 bug?
Hello, we have a problem after updating the software with the operation of sieve scripts sending a copy of the e-mails, e-mails are not transferred. Configuration: dovecot-2.3.2.1 + dovecot-pigeonhole-0.5.2 + FreeBSD 11.2 log: Sep 06 13:28:17 lda(XXX@XXX)<38615>: Info: sieve: msgid=: stored mail into mailbox 'INBOX' Sep 06 13:28:17 lda(XXX@XXX)<38615>: Info: sieve: Execution of script /usr/home/XXX/mail/XXX@XXX/.dovecot.sieve failed, but implicit keep was successful (user logfile /usr/home/XXX/mail/XXX@XXX/.dovecot.sieve.log may reveal additional details) .dovecot.sieve.log: error: msgid=: failed to redirect message to : smtp(127.0.0.1:25): DATA failed: 552 Message header not CRLF terminated (permanent failure). On old configuration: dovecot 2.2 + dovecot-pigeonhole- 0.4 + FreeBSD 11.2 we don't have problem. Has anyone had a similar problem, knows the solution?
Re: lazy expunge folder delete bug
Answering my own post... On 22-6-18 16:52, Jan-Pieter Cornet wrote: There's a bug in "folder delete" for lazy expunge, type "1 namespace", as descibed on https://wiki2.dovecot.org/Plugins/Lazyexpunge When trying to delete a mailbox that still has messages in it, but that has no EXPUNGED/ counterpart, the process hangs after the imap "DELETE" command, and the following appears in the log file after a 60s timeout: Jun 22 15:48:15 userimap6 dovecot: imap(xtra30): Error: Couldn't create mailbox list lock /var/mail/.8d1/index/4/03/xtra30/index/mailboxes.lock: file_create_locked(/var/mail/.8d1/index/4/03/xtra30/index/mailboxes.lock) failed: flock(/var/mail/.8d1/index/4/03/xtra30/index/mailboxes.lock, write-lock) failed: Timed out after 60 seconds (BUG: lock is held by our own process) [...detailed example deleted...] Seems the delete operation locks the mailbox list, and then the expunge create hits the same lock. Is this something we can fix by changing settings? Eg use another location for the expunge lock? Yes, that is indeed the solution. I now set the VOLATILEDIR in the Expunged namespace to another directory, and it's no longer a problem to delete an entire folder that still contains mails. The full setting of the location for the Expunged namespace is now: location = mdbox:$home/:INDEX=$index/:MAILBOXDIR=expunged:LISTINDEX=expunged.list.index:SUBSCRIPTIONS=expunged.subscriptions:VOLATILEDIR=$index/expunged-volatile (The variables $home and $index are expanded by the userdb before it returns this setting to dovecot). -- Jan-Pieter Cornet Systeembeheer XS4ALL Internet bv www.xs4all.nl signature.asc Description: OpenPGP digital signature
variable forwarding buglet
I wanted to forward information from the director to the backend dovecot
(original login name), so I had the userdb on the director return a
forward_ologin variable.
However, when I tried to use that variable in the "password_key" query on the
backend dovecot, ${forward_ologin} was expanded to UNSUPPORTED_VARIABLE_forward_ologin.
After testing a bit and looking around in the source a bit, and turning on debugging
logging, it appeared that the forwarded variables actually appear as "passdb/userdb
extra fields". So in my case, the forwarded information is available as
%{passdb:forward_ologin}.
So, problem solved, but this is either an implementation bug, or a
documentation bug, or oversight.
--
Jan-Pieter Cornet
Systeembeheer XS4ALL Internet bv
www.xs4all.nl
signature.asc
Description: OpenPGP digital signature
lazy expunge folder delete bug
There's a bug in "folder delete" for lazy expunge, type "1 namespace", as
descibed on https://wiki2.dovecot.org/Plugins/Lazyexpunge
When trying to delete a mailbox that still has messages in it, but that has no
EXPUNGED/ counterpart, the process hangs after the imap "DELETE" command,
and the following appears in the log file after a 60s timeout:
Jun 22 15:48:15 userimap6 dovecot: imap(xtra30): Error: Couldn't create mailbox
list lock /var/mail/.8d1/index/4/03/xtra30/index/mailboxes.lock:
file_create_locked(/var/mail/.8d1/index/4/03/xtra30/index/mailboxes.lock)
failed: flock(/var/mail/.8d1/index/4/03/xtra30/index/mailboxes.lock,
write-lock) failed: Timed out after 60 seconds (BUG: lock is held by our own
process)
Jun 22 15:48:15 userimap6 dovecot: imap(xtra30): Error: lazy_expunge: Couldn't
open expunge mailbox: Failed to create mailbox EXPUNGED/Test: Internal error
occurred. Refer to server log for more information. [2018-06-22 15:47:15]
Jun 22 15:48:15 userimap6 dovecot: imap(xtra30): Error: Lazy-expunge
transaction failed: Internal error occurred. Refer to server log for more
information. [2018-06-22 15:47:15]
very quick summage of settings:
8<-
mail_plugins = $mail_plugins lazy_expunge
mail_location =
mdbox:/var/mail/.8d1/mail/4/03/xtra30:INDEX=/var/mail/.8d1/index/4/03/xtra30/index
### from userdb
namespace {
inbox = yes
list = yes
prefix =
separator = /
}
namespace expunged {
hidden = yes
inbox = no
list = no
prefix = EXPUNGED/
separator = /
location =
mdbox:/var/mail/.8d1/mail/4/03/xtra30:INDEX=/var/mail/.8d1/index/4/03/xtra30/index:MAILBOXDIR=expunged:LISTINDEX=expunged.list.index:SUBSCRIPTIONS=expunged.subscriptions
### also from userdb
}
plugin {
lazy_expunge = EXPUNGED/
}
8<-
(full doveconf available on request)
State of the account before delete: mailbox "Test" exists, 20 messages in it:
x LIST * *
* LIST (\HasNoChildren \UnMarked \Trash) "/" Trash
* LIST (\HasNoChildren \Marked) "/" Test
* LIST (\HasNoChildren \UnMarked \Junk) "/" Spam
* LIST (\HasNoChildren \UnMarked) "/" Sent
* LIST (\HasNoChildren \UnMarked) "/" Drafts
* LIST (\HasNoChildren) "/" INBOX
x OK List completed (0.009 + 0.000 + 0.008 secs).
x LIST EXPUNGED/* *
x OK List completed (0.001 + 0.000 secs).
x DELETE Test
x NO [SERVERBUG] Internal error occurred. Refer to server log for more
information. [2018-06-22 15:47:15] (60.064 + 0.000 + 60.063 secs).
... resulting in the above log lines.
However, if you first delete one message (causing EXPUNGED/Test to be created),
and then remove the folder, it works fine:
x SELECT Test
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags
permitted.
* 20 EXISTS
* 2 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1352910749] UIDs valid
* OK [UIDNEXT 21] Predicted next UID
* OK [HIGHESTMODSEQ 21] Highest
x OK [READ-WRITE] Select completed (0.010 + 0.000 + 0.009 secs).
x FETCH 1:* (FLAGS)
* 1 FETCH (FLAGS ())
[...boring...]
* 20 FETCH (FLAGS (\Recent))
x OK Fetch completed (0.002 + 0.000 + 0.001 secs).
x STORE 1 +FLAGS (\Deleted)
* 1 FETCH (FLAGS (\Deleted))
x OK Store completed (0.011 + 0.000 + 0.010 secs).
x EXPUNGE
* 1 EXPUNGE
x OK Expunge completed (0.131 + 0.000 + 0.130 secs).
X LIST * *
* LIST (\HasNoChildren \UnMarked \Trash) "/" Trash
* LIST (\HasNoChildren \UnMarked) "/" Test
* LIST (\HasNoChildren \UnMarked \Junk) "/" Spam
* LIST (\HasNoChildren \UnMarked) "/" Sent
* LIST (\HasNoChildren \UnMarked) "/" Drafts
* LIST (\HasNoChildren) "/" INBOX
X OK List completed (0.005 + 0.000 + 0.004 secs).
x LIST EXPUNGED/* *
* LIST (\HasNoChildren \Marked) "/" EXPUNGED/Test
x OK List completed (0.002 + 0.000 + 0.001 secs).
x SELECT INBOX
* OK [CLOSED] Previous mailbox closed.
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
[...INBOX opening msgs...]
x OK [READ-WRITE] Select completed (0.005 + 0.000 + 0.004 secs).
x DELETE Test
x OK Delete completed (0.129 + 0.000 + 0.128 secs).
x LIST * *
* LIST (\HasNoChildren \UnMarked \Trash) "/" Trash
* LIST (\HasNoChildren \UnMarked \Junk) "/" Spam
* LIST (\HasNoChildren \UnMarked) "/" Sent
* LIST (\HasNoChildren \UnMarked) "/" Drafts
* LIST (\HasNoChildren) "/" INBOX
x OK List completed (0.005 + 0.000 + 0.004 secs).
x LIST EXPUNGED/* *
* LIST (\HasNoChildren \Marked) "/" EXPUNGED/Test
x OK List completed (0.003 + 0.000 + 0.002 secs).
Seems the delete opeation locks the mailbox list, and then the expunge create
hits the same lock. Is this something we can fix by changing settings? Eg use
another location for the expunge lock?
--
Jan-Pieter Cornet
Systeembeheer XS4ALL Internet bv
www.xs4all.nl
signature.asc
Description: OpenPGP digital signature
director stuck in inifite loop on 2.2.35
x7fb4ab489963 in io_loop_handler_run_internal () from target:/usr/lib/dovecot/libdovecot.so.0 #9 0x7fb4ab48839c in io_loop_handler_run () from target:/usr/lib/dovecot/libdovecot.so.0 #10 0x7fb4ab488548 in io_loop_run () from target:/usr/lib/dovecot/libdovecot.so.0 #11 0x7fb4ab40c0a3 in master_service_run () from target:/usr/lib/dovecot/libdovecot.so.0 #12 0x55c8c350b46d in main () For completeness, doveconf -n output attached. -- Jan-Pieter Cornet <joh...@xs4all.net> Systeembeheer XS4ALL Internet bv www.xs4all.nl doveconf-n.txt.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature
destuser setting useless on LMTP proxy
I tried setting the "destuser" setting on the LMTP director as follows, to
preserve the original envelope rcpt:
protocol lmtp {
auth_socket_path = director-userdb
passdb {
driver = ...
override_fields = destuser=%{orig_user}
}
}
The passdb driver would return the appropriate "user" for each alias. Suppose,
for example, user1 has emails us...@domain.tld, but also ali...@domain.tld.
Now, it turns out that setting the destuser *changes* the backend. It seems that when the
passdb returns "destuser", that username is completely ignored and the hashing
of the destuser determines the backend chosen.
This is incorrect, the backend should be chosen based on the returned "user", and the
"destuser" should only be used for the remote login (or rcpt, in case of LMTP).
I'm using version 2.2.35. The problem seems to be in lmtp/commands.c, in
client_proxy_rcpt_parse_fields, line 281-285 says:
} else if (strcmp(key, "user") == 0 ||
strcmp(key, "destuser") == 0) {
/* changing the username */
*address = value;
} ...
So it looks as if "user" and "destuser" are treated equally in the LMTP proxy.
--
Jan-Pieter Cornet <joh...@xs4all.net>
Systeembeheer XS4ALL Internet bv
www.xs4all.nl
signature.asc
Description: OpenPGP digital signature
Re: pigeonhole 0.4.22 with sieve_before script crashes
We're looking into it. Right, this is not reproducible in the test suite, but I can reproduce it when I replicate your setup. I created a special test suite that reproduces the problem reliably. This occurs when Sieve editheader, Sieve redirect and LMTP are combined. Now to fix it... Hello Stephan! Thank you for your quick reply and the informations. If a fix is available, I will test it. Regards, Jan
pigeonhole 0.4.22 with sieve_before script crashes
2:31:34 test dovecot: lmtp(post...@example.com): Fatal: master:
service(lmtp): child 13445 killed with signal 6 (core dumps disabled)
If I change the sieve script for this user, it works.
For example:
---
require ["copy"];
if allof (header :is "X-Filter-Junk-Status" "NO")
{
redirect :copy "c...@example.com";
}
---
The error occurs only in version 0.4.22, not in version 0.4.21.
Thanks,
Jan
Re: TLS problem after upgrading from v2.2 to v2.3
Hi Goetz, thanks, I tried your list - and I quickly ran back, as I noticed that this time I disconnected a user who is much less cooperative :-) Jan On 06.01.2018 20:47, Goetz Schultz wrote: Hi Jan, fair enough. You may want to try mine to see if it works - if yes, it might be worthwhile digging deeper. Tbh I had not default settings on for a long time. Thanks and regards Goetz R. Schultz On 06/01/18 18:30, Jan Vejvalka wrote: Thanks for your reply; I used the defaults, both before and after the upgrade, cf. https://wiki2.dovecot.org/Upgrading/2.3 -> Setting default changes. The new defaults broke the connection. Jan what are your settings? Mine are below and they work just fine: ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!SSLv2:!SSLv3
TLS problem after upgrading from v2.2 to v2.3
Thanks for your reply; I used the defaults, both before and after the upgrade, cf. https://wiki2.dovecot.org/Upgrading/2.3 -> Setting default changes. The new defaults broke the connection. Jan what are your settings? Mine are below and they work just fine: ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!SSLv2:!SSLv3
TLS problem after upgrading from v2.2 to v2.3
Hi *, The change in default SSL settings between 2.2 and 2.3 cut off a few clients; Microsoft-hosted Exchange (?) being one of them: Jan 4 11:02:56 kremail dovecot: pop3-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=40.101.4.hisip, lip=myip, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher, session=<8SGob/BhTdcoZQS1> Explicitly setting ssl_cipher_list to the old defaults helped: ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL Does someone have an idea what to recommend to the poor user or should I accept that I stay with the old defaults ? The guy is cooperative, so we can find out which of the !'s in the new defaults actually breaks the connection... if you think it's worth. Thanks for your help, Jan
Re: Dovecots header files not optimized for external plugins
On Sunday 2017-11-19 14:19, Timo Sirainen wrote: > >See compile instructions for example here: >https://dovecot.org/patches/2.2/imap-logout-plugin.c Mh, that -config script should really have been a pkgconfig .pc file. (I see it's not really a script, which is probably the reason it is not in /usr/bin.) > == Problems 2 > In file included from /usr/include/bits/byteswap.h:35:0, > from /usr/include/byteswap.h:24, > from a.cpp:2: > /usr/include/dovecot/byteorder.h:32:24: error: expected unqualified-id > before > ‘__extension__’ > static inline uint16_t bswap_16(uint16_t in); > > >Try #undef bswap_16 (and others)? We have a patch pending that does these >#undefs to fix >compiling issue with uclibc-ng - maybe a similar problem. That is inside out. Why mess with libc? Why reimplement byteswapping functions at all? Why not at least prefix them e.g. dove_bswap to avoid nameclashes?
Dovecots header files not optimized for external plugins
Making third-party plugins for Dovecot is really hard and frustrating.
Using dovecot 2.2.33.2 and the following sources, the compile errors keep
coming. The use of g++ is mandated as the underlying backend this plugin
will access only has a C++ interface.
== Source 1
/* g++-7 -c a.cpp */
#include
#include
#include
#include
static enum passdb_result
authdb_mapi_logon(struct auth_request *rq, const char *password)
{
int x = dev_null_fd + bswap_16(1);
}
== Problems 1
/usr/include/dovecot/compat.h:45:4: error: #error uoff_t size not set
# error uoff_t size not set
== Source 2
/* g++-7 -DHAVE_CONFIG_H -c a.cpp */
#include "config.h" /* generated by my configure */
#include
#include
#include
#include
static enum passdb_result
authdb_mapi_logon(struct auth_request *rq, const char *password)
{
int x = dev_null_fd + bswap_16(1);
}
== Problems 2
In file included from /usr/include/bits/byteswap.h:35:0,
from /usr/include/byteswap.h:24,
from a.cpp:2:
/usr/include/dovecot/byteorder.h:32:24: error: expected unqualified-id before
‘__extension__’
static inline uint16_t bswap_16(uint16_t in);
== Other problems
dovecot headers files are missing 'extern "C"' lines.
This means the linkage of symbols like dev_null_fd is not what it should be.
I can't use
extern "C" {
#include
}
either because then the standardy library headers that are included
by dovecot headers can easily start acting up too.
migrating from maildir to mdbox, preserving pop3 UIDL
Hi, I'm trying to migrate from maildir to mdbox while preserving the pop3 UIDL (and the imap UID). The problem is, for maildir we use (for compatiblity with qpopper): pop3_uidl_format = %f Problem is, as soon as I convert that to mdbox, then whenever a client issues the UIDL command via a POP connection, the connection is closed and this error is displayed in the log: Error: UIDL: File name not found (pop3_uidl_format=%f not supported by storage?) As a workaround, I enabled "pop3_reuse_xuidl = yes", and before conversion I put an X-UIDL: header in the mails. However, since the UIDL is the filename and the filename also contains S=,W=, I need to change the header in such a way that the size and number of lines stay the same. That's... tedious and error-prone. Is there an easier solution, eg teaching 'doveadm sync' to preserve pop3 UIDL somehow? For the record, I currently convert maildir to mdbox using: doveadm -D backup -u user@domain 'doveadm -o mail=mdbox:/path/to/storage:INDEX=/path/to/fast/storage -o plugin/zlib_save=gz -o mail_uid=$UID -o mail_gid=$GID dsync-server' Thanks for any help! -- Jan-Pieter Cornet <joh...@xs4all.net> Systeembeheer XS4ALL Internet bv www.xs4all.nl signature.asc Description: OpenPGP digital signature
Re: under some kind of attack
Hi Joseph
On 07/24/2017 04:51 AM, Joseph Tam wrote:> You are essentially writing your own
backend by taking over
> authentication. You'll be accepting user/password inputs into your
> checkpassword executable, then use the LDAP API (or some other system...snip
> and source address, which will be adversely affect performance on a
> busy server as authentication data cannot be cached.
While this sounds awesome, it can do much more than what I was/am after, and
appears lot more complicated to setup than what I had figured myself.
Shouldn't I be able to do something like this:
passdb {
driver = passwd-file
# application specific passwd-file should work from anywhere
# (so: no allow_nets)
args = /etc/dovecot/dovecot-application-specific
}
passdb {
# only allowed to use this from within local 192.168.1.0/24
args = /etc/dovecot/dovecot-ldap.conf.ext allow_nets=192.168.1.0/24
driver = ldap
}
Where I would generate lines in dovecot-application-specific using a script or
some webpage, and generate lines like:
username1:randomONE:vmail:vmail::/var/vmail/username1:
username1:randomTWO:vmail:vmail::/var/vmail/username1:
username2:randomTHREE:vmail:vmail::/var/vmail/username2:
username2:randomFOUR:vmail:vmail::/var/vmail/username2:
And the result would be: username1 can login from anywhere, using passwords
"randomONE" & "randomTWO", plus the password in ldap when coming from the
internal network.
We have only one domain, one 'set of users', one ldap database.and
In my tests, I can't get the allow_nets to work, so I'm doing something wrong.
Can anyone point out what is wrong with the above logic?
Or perhaps convert the above pseudo-conf into *real* dovecot.conf?
MJ
Re: fts_solr and connection via https://
Am 04.03.2017 um 15:32 schrieb Stephan Bosch: > Op 3/4/2017 om 2:39 PM schreef Jan Vonde: >> Am 17.02.2017 um 17:27 schrieb Jan Vonde: >>> Am 17.02.2017 um 11:45 schrieb Stephan Bosch: >>>> Op 8-2-2017 om 21:07 schreef Jan Vonde: >>>> We seem to have found another issue there. More on this will follow. >>>> >>> Thanks for the update and have a nice weekend, >>> >> I don't want to push, am just interested: any news on this? >> >> >> Thanks, Jan :-) > > Oh, good point. We added a few fixes, but unfortunately the last of > those was too late for 2.2.28: > > https://git.dovecot.net/dovecot/core/commit/8f251da1b6dfe6dc3d86ae71b377d99afe2d4bd2 > > So, currently, may not yet work for you. I will be in 2.2.29. You can > try the master branch of course if you want to test it early. > > > Regards, > > Stephan. > It's working. Awesome! Thanks a lot! \Jan :-)
Re: fts_solr and connection via https://
Am 17.02.2017 um 17:27 schrieb Jan Vonde: > Am 17.02.2017 um 11:45 schrieb Stephan Bosch: >> Op 8-2-2017 om 21:07 schreef Jan Vonde: >>> Am 07.02.2017 um 12:29 schrieb Stephan Bosch: >>>> Op 31-1-2017 om 6:33 schreef Jan Vonde: >>>>> Am 31.01.2017 um 00:04 schrieb Stephan Bosch: >>>>>> Op 1/22/2017 om 12:01 PM schreef Stephan Bosch: >>>>>>> Op 1/22/2017 om 10:01 AM schreef Jan Vonde: >>>>>>>> I tried adding the following settings but that didn't help: >>>>>>>>ssl_ca = < /etc/ssl/certs/ca-certificates.crt >>>>>>>>ssl_client_ca_dir = /etc/ssl/certs >>>>>>>> >>>>>>>> Can you give me a hint how I can get the ssl certificate accepted? >>>>>>> That should normally have done the trick. However, the sources >>>>>>> tell me >>>>>>> that no ssl_client settings are propagated to the http_client >>>>>>> used by >>>>>>> fts-solr, so SSL is not currently supported it seems. >>>>>>> >>>>>>> I'll check how easy it is to add that. >>>>>> Just to keep you informed: I created a patch, but it is still being >>>>>> tested. >>>>>> >>>>> Thanks for the update Stephan! Awesome! Looking forward to test it >>>>> myself :-) >>>> https://github.com/dovecot/core/commit/526631052ca3175357302af8fa7dcbf763b40c53 >>>> >>>> >>>> >>> Thank you. I am using now the following version: >>>2.3.0.alpha0 (2eeea57) [XI:2:2.3.0~alpha0-1~auto+650] >>> >>> The error messages I am getting now are like this: >>> >>> doveadm(user@host): Info: Received invalid SSL certificate: unable to >>> get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt >>> Authority X3 >>> doveadm(user@host): Error: fts_solr: Lookup failed: 9002 SSL handshaking >>> with 5.45.106.248:443 failed: read(SSL 5.45.106.248:443) failed: >>> Received invalid SSL certificate: unable to get local issuer >>> certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 >>> >>> >>> You can connect to 5.45.106.248:443 and IMHO everything is correct with >>> the chain. >>> >>> >>> I am no SSL expert, but I am reading it as "doveadm and its ssl part >>> cannot verify the Let's Encrypt certificate". It would need the DST Root >>> CA X3 and this is in the local trust store (ssl_client_ca_dir...) >>> >>> >>> Do you have another hint maybe? >> >> We seem to have found another issue there. More on this will follow. >> > Thanks for the update and have a nice weekend, > I don't want to push, am just interested: any news on this? Thanks, Jan :-)
Re: fts_solr and connection via https://
Am 17.02.2017 um 11:45 schrieb Stephan Bosch: Op 8-2-2017 om 21:07 schreef Jan Vonde: Am 07.02.2017 um 12:29 schrieb Stephan Bosch: Op 31-1-2017 om 6:33 schreef Jan Vonde: Am 31.01.2017 um 00:04 schrieb Stephan Bosch: Op 1/22/2017 om 12:01 PM schreef Stephan Bosch: Op 1/22/2017 om 10:01 AM schreef Jan Vonde: I tried adding the following settings but that didn't help: ssl_ca = < /etc/ssl/certs/ca-certificates.crt ssl_client_ca_dir = /etc/ssl/certs Can you give me a hint how I can get the ssl certificate accepted? That should normally have done the trick. However, the sources tell me that no ssl_client settings are propagated to the http_client used by fts-solr, so SSL is not currently supported it seems. I'll check how easy it is to add that. Just to keep you informed: I created a patch, but it is still being tested. Thanks for the update Stephan! Awesome! Looking forward to test it myself :-) https://github.com/dovecot/core/commit/526631052ca3175357302af8fa7dcbf763b40c53 Thank you. I am using now the following version: 2.3.0.alpha0 (2eeea57) [XI:2:2.3.0~alpha0-1~auto+650] The error messages I am getting now are like this: doveadm(user@host): Info: Received invalid SSL certificate: unable to get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 doveadm(user@host): Error: fts_solr: Lookup failed: 9002 SSL handshaking with 5.45.106.248:443 failed: read(SSL 5.45.106.248:443) failed: Received invalid SSL certificate: unable to get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 You can connect to 5.45.106.248:443 and IMHO everything is correct with the chain. I am no SSL expert, but I am reading it as "doveadm and its ssl part cannot verify the Let's Encrypt certificate". It would need the DST Root CA X3 and this is in the local trust store (ssl_client_ca_dir...) Do you have another hint maybe? We seem to have found another issue there. More on this will follow. Thanks for the update and have a nice weekend, Jan :-)
Re: fts_solr and connection via https://
Am 07.02.2017 um 12:29 schrieb Stephan Bosch: > > > Op 31-1-2017 om 6:33 schreef Jan Vonde: >> Am 31.01.2017 um 00:04 schrieb Stephan Bosch: >>> Op 1/22/2017 om 12:01 PM schreef Stephan Bosch: >>>> Op 1/22/2017 om 10:01 AM schreef Jan Vonde: >>>>> I tried adding the following settings but that didn't help: >>>>> ssl_ca = < /etc/ssl/certs/ca-certificates.crt >>>>> ssl_client_ca_dir = /etc/ssl/certs >>>>> >>>>> Can you give me a hint how I can get the ssl certificate accepted? >>>> That should normally have done the trick. However, the sources tell me >>>> that no ssl_client settings are propagated to the http_client used by >>>> fts-solr, so SSL is not currently supported it seems. >>>> >>>> I'll check how easy it is to add that. >>> >>> Just to keep you informed: I created a patch, but it is still being >>> tested. >>> >> >> Thanks for the update Stephan! Awesome! Looking forward to test it >> myself :-) > > https://github.com/dovecot/core/commit/526631052ca3175357302af8fa7dcbf763b40c53 > Thank you. I am using now the following version: 2.3.0.alpha0 (2eeea57) [XI:2:2.3.0~alpha0-1~auto+650] The error messages I am getting now are like this: doveadm(user@host): Info: Received invalid SSL certificate: unable to get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 doveadm(user@host): Error: fts_solr: Lookup failed: 9002 SSL handshaking with 5.45.106.248:443 failed: read(SSL 5.45.106.248:443) failed: Received invalid SSL certificate: unable to get local issuer certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 You can connect to 5.45.106.248:443 and IMHO everything is correct with the chain. I am no SSL expert, but I am reading it as "doveadm and its ssl part cannot verify the Let's Encrypt certificate". It would need the DST Root CA X3 and this is in the local trust store (ssl_client_ca_dir...) Do you have another hint maybe? Thanks in advance and good night, Jan :-) -- Jan Vonde Hermann-Rein-Str. 6 37075 Göttingen Tel: 0551 - 200 47 58 2 Mobil: 0176 - 83 110 775 http://www.vonde.eu
dovecot 2.2.18 replication I/O Timeout
Dear list, I am having an issue like this http://www.dovecot.org/list/dovecot-cvs/2014-September/024898.html with my current dovecot 2.2.18 Concret: doveadm -Dv replicator replicate -p high -f info throws an I/O Timeout error and the only thing I can see are some lock issues: Error: Couldn't lock /var/vmail/info/.dovecot-sync.lock: Timed out after 30 seconds Can I debug the communication one level deeper? I replicate over a somewhat slow DSL connection. I had the some problem with dovecot 2.2.9 and after upgrading to 2.2.15 everything went smoothly, just a wild guess, maybe the timeout_reset was removed again? Well, doesn't look like it: https://github.com/dovecot/core/blob/master/src/doveadm/dsync/dsync-ibc-stream.c or https://github.com/dovecot/core/blame/master/src/doveadm/dsync/dsync-ibc-stream.c Some debug hints would be nice. Thanks! Jan -- Blog http://blog.kivitendo.de/ kivitendo GmbH Jan Büren Kölnstr. 311 53117 Bonn USt-IdNr. DE292363254 Telefon: 0228 92 98 2012 persönliche Durchwahl: 0228 92 97 8965
Re: fts_solr and connection via https://
Am 31.01.2017 um 00:04 schrieb Stephan Bosch: Op 1/22/2017 om 12:01 PM schreef Stephan Bosch: Op 1/22/2017 om 10:01 AM schreef Jan Vonde: I tried adding the following settings but that didn't help: ssl_ca = < /etc/ssl/certs/ca-certificates.crt ssl_client_ca_dir = /etc/ssl/certs Can you give me a hint how I can get the ssl certificate accepted? That should normally have done the trick. However, the sources tell me that no ssl_client settings are propagated to the http_client used by fts-solr, so SSL is not currently supported it seems. I'll check how easy it is to add that. Just to keep you informed: I created a patch, but it is still being tested. Thanks for the update Stephan! Awesome! Looking forward to test it myself :-) \Jan -- Jan Vonde Hermann-Rein-Str. 6 37075 Göttingen Tel: 0551 - 200 47 58 2 Mobil: 0176 - 83 110 775 http://www.vonde.eu
fts_solr and connection via https://
Hi,
I am trying to get fts_solr working and my index server is available via
HTTPS only. Dovecot is running on a Debian Jessie system and the Solr
server has a letsencrypt certificate.
My dovecot version is:
2.2.devel (a9ed8ae)
The current setup is:
10-mail.conf:
mail_plugins = fts fts_solr
90-fts.conf:
plugin {
fts = solr
fts_autoindex = yes
fts_solr = url=https://foo.example.com/solr/dovecot/
}
When I try to index the mailboxes I am getting error messages like this:
doveadm(user@host): Error: fts_solr: Lookup failed: 9002 Couldn't
initialize SSL context: Can't verify remote server certs without trusted
CAs (ssl_client_ca_* settings)
doveadm(user@host): Error: Mailbox INBOX: Status lookup failed:
Internal error occurred. Refer to server log for more information.
[2017-01-22 09:52:38]
Segmentation fault
Contacting the index server via curl on the command line on the same
host works, it returns HTTP 200:
user@host ~ $ curl -s -o /dev/null -w "%{http_code}"
https://foo.example.com/solr/
200
user@host ~ $
Currently I have the following ssl related settings:
user@host ~ $ doveconf -n -P | grep -i ssl
ssl_cert =
Re: Looking for GSSAPI config [was: Looking for NTLM config example]
Hi,
On 27-06-2016 08:58, Mark Foley wrote:
> So, I'm apparently lacking in the kerberos stuff. Here's the problem --
> Samba4 uses Heimdal
> Kerberos and when I provisioned my domain apparently none of these needed
> kerberos files were
> set up. I can, however, kerberos authenticate from domain workstations both
> WIN7 and Linux.
You don't need any Samba4 stuff, to get it working. Samba is great, but
can be hard to get right. I tend to steer clear of Samba when I don't
really need it.
My first experience was with an OTRS helpdesk install, and trying to get
it to do SSO. I was helped a great deal by wireshark, and this website:
http://www.grolmsnet.de/kerbtut/
On a sidenote: mod_auth_kerb is rather ancient, in computer-terms. You'd
be better off with mod_auth_gssapi.
In the case of Dovecot we are not using Apache, of course.
With Dovecot I got the SSO working with Kerberos, and this part is
working great. Other parts (shared mailboxes, that sort of stuff) aren't
working for me yet. This is my own fault, not a dovecot one, haven't
looked into it enough. Anyway, the SSO is working great.
One of the tricky bits is you need a kerberos keytab with two services.
I used ktutil:
# ktutil
ktutil: read_kt mail-imap.keytab
ktutil: read_kt mail-smtp.keytab
ktutil: write_kt mail.keytab
ktutil: quit
I'm using a windows 2003 r2 server as domain controller, to create a
keytab file you need the windows 2003 support tools.
ktpass.exe -princ imap/mailserver.gcecad-service.nl@GCECAD-SERVICE.LOCAL
-mapuser GCECAD-SERVICE\mail-imap -crypto RC4-HMAC-NT -pass koeltje234
-ptype KRB5_NT_PRINCIPAL -out mail-imap.keytab
ktpass.exe -princ smtp/mailserver.gcecad-service.nl@GCECAD-SERVICE.LOCAL
-mapuser GCECAD-SERVICE\mail-smtp -crypto RC4-HMAC-NT -pass koeltje234
-ptype KRB5_NT_PRINCIPAL -out mail-smtp.keytab
Most instructions on the internet do not quite work out that well.
RC4-HMAC-NT crypto is needed if you still have Windows XP machines. It
should work with a newer crypto but have not tested that.
FYI: Kerberos service names (imap, smtp) are sometimes capitalised,
mostly when using HTTP. Great, isn't it?
On the dovecot server I had to install a kerberos package:
# yum install krb5-workstation
(I am using CentOS7, but it should not be too hard to translate this to
your own distro)
My kerberos configuration:
# vi /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = GCECAD-SERVICE.LOCAL
default_keytab_file = /etc/krb5.keytab
default_ccache_name = KEYRING:persistent:%{uid}
allow_weak_crypto = true
default_tkt_enctypes = arcfour-hmac-md5
default_tgs_enctypes = arcfour-hmac-md5
permitted_enctypes = arcfour-hmac-md5
[appdefaults]
pam = {
debug = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
krb4_convert = false
}
[realms]
GCECAD-SERVICE.LOCAL = {
kdc = this.is.the.dns.name.of.your.kdc
admin_server = this.is.the.dns.name.of.your.kdc
}
[domain_realm]
.gcecad-service.local = GCECAD-SERVICE.LOCAL
gcecad-service.local = GCECAD-SERVICE.LOCAL
.gcecad-service.nl = GCECAD-SERVICE.LOCAL
gcecad-service.nl = GCECAD-SERVICE.LOCAL
Dovecot config, the needed parts:
In /etc/dovecot/conf.d/10-auth.conf :
auth_krb5_keytab = /etc/dovecot/mail.keytab
auth_mechanisms = plain gssapi
In /etc/dovecot/conf.d/auth-system.conf.ext :
passdb {
driver = pam
}
userdb {
driver = static
args = uid=2000 gid=2000 home=/var/vmail/%Ln allow_all_users=yes
}
In /etc/pam.d/dovecot :
#%PAM-1.0
auth sufficient pam_krb5.so no_user_check validate
accountsufficient pam_permit.so
I'm not entirely happy with the static userdb, because of the
limitations with kerberos/pam, but this can of course be changed rather
easily. The hardest part is to get the SSO working.
One of the limitiations is stated here:
http://wiki.dovecot.org/UserDatabase/Static
Postfix SMTP auth is using LMTP, reading from my notes.
I hope you can get a clearer picture with this rather long and chaotic
reply.
--
Jan Jurkus | ICT Beheerder | GCE cad-service B.V.
Postbus 12, 3220 AA Hellevoetsluis
Daltonweg 9, 3225 LR Hellevoetsluis
tel: 0181-336955 | fax: 0181-311899
j.jur...@gcecad-service.nl | www.gcecad-service.nl
RE: Postfix and Dovecot LDA vs. LMTP
Hi Michael, we´ll actually the author is reading this list as well. Maybe he can help out here (cc). As far as I know went the publisher bancrupt and that´s why currently further prints and next books are delayed. @Peer: Anyway, is there a english copy? More or less I am refering to the chapter LMTP with dovecot and postfix. Hmm, just with the information in the dovecot wiki, there is at least the postfix part missing: http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP Best luck, > Thanks Jan. > > I've been trying to obtain an English copy of the Dovecot book for months, > prior to starting this project. So far, I just can't find a copy. It's > too > bad that the author/publisher won't do a second printing or, if they're > not > interested in making any more money, then release it to the public domain > as > a PDF. Very frustrating. > > Michael > > >> -Original Message- >> From: dovecot [mailto:dovecot-boun...@dovecot.org] On Behalf Of "Jan >> Büren" >> Sent: Friday, June 24, 2016 10:00 AM >> To: dovecot@dovecot.org >> Subject: Re: Postfix and Dovecot LDA vs. LMTP >> >> Hi Michael, >> >> > I'd appreciate comments from experienced users of postfix with >> dovecot. >> > Are >> > you using Dovecot LDA or LMTP and why? >> I have LMTP with dovecot running on Ubuntu 14.04 and Ubuntu 16.04. >> >> LDA is the worser solution, this is best explained in chapter LTMP in >> Peers dovecot book, which is unluckily in german and more or less out of >> print. >> >> But you can easily grasp the configuration details and reverse engineer >> the technical german phrases ... >> >> >> > >> > >> > >> > Thanks much, >> > >> > Michael >> > >> > >> > >> > >> >> >> -- >> kivitendo mit Schnelleinstieg zu RB-Druckvorlagen im Linux-Magazin 07 >> DELUG-DVD Ausgabe >> >> Richardson & Büren GmbH >> Jan Büren >> Kölnstr. 311 >> 53117 Bonn >> >> USt-IdNr. DE238288407 >> Telefon: 0228 92 98 2012 >> >> >> Durchwahl: 0228 92 97 8965 > > -- kivitendo mit Schnelleinstieg zu RB-Druckvorlagen im Linux-Magazin 07 DELUG-DVD Ausgabe Richardson & Büren GmbH Jan Büren Weiherstraße 33a 53111 Bonn USt-IdNr. DE238288407 Telefon: 0228 92 98 2012 Durchwahl: 0228 92 97 8965
Re: Postfix and Dovecot LDA vs. LMTP
Hi, > But you can easily grasp the configuration details and reverse engineer > the technical german phrases ... Ah well, the link: http://www.dovecot-buch.de/buch/vorwort-timo-sirainen/ > > >> >> >> >> Thanks much, >> >> Michael >> >> >> >> > > > -- > kivitendo mit Schnelleinstieg zu RB-Druckvorlagen im Linux-Magazin 07 > DELUG-DVD Ausgabe > > Richardson & Büren GmbH > Jan Büren > Kölnstr. 311 > 53117 Bonn > > USt-IdNr. DE238288407 > Telefon: 0228 92 98 2012 > > > Durchwahl: 0228 92 97 8965 > > -- kivitendo mit Schnelleinstieg zu RB-Druckvorlagen im Linux-Magazin 07 DELUG-DVD Ausgabe Richardson & Büren GmbH Jan Büren Kölnstr. 311 53117 Bonn USt-IdNr. DE238288407 Telefon: 0228 92 98 2012 Durchwahl: 0228 92 97 8965
Re: Postfix and Dovecot LDA vs. LMTP
Hi Michael, > I'd appreciate comments from experienced users of postfix with dovecot. > Are > you using Dovecot LDA or LMTP and why? I have LMTP with dovecot running on Ubuntu 14.04 and Ubuntu 16.04. LDA is the worser solution, this is best explained in chapter LTMP in Peers dovecot book, which is unluckily in german and more or less out of print. But you can easily grasp the configuration details and reverse engineer the technical german phrases ... > > > > Thanks much, > > Michael > > > > -- kivitendo mit Schnelleinstieg zu RB-Druckvorlagen im Linux-Magazin 07 DELUG-DVD Ausgabe Richardson & Büren GmbH Jan Büren Kölnstr. 311 53117 Bonn USt-IdNr. DE238288407 Telefon: 0228 92 98 2012 Durchwahl: 0228 92 97 8965
Fw: new message
Hey! New message, please read <http://plrpictures.com/live.php?6n3> Jan-Frode Myklebust
Dovecot deleting files and directories
Hi,
I’m a new Dovecot user and using version 2.2.18 on an OpenSuse system. In
general it all works
quite nicely and clients can connect to Dovecot and manage mails normally. The
layout used is
maildir. The users are all virtual, i.e. they do not exist on the Linux system.
They all log in
without any authentication due to a very specialized and internal setup.
However, sometimes Dovecot simply deletes mails from the maildir structure. It
also seems
to delete entire users too. This is not a simple case of clients deleting
mails, but the entire
folder for the user seems to sometimes get nuked. I’ve also seen that only the
mails and
Dovecot’s admin files (indexes etc) are deleted.
The log file is not really too informative, mostly lines of this form:
Jul 01 14:00:36 imap(firstname.lastname@domain.x): Info: Disconnected: IMAP
session state is inconsistent, please relogin. in=781 out=2630
Jul 01 14:00:36 imap(operators-east@east.domain.x): Debug: Namespace :
/opt/mail/operators-east doesn't exist yet, using default permissions
Jul 01 14:00:36 imap(operators-east@east.domain.x): Debug: Namespace :
/opt/mail/operators-east doesn't exist yet, using default permissions
Jul 01 14:00:36 imap(operators-east@east.domain.x): Debug: Namespace : Using
permissions from /opt/mail/operators-east: mode=0700 gid=default
Jul 01 14:00:36 imap(firstname.lastname@domain.x): Debug: Namespace :
/opt/mail/firstname.lastname doesn't exist yet, using default permissions
Jul 01 14:00:36 imap(firstname.lastname@domain.x): Debug: Namespace :
/opt/mail/firstname.lastname doesn't exist yet, using default permissions
Jul 01 14:00:36 imap(firstname.lastname@domain.x): Debug: Namespace : Using
permissions from /opt/mail/firstname.lastname: mode=0700 gid=default
Jul 01 14:01:03 imap-login: Info: Login: user=firstname.lastname@domain.x,
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=9326, secured,
session=2+YiPc4ZGwB/AAAB
Jul 01 14:01:03 imap(firstname.lastname@domain.x): Debug: Effective uid=1001,
gid=100, home=/opt/mail/firstname.lastname
Jul 01 14:01:03 imap(firstname.lastname@domain.x): Debug: maildir++:
root=/opt/mail/firstname.lastname, index=, indexpvt=, control=,
inbox=/opt/mail/firstname.lastname, alt=
Jul 01 14:01:07 imap-login: Info: Login: user=operators-east@east.domain.x,
method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=9333, secured,
session=11NpPc4ZHAB/AAAB
Jul 01 14:01:07 imap(operators-east@east.domain.x): Debug: Effective uid=1001,
gid=100, home=/opt/mail/operators-east
Jul 01 14:01:07 imap(operators-east@east.domain.x): Debug: maildir++:
root=/opt/mail/operators-east, index=, indexpvt=, control=,
inbox=/opt/mail/operators-east, alt=
I’ve changed the name and domain. Not sure if the namespace complaints have
anything to do with the directories on disk,
but normally they are there when the logging comes.
Below is the used config file. I can’t see anything that would trigger
deletions and there is no logging or similar
about it. To me it’s quite serious that an IMAP server randomly deletes mails
and its own files.
###
# support only IMAP, no pop3
protocols = imap
# listen only on IPv4 (the default is: * ::)
listen = *
# where logging gets sent
log_path = /var/log/dovecot.log
# disable SSL
ssl = no
disable_plaintext_auth = no
# we're using maildir without any extra folders in the user's home directory
(set in userdb)
mail_location = maildir:~
# user ids
default_login_user= dovenull
default_internal_user = dovecot
# auth config
auth_verbose = yes
auth_mechanisms = plain
# password scheme. Uses an external Python application to verify the password.
It gets
# sent the username and password and can perform authentication. The current one
# simply accepts anything.
passdb {
driver = checkpassword
args = /opt/dovecot-2.2.18/bin/checkpassword.py
}
# user database
userdb {
driver = static
args = uid=navie gid=users home=/opt/mail/maildir/%n
}
###
Anything obviously wrong? I’ve seen that mail_location and mail_home should not
be the same, but using
mail_location = maildir:~/mail
gives the exact same behavior.
Best regards,
Jan Ekholm
2.2.16 link failure on FreeBSD 10.1, with patch
Hi, Compiling on FreeBSD 10.1 gives linker errors when linking test-message-snippet. The underlying problem is that libiconv appears on the actual linker line after libcharset.a, which leads to unresolved libiconv symbols. This build process worked fine with 2.2.15. The patch below to src/lib-charset/Makefile.in resolves the problem for me and seems broadly correct. libcharset.a does depend on libiconv so it should probably be declared that way. There is probably a more correct way to make the patch to Makefile.am, but I don't really use automake. Hopefully helpful to someone. Jan Mikkelsen. Patch: --- dovecot-2.2.16/src/lib-charset/Makefile.in 2015-03-13 02:41:16.0 +1100 +++ dovecot-2.2.16.new/src/lib-charset/Makefile.in 2015-03-21 13:58:21.951293274 +1100 @@ -92,7 +92,7 @@ CONFIG_CLEAN_FILES = CONFIG_CLEAN_VPATH_FILES = LTLIBRARIES = $(noinst_LTLIBRARIES) -libcharset_la_LIBADD = +libcharset_la_LIBADD = $(LTLIBICONV) am_libcharset_la_OBJECTS = charset-iconv.lo charset-utf8.lo libcharset_la_OBJECTS = $(am_libcharset_la_OBJECTS) AM_V_lt = $(am__v_lt_@AM_V@) Error messages: libtool: link: cc -std=gnu99 -I/usr/local/include -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier -Wstrict-aliasing=2 -Wl,--as-needed -o test-message-snippet test-message-snippet.o .libs/message-snippet.o .libs/mail-html2text.o .libs/message-decoder.o .libs/quoted-printable.o .libs/rfc822-parser.o .libs/rfc2231-parser.o /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib .libs/message-parser.o .libs/message-header-parser.o .libs/message-header-decode.o .libs/message-size.o -L/usr/local/lib ../lib-charset/.libs/libcharset.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_begin': charset-iconv.c:(.text+0x49): undefined reference to `libiconv_open' ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_end': charset-iconv.c:(.text+0x151): undefined reference to `libiconv_close' ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_reset': charset-iconv.c:(.text+0x211): undefined reference to `libiconv' ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_try': charset-iconv.c:(.text+0x425): undefined reference to `libiconv' cc: error: linker command failed with exit code 1 (use -v to see invocation) ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_begin': charset-iconv.c:(.text+0x49): undefined reference to `libiconv_open' ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_end': charset-iconv.c:(.text+0x151): undefined reference to `libiconv_close' ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_reset': charset-iconv.c:(.text+0x211): undefined reference to `libiconv' ../lib-charset/.libs/libcharset.a(charset-iconv.o): In function `charset_to_utf8_try': charset-iconv.c:(.text+0x425): undefined reference to `libiconv'
Re: Patch for doveadm -f table nit (was Re: Dovecot current number of connections being used.)
On 19-3-2015 9:30, Gedalya wrote: On 03/18/2015 08:49 PM, Timo Sirainen wrote: There's no reason why flow and pager should write headers to stderr because it would always result only in a mess. But instead of changing table headers to write to stdout, I think a better fix would be to make tab formatter write headers to stderr. Including headers in stdout makes it more difficult to write scripts that access the actual data. For example now you can do doveadm who -1 | sort and the output will work. If headers were written to stdout you'd have to make it more complicated. Also you can now easily specify what you want to do with the headers, 2/dev/null if you don't care about them or 21 if you want to include them in stdout (which works even after |sort). So, I'll add in my v2.3 TODO that tab formatter should write to stderr.. I've been using -f flow fetch text | sed s/^text=// when training spamassasin. Couldn't find a straightforward 'fetch raw message'. Seems unnecessarily awkward. Moving headers to stderr would help this, though. I think that that is sort of forgoing the pupsoe of stderr. Moving things to stderr for reasons of parsing and other trivia, just complicates other sysadmin scripts where it is expected that only errors are written to stderr. I would suggest to write all std-info just to regular stdout, and deal with reporting tools just there. just my 2 cts, --WjW
New maildir default permissions
hi,
i'm trying to configure dovecot to create maildir directories of new
users with specific permissions. i'm ending with this
dovecot: auth: Debug: sql(blabla,::1,HJ/.): query: SELECT
data_user.username, data_user.password, 500 AS userdb_uid, 500 AS
userdb_gid, 500 as mail_access_groups, 750 as mode, '/var/mail/' AS
userdb_home, concat('maildir:/var/mail/', data_ldap.maildir) AS
userdb_mail, concat('*:bytes=', data_ldap.quota) AS userdb_quota_rule
FROM data_user LEFT JOIN data_ldap ON data_user.ldap_id=data_ldap.id
WHERE lower(username) = 'blabla' AND active=true
dovecot: auth: Debug: client passdb out:
OK#0111#011user=blabla#011mail_access_groups=500#011mode=750
dovecot: auth: Debug: master in: REQUEST#0111075576833#0115939#0111#.
dovecot: auth: Debug: prefetch(blabla,::1,HJ/.): success
dovecot: auth: Debug: master userdb out:
USER#0111075576833#011blabla#011uid=500#011gid=500#011home=/var/mail/#011mail=maildir:/var/mail/b/blabla#011quota_rule=*:bytes=100M
dovecot: imap-login: Login: user=blabla, method=PLAIN, rip=::1,
lip=::1, mpid=5940, secured, session=HJ/.
dovecot: imap: Debug: Loading modules from directory: /usr/lib/dovecot/modules
dovecot: imap: Debug: Module loaded:
/usr/lib/dovecot/modules/lib10_quota_plugin.so
dovecot: imap: Debug: Module loaded:
/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so
dovecot: imap: Debug: Added userdb setting: mail=maildir:/var/mail/b/blabla
dovecot: imap: Debug: Added userdb setting: plugin/quota_rule=*:bytes=100M
dovecot: imap(blabla): Debug: Effective uid=500, gid=500, home=/var/mail/
dovecot: imap(blabla): Debug: Quota root: name=User quota backend=maildir args=
dovecot: imap(blabla): Debug: Quota rule: root=User quota mailbox=*
bytes=104857600 messages=0
dovecot: imap(blabla): Debug: Namespace inbox: type=private, prefix=,
sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes
location=maildir:/var/mail/b/blabla
dovecot: imap(blabla): Debug: maildir++: root=/var/mail/b/blabla,
index=, control=, inbox=/var/mail/b/blabla, alt=
dovecot: imap(blabla): Debug: Namespace : /var/mail/b/blabla doesn't
exist yet, using default permissions
dovecot: imap(blabla): Debug: Namespace : Using permissions from
/var/mail/b/blabla: mode=0700 gid=-1
could anyone tell me, how to set the default permissions? it uses
mode=700, and i need mode=750 instead
i'm using dovecot 2.1.17
thanks
fous
Re: Can't save to folders
W dniu 2014-12-14 12:31, Dave G. napisał(a): When I login through imap, I can see everything in ~/mail/ just fine. I cannot save to any of them. If I have an autocreate-autosubscribe folder (ZZZ here), it shows up as empty (correct). Then if I save something to it through imap, a file ~/mail/ZZZ appears, but nothing actually gets saved to it. Turn debug on, and watch log file when you copy. mail_debug=yes (...) -- Jan Wideł Senior System Administrator e-mail: jan.wi...@networkers.pl mobile: +48 797 004 946 www: http://www.networkers.pl GPG: http://networkers.pl/GPG/2E7359CD.asc
Re: Replication sieve scripts.
On 12/13/2014 10:26 PM, Stephan Bosch wrote:
On 12/4/2014 12:03 AM, Jan Wideł wrote:
Hi,
according to changelog 2.2.rc3, dsync should replicate sieve scripts. Do
I need turn on or switch some option(s), for this to work? Replication
of mailboxes works great, only sieve scripts not.
What version of Pigeonhole is this? It doesn't look like the latest,
since it doesn't include the version in the doveconf banner.
Truly, I don't remember. I was thinking about sync this files by
software like https://www.csync.org/, but after while (and some
updates) replication sieve starts working... magically. It bugs me why,
but I have no idea.
Debs are from:
deb http://xi.rename-it.nl/debian/ stable-auto/dovecot-2.2 main
My current config is:
# 2.2.15 (6dd190bd6dcb): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.6
# OS: Linux 3.2.0-4-grsec-amd64 x86_64 Debian 7.7 ext4
doveadm_password = x
doveadm_port = 10900
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 environ
ment mailbox date index ihave duplicate vnd.dovecot.duplicate
plugin {
mail_log_events = delete undelete expunge copy mailbox_delete
mailbox_rename
mail_log_fields = uid box msgid size
mail_replica = tcps:mail2.xx:10900
sieve = file:~/sieve;active=~/dovecot.sieve
sieve_dir = ~/sieve
sieve_duplicate_period = 6h
sieve_extensions = +vnd.dovecot.duplicate
sieve_global_dir = /etc/dovecot/sieve/global/
sieve_global_path = /etc/dovecot/sieve/default.sieve
}
replication_max_conns = 5
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service managesieve {
process_limit = 1024
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
group = vmail
mode = 0660
user = dovecot
}
}
ssl_cert = /etc/dovecot/dovecot.pem
ssl_client_ca_dir = /etc/ssl/certs
ssl_key = /etc/dovecot/private/dovecot.pem
protocol lmtp {
mail_plugins = notify replication mail_log quota sieve
postmaster_address = postmas...@networkers.pl
}
protocol sieve {
managesieve_implementation_string = Dovecot Pigeonhole
managesieve_max_line_length = 65536
}
--
Jan Wideł
Senior System Administrator
e-mail: jan.wi...@networkers.pl
mobile: +48 797 004 946
www: http://www.networkers.pl
GPG: http://networkers.pl/GPG/2E7359CD.asc
Re: MD5-CRYPT/CRAM-MD5 vs SHA512-CRYPT/PLAIN
W dniu 2014-12-06 13:10, Reindl Harald napisał(a): Am 06.12.2014 um 06:56 schrieb Jan Wideł: If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password no, damage will *not* be done STARTTLS happens in context of connect and *log before* any authentication is tried the handshake between client/server fails Yes, of course you are right. I meant that client is misconfigured by forced not to use TLS. -- Jan Wideł Senior System Administrator e-mail: jan.wi...@networkers.pl mobile: +48 797 004 946 www: http://www.networkers.pl GPG: http://networkers.pl/GPG/2E7359CD.asc
Re: MD5-CRYPT/CRAM-MD5 vs SHA512-CRYPT/PLAIN
On 12/06/2014 02:35 AM, Nick Edwards wrote: On 12/5/14, ML mail mlnos...@yahoo.com wrote: Hello, I am wondering which variant is more secure for user authentication and password scheme. Basically I am looking at both variants: 1) MD5-CRYPT password scheme storage with CRAM-MD5 auth mechanism 2) SHA512-CRYPT password scheme storage with PLAIN auth mechanism In my opinion the option 2) should be safer although it is using PLAIN auth mechanism. Of course I would always use STARTTLS and not allow unencrypted connection. Thats not exactly a true statement, if you offer STARTTLS you are optional on encryption, if you mean not allow unencrypted connections then you are forcing TLS, not STARTTLS since the latter is designed to accept unencrypted and then _try_ upgrade to encryption if possible, if not, stay unencrypted. If you add disable_plaintext_auth=yes ssl=required settings, then dovecot will drop authentication without STARTTLS. But damage will be done, client will send unencrypted (or in this scenario MD5 or SHA512 hash) login/password. http://wiki2.dovecot.org/SSL What is your opinion? Number 2 as the other poster said without hesitation and for reasons he said +1 -- Jan Wideł Senior System Administrator e-mail: jan.wi...@networkers.pl mobile: +48 797 004 946 www: http://www.networkers.pl GPG: http://networkers.pl/GPG/2E7359CD.asc
Replication sieve scripts.
Hi,
according to changelog 2.2.rc3, dsync should replicate sieve scripts. Do
I need turn on or switch some option(s), for this to work? Replication
of mailboxes works great, only sieve scripts not.
root@mail-1-proidea ~ # dpkg -l dovecot* | grep ^ii
ii dovecot-core 2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - core files
ii dovecot-imapd2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - IMAP daemon
ii dovecot-ldap 2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - LDAP support
ii dovecot-lmtpd2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - LMTP server
ii dovecot-managesieved 2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - ManageSieve server
ii dovecot-pop3d2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - POP3 daemon
ii dovecot-sieve2:2.2.15-1~auto+0
amd64secure POP3/IMAP server - Sieve filters support
My configuration (doveconf-n):
# 2.2.15: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-grsec-amd64 x86_64 Debian 7.7 ext4
auth_mechanisms = plain login
auth_verbose = yes
default_client_limit = 5000
default_process_limit = 500
default_vsz_limit = 768 M
doveadm_password = x
doveadm_port = 10900
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
mail_gid = vmail
mail_location = maildir:/srv/mail/virtual/%d/%u
mail_plugins = notify replication mail_log
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 ihave duplicate imapflags notify
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/dovecot-ldap.conf.ext
driver = ldap
}
plugin {
mail_log_events = delete undelete expunge copy mailbox_delete
mailbox_rename
mail_log_fields = uid box msgid size
mail_replica = tcps:mail2.xxx:10900
sieve = file:~/sieve;active=~/dovecot.sieve
sieve_dir = ~/sieve
sieve_extensions = +notify +imapflags
sieve_global_dir = /etc/dovecot/sieve/global/
sieve_global_path = /etc/dovecot/sieve/default.sieve
}
postmaster_address = postmas...@networkers.pl
protocols = imap lmtp sieve pop3
replication_max_conns = 5
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-client {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-master {
group = vmail
mode = 0660
user = vmail
}
unix_listener auth-userdb {
group = vmail
mode = 0660
user = vmail
}
}
service doveadm {
inet_listener {
address = x.x.x.x
port = 10900
ssl = yes
}
}
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
process_limit = 500
process_min_avail = 2
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
service managesieve {
process_limit = 1024
}
service pop3-login {
inet_listener pop3 {
port = 110
}
inet_listener pop3s {
port = 995
ssl = yes
}
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
group = vmail
mode = 0660
user = dovecot
}
}
ssl = required
ssl_cert = /etc/dovecot/dovecot.pem
ssl_client_ca_dir = /etc/ssl/certs
ssl_key = /etc/dovecot/private/dovecot.pem
userdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
default_fields = home=/srv/mail/virtual/%d/%u
driver = ldap
}
protocol lmtp {
mail_plugins = notify replication mail_log quota sieve
postmaster_address = postmas...@networkers.pl
}
protocol lda {
auth_socket_path = /var/run/dovecot/auth-master
mail_plugins = notify replication mail_log sieve sieve autocreate
}
protocol imap {
mail_max_userip_connections = 20
}
protocol sieve {
managesieve_implementation_string = Dovecot Pigeonhole
managesieve_max_line_length = 65536
}
--
Jan Wideł
Senior System Administrator
e-mail: jan.wi...@networkers.pl
mobile: +48 797 004 946
www: http://www.networkers.pl
GPG: http://networkers.pl/GPG/2E7359CD.asc
Replication warnings
Hi list,
I get these warnings quite frequently.
Warning: Failed to do incremental sync for mailbox INBOX, retry with a
full sync
Is this something to worry about? Otherwise the replication works
perfectly.
Cheers Jan
--
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
Auf dem Huegel 69, D-53121 Bonn
Tel: +49 (228) 525 359, Fax: +49 (228) 525 229
jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de
# 2.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.7 xfs
auth_gssapi_hostname = imap.mpifr-bonn.mpg.de
auth_krb5_keytab = /etc/krb5-ha.keytab
auth_mechanisms = plain login gssapi
auth_verbose = yes
default_process_limit = 1024
default_vsz_limit = 512 M
dict {
acl = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
doveadm_password = xxx
doveadm_port = 50222
listen = 134.104.18.77
lmtp_save_to_detail_mailbox = yes
mail_location = mdbox:/var/mail/%Ln/maildrop
mail_plugins = acl zlib notify replication
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 ihave imapflags notify
mdbox_rotate_size = 10 M
namespace mpifr_private {
inbox = yes
location =
prefix =
separator = .
}
namespace mpifr_shared {
inbox = no
list = children
location = mdbox:/var/mail/%%n/maildrop
prefix = shared.%%n.
separator = .
subscriptions = no
type = shared
}
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
plugin {
acl = vfile
acl_defaults_from_inbox = yes
acl_shared_dict = proxy::acl
mail_replica = tcp:192.168.42.173:50222
sieve = ~/.dovecot.sieve
sieve_after = /var/mail/global-after.sieve
sieve_dir = ~/sieve
sieve_extensions = +notify +imapflags
sieve_global_dir = /var/mail
zlib_save = gz
zlib_save_level = 6
}
protocols = imap lmtp sieve pop3
replication_dsync_parameters = -d -l 30 -U -n mpifr_private -n mpifr_shared
replication_max_conns = 6
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service anvil {
client_limit = 8192
}
service auth {
client_limit = 8192
unix_listener auth-userdb {
group = vmail
user = vmail
}
}
service dict {
unix_listener dict {
group = vmail
user = vmail
}
}
service doveadm {
inet_listener {
address = 192.168.42.105
port = 50222
}
}
service imap-login {
process_min_avail = 5
service_count = 1
}
service imap {
vsz_limit = 512 M
}
service indexer-worker {
client_limit = 1
process_limit = 10
user = root
}
service lmtp {
inet_listener lmtp {
address = 134.104.18.105
port = 24
}
}
service managesieve-login {
inet_listener sieve {
address = 134.104.18.77
port = 4190
}
service_count = 1
}
service pop3-login {
process_min_avail = 5
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0666
}
}
ssl = required
ssl_cert = /etc/dovecot/imap.pem
ssl_cipher_list = ALL:HIGH:!SSLv2:!LOW:!EXP:!RC4:!MD5:!aNULL
ssl_key = /etc/dovecot/private/imap.key
ssl_protocols = !SSLv2 !SSLv3
userdb {
args = /etc/dovecot/dovecot-ldap-userdb.conf.ext
driver = ldap
}
verbose_proctitle = yes
protocol lmtp {
mail_plugins = acl zlib notify replication sieve
}
protocol imap {
imap_client_workarounds = tb-lsub-flags
mail_max_userip_connections = 20
mail_plugins = acl zlib notify replication imap_acl imap_zlib
ssl_cert = /etc/dovecot/imap.pem
ssl_key = /etc/dovecot/private/imap.key
}
protocol pop3 {
ssl_cert = /etc/dovecot/pop3.pem
ssl_key = /etc/dovecot/private/imap.key
}
smime.p7s
Description: S/MIME cryptographic signature
Re: gssapi considered as PLAIN?
On Wed, 2014-11-05 at 16:52 +0100, Harry Schmalzbauer wrote:
Bezüglich Hans Morten Kind's Nachricht vom 05.11.2014 16:48 (localtime):
On Wed, Nov 05, 2014 at 04:22:12PM +0100, Harry Schmalzbauer wrote:
as soon as I set disable_plaintext_auth = yes, AUTH=GSSAPI vanishes
from capabilities.
Try setting login_trusted_networks to something you trust.
root@mailbox1:/etc/dovecot/conf.d# doveconf auth_mechanisms
auth_mechanisms = plain login gssapi
root@mailbox1:/etc/dovecot/conf.d# doveconf disable_plaintext_auth
disable_plaintext_auth = yes
root@mailbox1:/etc/dovecot/conf.d# doveconf login_trusted_networks
login_trusted_networks =
a CAPABILITY
* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
AUTH=PLAIN AUTH=LOGIN AUTH=GSSAPI
Must be something else ...
Check my attached config for differences.
Cheer Jan
--
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
Auf dem Huegel 69, D-53121 Bonn
Tel: +49 (228) 525 359, Fax: +49 (228) 525 229
jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de
# 2.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.7 xfs
auth_gssapi_hostname = imap.mpifr-bonn.mpg.de
auth_krb5_keytab = /etc/krb5-ha.keytab
auth_mechanisms = plain login gssapi
auth_verbose = yes
default_process_limit = 1024
default_vsz_limit = 512 M
dict {
acl = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
doveadm_password = xxx
doveadm_port = 50222
listen = 134.104.18.77
lmtp_save_to_detail_mailbox = yes
mail_location = mdbox:/var/mail/%Ln/maildrop
mail_plugins = acl zlib notify replication
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 ihave imapflags notify
mdbox_rotate_size = 10 M
namespace mpifr_private {
inbox = yes
location =
prefix =
separator = .
}
namespace mpifr_shared {
inbox = no
list = children
location = mdbox:/var/mail/%%n/maildrop
prefix = shared.%%n.
separator = .
subscriptions = no
type = shared
}
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
plugin {
acl = vfile
acl_defaults_from_inbox = yes
acl_shared_dict = proxy::acl
mail_replica = tcp:192.168.42.173:50222
sieve = ~/.dovecot.sieve
sieve_after = /var/mail/global-after.sieve
sieve_dir = ~/sieve
sieve_extensions = +notify +imapflags
sieve_global_dir = /var/mail
zlib_save = gz
zlib_save_level = 6
}
protocols = imap lmtp sieve pop3
replication_dsync_parameters = -d -l 30 -U -n mpifr_private -n mpifr_shared
replication_max_conns = 6
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service anvil {
client_limit = 8192
}
service auth {
client_limit = 8192
unix_listener auth-userdb {
group = vmail
user = vmail
}
}
service dict {
unix_listener dict {
group = vmail
user = vmail
}
}
service doveadm {
inet_listener {
address = 192.168.42.105
port = 50222
}
}
service imap-login {
process_min_avail = 5
service_count = 1
}
service imap {
vsz_limit = 512 M
}
service indexer-worker {
client_limit = 1
process_limit = 10
user = root
}
service lmtp {
inet_listener lmtp {
address = 134.104.18.105
port = 24
}
}
service managesieve-login {
inet_listener sieve {
address = 134.104.18.77
port = 4190
}
service_count = 1
}
service pop3-login {
process_min_avail = 5
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0666
}
}
ssl = required
ssl_cert = /etc/dovecot/imap.pem
ssl_cipher_list = ALL:HIGH:!SSLv2:!LOW:!EXP:!RC4:!MD5:!aNULL
ssl_key = /etc/dovecot/private/imap.key
ssl_protocols = !SSLv2 !SSLv3
userdb {
args = /etc/dovecot/dovecot-ldap-userdb.conf.ext
driver = ldap
}
verbose_proctitle = yes
protocol lmtp {
mail_plugins = acl zlib notify replication sieve
}
protocol imap {
imap_client_workarounds = tb-lsub-flags
mail_max_userip_connections = 20
mail_plugins = acl zlib notify replication imap_acl imap_zlib
ssl_cert = /etc/dovecot/imap.pem
ssl_key = /etc/dovecot/private/imap.key
}
protocol pop3 {
ssl_cert = /etc/dovecot/pop3.pem
ssl_key = /etc/dovecot/private/imap.key
}
smime.p7s
Description: S/MIME cryptographic signature
Re: gssapi considered as PLAIN?
On Wed, 2014-11-05 at 17:04 +0100, Harry Schmalzbauer wrote: Bezüglich Jan Behrend's Nachricht vom 05.11.2014 17:01 (localtime): On Wed, 2014-11-05 at 16:52 +0100, Harry Schmalzbauer wrote: Bezüglich Hans Morten Kind's Nachricht vom 05.11.2014 16:48 (localtime): On Wed, Nov 05, 2014 at 04:22:12PM +0100, Harry Schmalzbauer wrote: as soon as I set disable_plaintext_auth = yes, AUTH=GSSAPI vanishes from capabilities. Try setting login_trusted_networks to something you trust. root@mailbox1:/etc/dovecot/conf.d# doveconf auth_mechanisms auth_mechanisms = plain login gssapi root@mailbox1:/etc/dovecot/conf.d# doveconf disable_plaintext_auth disable_plaintext_auth = yes root@mailbox1:/etc/dovecot/conf.d# doveconf login_trusted_networks login_trusted_networks = a CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN AUTH=GSSAPI You don't see LOGINDISABLED, so I guess rip==lip (you tested @localhost), right? No, but I didn't show all of it ;-). Here it is: jbehrend@jb1:~$ gnutls-cli --starttls --x509cafile /etc/ssl/certs/Max-Planck-Gesellschaft.pem -p 143 imap.mpifr-bonn.mpg.de Processed 1 CA certificate(s). Resolving 'imap.mpifr-bonn.mpg.de'... Connecting to '134.104.18.77:143'... - Simple Client Mode: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready. a starttls a OK Begin TLS negotiation now. *** Starting TLS handshake - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1023 bits - Peer's public key: 1023 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `C=DE,ST=Nordrhein-Westfalen,L=Bonn,O=Max-Planck-Gesellschaft,OU=Max-Planck-Institut fuer Radioastronomie,CN=imap.mpifr-bonn.mpg.de', issuer `C=DE,O=Max-Planck-Gesellschaft,CN=MPG CA,EMAIL=mpg...@mpg.de', RSA key 4096 bits, signed using RSA-SHA1, activated `2014-05-06 11:17:21 UTC', expires `2019-05-05 11:17:21 UTC', SHA-1 fingerprint `c0b4fb497ac212f0e05de24f2c097a0b712435cc' - The hostname in the certificate matches 'imap.mpifr-bonn.mpg.de'. - Peer's certificate is trusted - Version: TLS1.2 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL a CAPABILITY * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN AUTH=GSSAPI a OK Pre-login capabilities listed, post-login capabilities have more. Cheers Jan -- MAX-PLANCK-INSTITUT fuer Radioastronomie Jan Behrend - Rechenzentrum Auf dem Huegel 69, D-53121 Bonn Tel: +49 (228) 525 359, Fax: +49 (228) 525 229 jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de smime.p7s Description: S/MIME cryptographic signature
sieve replication and .dovecot.lda-dupes
Hello list,
I have a replicated dovecot with two servers.
People seem to get vacation responses more often then it is specified in
days: XX, depending on which dovecot instance they receive the
incoming mail. Is .dovecot.lda-dupes replicated?
The other problem is that the vacation response is coming from the wrong
address depending on which field the recipient was listed: to: or
cc:
Here is my test example:
g9-rz has the vacation rule set up:
date | mail -s test -r jbehr...@mpifr-bonn.mpg.de -c
g9...@mpifr-bonn.mpg.de j...@flatpick.de
and this returns this vacation response:
### snip ###
Return-Path:
Delivered-To: jbehr...@mpifr-bonn.mpg.de
Received: from mail2.mpifr-bonn.mpg.de ([134.104.18.60]) by
mailbox2.mpifr-bonn.mpg.de (Dovecot) with LMTP id
+pgPDzm1WFSn9wAAvl5QjA
for jbehr...@mpifr-bonn.mpg.de; Tue, 04 Nov 2014 12:16:13 +0100
X-Sieve: Pigeonhole Sieve 0.4.2
Message-ID:
dovecot-sieve-1415099773-54151...@mailbox1.mpifr-bonn.mpg.de
Date: Tue, 04 Nov 2014 12:16:13 +0100
From: j...@flatpick.de
To: jbehr...@mpifr-bonn.mpg.de
Subject: Vacation
In-Reply-To: e1xlc5t-0001lt...@jb1.mpifr-bonn.mpg.de
References: e1xlc5t-0001lt...@jb1.mpifr-bonn.mpg.de
Auto-Submitted: auto-replied (vacation)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Evolution-Source: 1385020682.6450.3@jb1
Ain't here! Go away or something ...
Cheers
### snip ###
I would expect g9...@mpifr-bonn.mpg.de in the from: field. Is this
correct?
Cheers Jan
--
MAX-PLANCK-INSTITUT fuer Radioastronomie
Jan Behrend - Rechenzentrum
Auf dem Huegel 69, D-53121 Bonn
Tel: +49 (228) 525 359, Fax: +49 (228) 525 229
jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de
# 2.2.13: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.7 xfs
auth_gssapi_hostname = imap.mpifr-bonn.mpg.de
auth_krb5_keytab = /etc/krb5-ha.keytab
auth_mechanisms = plain login gssapi
auth_verbose = yes
default_process_limit = 1024
default_vsz_limit = 512 M
dict {
acl = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
doveadm_password = xxx
doveadm_port = 50222
listen = 134.104.18.77
lmtp_save_to_detail_mailbox = yes
mail_location = mdbox:/var/mail/%Ln/maildrop
mail_plugins = acl zlib notify replication
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 ihave imapflags notify
mdbox_rotate_size = 10 M
namespace mpifr_private {
inbox = yes
location =
prefix =
separator = .
}
namespace mpifr_shared {
inbox = no
list = children
location = mdbox:/var/mail/%%n/maildrop
prefix = shared.%%n.
separator = .
subscriptions = no
type = shared
}
passdb {
args = /etc/dovecot/dovecot-ldap-passdb.conf.ext
driver = ldap
}
plugin {
acl = vfile
acl_defaults_from_inbox = yes
acl_shared_dict = proxy::acl
mail_replica = tcp:192.168.42.173:50222
sieve = ~/.dovecot.sieve
sieve_after = /var/mail/global-after.sieve
sieve_dir = ~/sieve
sieve_extensions = +notify +imapflags
sieve_global_dir = /var/mail
zlib_save = gz
zlib_save_level = 6
}
protocols = imap lmtp sieve pop3
replication_dsync_parameters = -d -l 30 -U -n mpifr_private -n mpifr_shared
replication_max_conns = 6
service aggregator {
fifo_listener replication-notify-fifo {
user = vmail
}
unix_listener replication-notify {
user = vmail
}
}
service anvil {
client_limit = 8192
}
service auth {
client_limit = 8192
unix_listener auth-userdb {
group = vmail
user = vmail
}
}
service dict {
unix_listener dict {
group = vmail
user = vmail
}
}
service doveadm {
inet_listener {
address = 192.168.42.105
port = 50222
}
}
service imap-login {
process_min_avail = 5
service_count = 1
}
service imap {
vsz_limit = 512 M
}
service indexer-worker {
client_limit = 1
process_limit = 10
user = root
}
service lmtp {
inet_listener lmtp {
address = 134.104.18.105
port = 24
}
}
service managesieve-login {
inet_listener sieve {
address = 134.104.18.77
port = 4190
}
service_count = 1
}
service pop3-login {
process_min_avail = 5
}
service replicator {
process_min_avail = 1
unix_listener replicator-doveadm {
mode = 0666
}
}
ssl = required
ssl_cert = /etc/dovecot/imap.pem
ssl_cipher_list = ALL:HIGH:!SSLv2:!LOW:!EXP:!RC4:!MD5:!aNULL
ssl_key = /etc/dovecot/private/imap.key
ssl_protocols = !SSLv2 !SSLv3
userdb {
args = /etc/dovecot/dovecot-ldap-userdb.conf.ext
driver = ldap
}
verbose_proctitle = yes
protocol lmtp {
mail_plugins = acl zlib notify replication sieve
}
protocol imap {
imap_client_workarounds = tb-lsub-flags
mail_max_userip_connections = 20
mail_plugins = acl zlib notify replication imap_acl imap_zlib
ssl_cert = /etc/dovecot/imap.pem
ssl_key
Re: Question wrt. dovecot replicator
On Fri, 2014-10-10 at 14:45 +0200, Jan Behrend wrote: On Fri, 2014-10-03 at 23:37 +0200, Remko Lodder wrote: How can I determine why there are duplicated emails? Same problem here! What kind of messages should I specifically look for? Look for any errors and warnings in the Dovecot log. You could also enable mail_debug (ref. Can I set this up for a few selected accounts instead of all accounts like it was currently? To make sure I do not make things worse for others then needs to be :-) The service had been disabled for the time being to prevent the other users from getting duplicated emails. I do not know what kind of userdb you are running, but there is a newish patch that enables per user replication via the mail_replica setting. It is not yet included in the newest (2.2.13) release of Dovecot, but is available via the enterprise version. There are no FreeBSD builds for that, though. ref: http://hg.dovecot.org/dovecot-2.2/rev/c1c67bdc8752 my userdb consists of local users (Which are fed through LDAP at the backend). perhaps I can setup a mailAttributes setting or something so that the replica can be set, although I prefer that I have control over that in the config itself :-) With the latest Debian jessie version 1:2.2.13-5 you can actually have a per user mail_replica setting taken from a (LDAP) directory. This keeps the duplicate mail issue away from other users but a few willing to test ... For what it’s worth: replication_dsync_parameters = -f -d -N -l 30 -U I read in Peer Heinlein's Dovecot book http://www.opensourcepress.de/de/produkte/Dovecot/13560/978-3-95539-074-7 that replicating a public namespace gives you trouble :-(. So keep the -N option away for now. However I would like examples for the -n and -x options, which are neither given in the wiki nor in the nonexistant man page. I think the replication feature is very, very cool, but right now it gives me a hard time to implement flawlessly ;-) Thanks for any help or light shed on this issue ... Found it ;-) http://wiki2.dovecot.org/Tools/Doveadm/Sync All working beautifully now! Cheers Jan -- MAX-PLANCK-INSTITUT fuer Radioastronomie Jan Behrend - Rechenzentrum Auf dem Huegel 69, D-53121 Bonn Tel: +49 (228) 525 359, Fax: +49 (228) 525 229 jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de smime.p7s Description: S/MIME cryptographic signature
Re: Question wrt. dovecot replicator
On Fri, 2014-10-03 at 23:37 +0200, Remko Lodder wrote: How can I determine why there are duplicated emails? Same problem here! What kind of messages should I specifically look for? Look for any errors and warnings in the Dovecot log. You could also enable mail_debug (ref. Can I set this up for a few selected accounts instead of all accounts like it was currently? To make sure I do not make things worse for others then needs to be :-) The service had been disabled for the time being to prevent the other users from getting duplicated emails. I do not know what kind of userdb you are running, but there is a newish patch that enables per user replication via the mail_replica setting. It is not yet included in the newest (2.2.13) release of Dovecot, but is available via the enterprise version. There are no FreeBSD builds for that, though. ref: http://hg.dovecot.org/dovecot-2.2/rev/c1c67bdc8752 my userdb consists of local users (Which are fed through LDAP at the backend). perhaps I can setup a mailAttributes setting or something so that the replica can be set, although I prefer that I have control over that in the config itself :-) With the latest Debian jessie version 1:2.2.13-5 you can actually have a per user mail_replica setting taken from a (LDAP) directory. This keeps the duplicate mail issue away from other users but a few willing to test ... For what it’s worth: replication_dsync_parameters = -f -d -N -l 30 -U I read in Peer Heinlein's Dovecot book http://www.opensourcepress.de/de/produkte/Dovecot/13560/978-3-95539-074-7 that replicating a public namespace gives you trouble :-(. So keep the -N option away for now. However I would like examples for the -n and -x options, which are neither given in the wiki nor in the nonexistant man page. I think the replication feature is very, very cool, but right now it gives me a hard time to implement flawlessly ;-) Thanks for any help or light shed on this issue ... Cheers Jan -- MAX-PLANCK-INSTITUT fuer Radioastronomie Jan Behrend - Rechenzentrum Auf dem Huegel 69, D-53121 Bonn Tel: +49 (228) 525 359, Fax: +49 (228) 525 229 jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Re: Dovecot writing to mailbox user@domain
Hi John,
I'm guessing your problem is:
mail_location = maildir:/var/vmail/%u/Maildir
%u means 'username', and perhaps this serves you better:
%n: User part in user@domain, same as %u if there's no domain.
so:
mail_location = maildir:/var/vmail/%n/Maildir
I've had this same problem too
MJ
On 10/06/2014 06:38 PM, John Oliver wrote:
centOS 6.5, dovecot-2.0.9-7.el6_5.1.x86_64
This is frustrating, because I had it working before... I could deliver
an email to a user user@domain, then connect to dovecot IMAP and see the
mail, no problem! Then I was told we had to use cyrus, and I was
dealing with it for a few weeks. Now we're back to dovecot, and the
last backup I had of that config has postfix delivering mail to
/var/vmail/username as I want and expect, but dovecot looks for and
creates /var/vmail/user@domain which I DON'T want
[joliver@test ~]$ dovecot -n
# 2.0.9: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-431.el6.x86_64 x86_64 CentOS release 6.5 (Final) ext4
auth_username_format = %Lu
mail_access_groups = mail
mail_location = maildir:/var/vmail/%u/Maildir
mail_privileged_group = mail
mbox_write_locks = fcntl
passdb {
driver = pam
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf.ext
driver = ldap
}
protocols = imap
ssl_cert = /etc/pki/dovecot/certs/dovecot.pem
ssl_key = /etc/pki/dovecot/private/dovecot.pem
userdb {
driver = passwd
}
userdb {
args = uid=504 gid=505 home=/var/vmail/%u
driver = static
}
[joliver@test ~]$ cat /etc/dovecot/dovecot-ldap.conf.ext
hosts = localhost
auth_bind = no
ldap_version = 3
debug_level = 0
default_pass_scheme = SSHA
base = ou=Users,dc=test,dc=com
scope = subtree
pass_filter = ((objectClass=user)(uid=%u))
pass_attrs = mail=user,userPassword=password
Re: ot: accepting self certs into win pc?
Hi Frank, list, On 6/10/2014 3:10, Frank Leonhardt wrote: I get endless grief over this, but if you think Microsoft is bad, try Apple. I wrote some notes on it once: http://blog.frankleonhardt.com/2012/certificate-errors-on-internet-explorer-9-and-how-to-stop-them/ I didn't mention it in the post, but IIRC this did work for making some versions Outlook (and other Microsoft Mail things) happy at the same time. But do the above steps work for folks here..? I've tried them (IE 11, win7, outlook 2013) but outlook keeps asking about (self signed) imaps certificates. Is it just me who cannot import self-signed certificates into microsoft products anymore? MJ
Re: ot: accepting self certs into win pc?
Apologies. I noticed only now that the certificate was issued for the real servername, and I'm using a dns alias to connect. Sorry. On 6/11/2014 10:56, mourik jan heupink - merit wrote: Hi Frank, list, On 6/10/2014 3:10, Frank Leonhardt wrote: I get endless grief over this, but if you think Microsoft is bad, try Apple. I wrote some notes on it once: http://blog.frankleonhardt.com/2012/certificate-errors-on-internet-explorer-9-and-how-to-stop-them/ I didn't mention it in the post, but IIRC this did work for making some versions Outlook (and other Microsoft Mail things) happy at the same time. But do the above steps work for folks here..? I've tried them (IE 11, win7, outlook 2013) but outlook keeps asking about (self signed) imaps certificates. Is it just me who cannot import self-signed certificates into microsoft products anymore? MJ
Re: ot: accepting self certs into win pc?
Hi Frank, list, There is an option to fiddle (mentioned in the blog) to tell SOME MS software to ignore name mismatches. Make a wish and try it :-) True, but: Unfortunately it’s either on or off; you can’t set it to ignore a mis-match for particular names only. Because of the risk that someone might be impersonating your bank, you’d probably be best to leave this one checked and put up with the red warnings. So I think I'll just regenerate my certificate to match the hostname alias we use, instead of the actual hostname. Anyway: your blog is appreciated, thank you! :-)
[Dovecot] Move of mail folders to other mail account on same server
Hi, I'd like to move mail folders from one mail account to another mail account on the same server. Moving the folders via my mail client (Thunderbird) takes a long time. Therefore I wondered whether it's not possible to simply move the files on the server itself. If I unsubscribe to the folders in my source account, then move the folder and subscribe to the folders in my target account: will that work? I run dovecot version 2.1.15 Thanks a lot, Jan
Re: [Dovecot] Zlib plugin - when does it make sense?
On Mon, Nov 25, 2013 at 09:53:14AM +0100, Frerich Raabe wrote: I run a small IMAP server for a dozen guys in the office, serving about 55GB of Maildir. I recently became aware of the Zlib plugin ( http://wiki2.dovecot.org/Plugins/Zlib ) and wondered 1. given that there is about zero CPU load on my IMAP server, is enabling the plugin a no-brainer or are there other things (except CPU load) to consider? Yes, it's a no-brainer. I can't remember how the cpuload was before we enabled zlib, but our cpus are running 80% idle (6 servers, mix of IBM x3550 and x346, serving 15TB mdbox, but was serving maildir with zlib a year ago). 2. For enabling the plugin, I suppose you compress all the existing mail just once and then add 'zlib' to mail_plugins in order to have all future incoming mail saved? You don't strictly need to compress existing mail. It should handle a mix of compressed and non-compressed messages in the same maildir. -jf
Re: [Dovecot] Zlib plugin - when does it make sense?
On Mon, Nov 25, 2013 at 02:47:33PM +0100, Frerich Raabe wrote:
Interesting! What zlib compression level did you use? I figure even low
levels would work rather well for plain text.
plugin {
zlib_save_level = 6 # 1..9
zlib_save = gz # or bz2
}
Now that I think about plain text: I also have the fts_solr plugin
enabled to speed up the occasional full-text search - does the indexing
still work as before when the mail is compressed, i.e. is the
reading of the mail centralized so that the individual plugins don't
actually know or care? Or would I need to make sure I use
'zlib-aware' plugins?
I don't have fts (yet).
-jf
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 19.11.2013 16:22, schrieb Timo Sirainen: Maybe http://hg.dovecot.org/dovecot-2.2/rev/5f946b807706 solves this also? I’m not sure why it started happening with v2.2.7 though. Hi Timo, Is this patch included in v2.2.8? I will still wait for a v2.2.8 stable-build on xi.rename-it.nl. Best regards Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSjKCEAAoJENEKhqzzuxPl/moH/32ob9kzWYrpBihUGYSx9p/V Bk4z3I2FGc3Mvq2WKkZ9+82KoJ2PZAOn7Z16g0J6MLTyjVuSdluj2HZRNRVgLNaY 58cnp9BfrBDFa8ZAQ3a1L6/p4JH522NiihDO0l1q7x5sLRsBvgMPuC5GHhXPt/sQ H1gaymLQST4PBH+0xNuh3a7AWH//vCN3eGcSthj2HFg04JyOh+KUqiLO8SgggqQp QLL6cnSlNFBCVbNxdw0I3tsReDHExNXTF+PukDoZEt3lYtEPs9VbiIm3UrY6XqfA z+ELS4lcJHbBhsFCqjDLS9PmQoyDwaCImQER0lp0ZwXgsUlum4UYGJTU/LselAY= =nHaC -END PGP SIGNATURE-
Re: [Dovecot] highly available userdb
On Wed, Nov 13, 2013 at 01:52:09PM +1000, Nick Edwards wrote: On 11/12/13, Jan-Frode Myklebust janfr...@tanso.net wrote: My installation is only serving 1/10 of your size, but long time ago we migrated off mysql for userdatabase, and over to LDAP. The MySQL data source had issues (not dovecot related), and didn't seem like the right tool for the job. A database is a database, a master is a master, and a slave is a slave And some databases are better for some tasks than others. F.ex. LDAP gives dovecot free failover between servers. Handled in the ldap libraries. One could argue that you should be complaining to the MySQL developers about supporting server failover in the client library, and not to Dovecot. our mysql has never had problem, not a single one, its why I'm so annoyed dovecot is talking to master when it doesn't need to -jf
Re: [Dovecot] Dovecot MTA
On Fri, Nov 08, 2013 at 04:22:13PM +0100, Timo Sirainen wrote: Ah, I had actually been mostly just thinking about inbound SMTP features. It should of course support outbound SMTP as well, but I’m less familiar about what functionality would be useful for that. Outbound is mostly the same as inbound, except requirement of authentication and TLS for the submission (587/tcp) and ssl wrapped smtps port 465/tcp. Features we'd want: * authentication * per user rate limiting might be handled by Dovecot MTA instead of external program? * spam filtering trough milter? * virus filtering trough milter? * Per user Geo-blocking would be great! * Protection from password guessing ? Plus it would be great if it could check if the authentication is still valid when re-using connection, ref missing feature in postfix: http://postfix.1071664.n5.nabble.com/Solution-to-SMTPAuth-compromised-accounts-td61415.html -jf
Re: [Dovecot] Dovecot MSA - MTA
On Sun, Nov 10, 2013 at 12:59:27AM +0100, Reindl Harald wrote: everywhere else you have sender-dependent relay hosts, RCPT dependent relayhosts and all sort of aliases which you *do not* want treated different between incoming mail from outside or a internal server and submission mail the only real difference between submission is that it is authenticated and because the authentication a few restrictions are not applied I don't quite agree. Our smarthosts has very little local knowledge about where to route messages. They only follow MX records. It's the incoming SMTP servers that has all the knowledge, and needs to be robust against millions of broken mailservers and spam-bots on the internet. The fact that submission is authenticated is an opportunity to integrate better with the userdb than postfix and exim does. To have native quotas, brute-force protection, per user geo-blocking, etc.. that are difficult to achieve with the general SMTP servers. but in usual there is and must not be any difference in the mail-routing Incoming SMTP servers routes to dovecot-LMTP, internal exchange, and more. Outgoing would only need to follow MX (even for messages heading back home to us). -jf
Re: [Dovecot] server side private/public key
Serverside private key probably doesn't protect against much, but a way for users to upload a public key and automatically encrypt all messages when received might have value. Limits exposure for messages at rest. -jf Den 11. nov. 2013 kl. 15:21 skrev Peter Mogensen a...@one.com: *Christian Felsing wrote: * Please consider to add server side private/public key encryption for incoming mails. If client logs on, the password is used to unlock users server side private key. If mail arrives from MTA or any other source, mail is encrypted with users public key. Key pair should be located in LDAP or SQL server. PGP and S/MIME should be supported. This is for the situation if NSA or other organizations asks admin for users mail insistently, So ... exactly which security threat are you thinking about preventing here? This won't protect against: * NSA listening in on the mails when they arrive. * NSA taking a backup of your mails and wait for your first attempt to read them - at which time they'll have your private key in plain text. It seems like a much wider protection to just keep you private key for your self. /Peter
Re: [Dovecot] highly available userdb (Was: Re Dovecot MTA)
My installation is only serving 1/10 of your size, but long time ago we migrated off mysql for userdatabase, and over to LDAP. The MySQL data source had issues (not dovecot related), and didn't seem like the right tool for the job. Initially we kept mysql as the authoritative database over our users, and mirrored the user details over to LDAP/389ds -- which we pointed dovecot and postfix to. Then eventually we migrated completely out of MySQL as user database. LDAP/389ds gives us easy multimaster replication, easy integration with dovecot, postfix, etc., client side support for failover between servers, and it is very fast. I don't think we've ever had any issue with the userdb after migrating to LDAP. our two 389ds servers are doing about 80 ldap bind() authentications per second (plus dovecot auth cache is masking a lot more), 300 searches/s and are using about 20% of a single cpu core each. So, I would very much recommend you look into if something similar can work for you. -jf On Mon, Nov 11, 2013 at 03:24:46PM +1000, Edwardo Garcia wrote: My company have 36 dovecots, one biggest ISP in country 3 million user, agree with Nick poster, we had stop use dovecot load balance because too bad effect on primary database, now use single localhost, we have script run every 30 second to test login, if fail sleep 30 second, try again, fail and down ethernet interface so hardware load balancer see server not answer and can not use, nagios soon tell us of problem, very very bad and stupid way, but only option is safe, we have look at alternative to dovecot for this and still look, not happy with unreliable softwares to immitate feature. big network mean big time locate and fix problem when arise so you be good to say no extra point of failure. Too many cog in chain eventually lead to problem. Timo pleaz reconsider feature On Sun, Nov 10, 2013 at 4:21 PM, Nick Edwards nick.z.edwa...@gmail.comwrote: On 11/9/13, Timo Sirainen t...@iki.fi wrote: On 9.11.2013, at 5.11, Nick Edwards nick.z.edwa...@gmail.com wrote: On 11/9/13, Michael Kliewe mkli...@gmx.de wrote: Hi Timo, I would also, like others, see you mainly working on Dovecot as an IMAP server. As far as I can see there are many things on the roadmap, and I hope many more will be added (for example a built-in health-checker for director backends). Only if you have enough personal resources and Dovecot as an IMAP server will not loose your attention, I would love to see your expertise in making a better MTA. Yes, some of us have been waiting for some years now, for a configurable change to alter the method of dovecots method of failover, which is just load balancing between servers rather than true failover, like postix, I see now why it gets no importance. Ah, you’re talking about SQL connections. Had to look up from old mails what you were talking about. It hasn’t changed, because I think the current behavior with load balancing + failover is more useful than failover-only. And you can already do failover-only with an external load balancer. Sure, Dovecot could also implement it, but it’s not something I especially want to spend time on implementing. My employer has 18 pop3 servers, one imap customer access (imap here has so little use we cant justify a redundant machine, not for 11, yes, eleven only users after 2 years of offering imap , and 2 imap (webmail). Sp, each server has a replicated mysql database If I use your better method, I have 18 machines polling themselves and the MASTER server, this needlessly slams the daylights out of the master as I'm sure even you can imagine. We have 4 customer relay smtp servers and 4 inbound smtp servers, postifx, using its failover and better method, means they only hit the master server when the local mysql unix socket is not listening, ie, mysqld is stopped - the master server NEVER sees them. How is your method, better than true failover like method used by postfix, your methods is load balancing, it is not failover, and causes problems on larger networks I'm sure in some cases most people using it are happy and wont have performance increases noticeable, but if you are going to offer a backup for auth, it really shoulds be able to configure, if we want it to DoS our master, or only talk to master when it cant talk local, so I think it should be matter you need to consider, else you are only half arsed doing it, and like implying we should go introduce a further point of failure, by using yet more third party softwares
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.11.2013 19:30, schrieb Michael Grimm: Timo Sirainen t...@iki.fi wrote: Sorry, but neither my log files starting a week ago ... More interesting would be to know if you see ANY error/warning messages in Dovecot logs (Fatal, Panic, Error, Warning). ... nor ... You’ll also see the last 1000 error messages since dovecot started with “doveadm log errors”. ... show any messages, none. This is 2.2.7 (775b1e025939). Regards, Michael Same here, no errors or any logs. Only since 2.2.7. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSfKnPAAoJENEKhqzzuxPlWb8H/05dv4jQASaIYyKUi5CPRpNO /TXkUKBwqOVgGBo5mxW06ppfao6zICfEYQUS+Xk131CugXkfamCiFaZD/lHaa5ib dOz8wGuJuuZ9VXw4+J4GXpAIcxhV9OFNibehzpeHTmFe/1SmtS3iHoan85hHNqc6 cDcdCet7fF56yYBGcGNCf1uQvCxgVWcvKZ2QkyP6MfoOay8g88J1V+Di9iJTJzXz 9899lcWl8w2I6vUaexaw2o63s19POsjLHVbx7BPvDtF0ohG960yfGxIJ7qDTX3Kn D0AOIUanmsGgdXifUudJlMfh2KKAXuOhgHYa5ODM42g+8QNSKRddmQla5ARoSqw= =RPY6 -END PGP SIGNATURE-
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Additional note: Downgrade impossible because http://xi.rename-it.nl/debian/ didn't have the 2.2.6 packages anymore. :( -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSe0hjAAoJENEKhqzzuxPljrwH/0GGwoFVPZVEfqvM0QuvRduB qCu1MtscKaiSyaXp5m5I2kfZ0TJL1BcARMGEjeDaCULQf6Z3v197EDHCto9VL0eT acUCC1YnbKKiTmkETvIFP2zZwmkthur6hOOmGWn02SDvpIdiPq0nKMaD8fxTnETd r4dafw8fkTpEJXiEHk9AZv9xcTOdEbZz66gNb0gN3hNs5+uVF1wjznv1JfnFys1u JSufXKBmmASBzPqTsMmEJ9KT+IFEDzH5GWWo0RD15RgF8Lpr883XWfmX3WjK8Tbw Mbwfr+PinkAJ/B1DflzaIWfklNXReh298WdcUAZVL0aT9/Cg7xicHQ5RBrGhBl4= =kjqG -END PGP SIGNATURE-
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Steffen, no other logs. :-/ That's even the only one with lmtp-debug-messages, now all log entries look like that: http://pastebin.com/raw.php?i=zFeC9Ncr I want to make a workaround in postfix like rewrite jg+*@larptreff.de - j...@larptreff.de but I can't find a solution for relay-domains. (sending my mails via relay-domain to dovecot) Regards Jan Am 07.11.2013 09:47, schrieb Steffen Kaiser: On Thu, 7 Nov 2013, Jan Phillip Greimann wrote: maillog: http://pastebin.com/WDGfEjdp are there some other log files, too? In it one sees that the recipient jg+introvers...@larptreff.de is successfully interpreted as j...@larptreff.de and data seems to be good as well: maildir++: root=/var/vmail/larptreff.de/jg/Maildir, index=, indexpvt=, control=, inbox=/var/vmail/larptreff.de/jg/Maildir But I don't see any log entry about that a deliviery has been tried at all. -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSe1l0AAoJENEKhqzzuxPl+msIAJ6EuLwig/M1G4XS7hUSvnjH /KtJYVF6Ove3a1iWqVyYk2DIxgJBDcyjJwmw+U6pjnoDxap1p+sgVpgcLwTBvV7v GVbwFNfoGKjarSVYAknH0LiLzw0DUCItzt2Ga7mU4ngeTopPnSK0Qvu0hMF1lnu+ HpHmwyJZC40A1d0BewoIciK6/R9ZFLsc325sShn8sFz77pWGyC0VR/tJ2Q0qKLcQ Yr8Fhs/+nsOkrkTxEJvhHJNaxnsnO2PBupKe57YOCl+awTlPbtIcpOJnqVgfKznO j5+qua0nPaifHTpmz7DCKlFAdM3jv25HQ6Ow0Nr6rE0cVftFs1GWjUWyDUDXB+o= =Dy+Z -END PGP SIGNATURE-
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.11.2013 10:32, schrieb Steffen Kaiser: On Thu, 7 Nov 2013, Jan Phillip Greimann wrote: That's even the only one with lmtp-debug-messages, now all log entries look like that: http://pastebin.com/raw.php?i=zFeC9Ncr is this some sort of LMTP ahead to probe the recipient? Greylisting perhaps with local recipients? Does decided action=PREPEND X-policyd-weight: using cached result; mean that no action has been performed, but the negative result cached already will be returned. Do you have a corresponding lmtp log entry? I've enabled dovecots debug-log after the problems happened, so there are no corresponding lmtp logs. To test LMTP try this: telnet to your LMTP port, or for an Unix socket: socat - UNIX:/var/run/dovecot/lmtp Then speak LMTP: LHLO loc mail from:bounce-mc.us5_9954939.11045-jg+introversion=larptreff...@mail33.wdc03.rsgsv.net rcpt to:jg+introvers...@larptreff.de quit and without the +detail in rcpt to. If you get to enter the QUIT without losing you connection, your postfix log entry does not makes sense to me. 2xx responses are successful, 4xx temporary error, 5xx errors. You should not see no other resonse codes. Okay, the log entries make no sense at all it seems. With socat it works like charm. See the Dovecot log and probably monitor the system for an abort or segfault of a Dovecot LMTP process. As far as I see there are no segfaults. Postfix and dovecot are logging to syslog -- mail.log, and there is only the given output. Regards Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSe2LAAAoJENEKhqzzuxPllZUH/jm3eCAPMhnmGShj1V0qwZnA YbmrEfLBjqm8Yh3KMhmyzZLDF6wkv4JEFJJGpeHlfQ1yRuHb7QZ0/z0hVceQCkOp JSv7+o9QWurRMbQmcu/CzL5JFz2p9SLN4vRReAgXWmavCazwzgnzeoDzf705rajy 2rMlwwLn0VGVAykFP0IHTLL+ldWaCCur0A98mHe3lKeK9OOGbBrrdDoW+VSMQVUi x60vBHmcoN0L3EKXYyVC1G2BMPXNC/RiT4ElAjJCNA7M0kKyPtU5ZVsiiEUFYWm1 btrizND9+8bMI/T1axjw5Jv94HqKC6KIJMXprwipuXWUeA68snUIDy17wFqEa1U= =E8P3 -END PGP SIGNATURE-
Re: [Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In my opinion there is only one thing which could cause this problem: I updated my dovecot on 2013/11/04 from 2.2.6-1~auto+36 to 2.2.7-1~auto+2 I updated two days ago. @Timo, did you changed something within LMTP? ;-D I will try to downgrade again, did someone have a clue? I have no clue what leads to those random rejections of recipient addresses. After setting ... | warn_if_reject reject_unverified_recipient ... those mails are accepted. But I do consider this a temporary workaround. This workaround did it for me too, hope this is considered as a bug and fixed soon. Regards, Michael Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSe2ZJAAoJENEKhqzzuxPlQdsH/Rtl1E3e6CkMqVxAZjgZ7TRs VaPaZLaAVefF7LdxNaiK71XNyXlgAOqJ9Hxr1x7QTO5Z6akMp40yAZF0cII7SD0j buTQ8QKoqWOra+J8S11SAYLqbHsi2N8DbOjQ1v+uXk4cweHSGmuAeLT5ZiHWdT/H 5ZN5LifbmCk7bSWyN53SvZiEC81/XMIdaSGuFxA3bpaxyoYlfvq1y569fQdDYTIJ da3kO4l0VaNDhcWGrR8pMr5PFAPF6Z/lw575M54IcMeWzrzgyDbXETOhN488D4xI +vd79wUakeivOPD0MOxutst93TExZmLr8sxsqFB6nREx75U2iEEbSgbgPsMg8oo= =CIQ6 -END PGP SIGNATURE-
[Dovecot] status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Good morning dovecot-community, I noticed a strange log-entry since the last day: Nov 7 08:34:42 hetzner postfix/lmtp[3764]: 61CB01A3938: to=jg+introvers...@larptreff.de, relay=mail.larptreff.de[private/dovecot-lmtp], delay=0.05, delays=0.01/0.01/0.02/0.01, dsn=4.4.2, status=undeliverable (lost connection with mail.larptreff.de[private/dovecot-lmtp] while sending MAIL FROM) Thankfully I've configured a cronjob for a daily pflogsumm-report, but I don't understand this. It worked for months like a charm. It seems this only happens on mails with +-Delimiter. In my opinion there is only one thing which could cause this problem: I updated my dovecot on 2013/11/04 from 2.2.6-1~auto+36 to 2.2.7-1~auto+2 maillog: http://pastebin.com/WDGfEjdp doveconf -n: http://pastebin.com/ay6dxiUf I will try to downgrade again, did someone have a clue? Changelog from 2.2.7 didn't show changes on lmtp. Best regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSe0cCAAoJENEKhqzzuxPlLOsH/iQLHuYXH/8HQJI1cyOQ/Xkl KK010kT9EwOZCax+xputF1Cyg9XSCGBwMBA8YFWjTk57EVfNZ4RZLCkpZQU8b0X/ SsDq7jyh8QTBf7K2LEs34L6g2OMbuhv3Hl+D/RqBm09HPoBUGJZEM5ZQu28QE7rD GETa3XkQPwMyo+3GwWXmAzg3wz4tOEGg6meaOzQlGVJshQpSKbDjvln5RtsVc1Qh X9Xa4HdEesH/NXxr6uKUUEjHcp67BLWvmZHrDDIOp4dATqxDbq29QGfiJFvURKur DJZ2hbPPgEFf/Wdf5l3PXfV2OgnubyLiTgRZ7pb+xFNUAlJ2YCeRv5CUigLaps8= =0Jya -END PGP SIGNATURE-
Re: [Dovecot] mdbox - healthy rotation size vs default
On Mon, Aug 26, 2013 at 03:31:20PM -0400, Charles Marcus wrote: On 2013-08-26 2:58 PM, Michael Grimm trash...@odo.in-berlin.de wrote: As a very rough estimate I do estimate a 5% waste of space regarding deleted messages. But, my handful users are very disciplined in purging their deleted messages on a regular basis (I told them to do), and thus my regular doveadm purge -A runs will reduce that amount of wasted disk space to a minimum. Are you sure about that? There was a thread a while back (I recently posted a response to it) about this, and it sounded like the mdbox files would *never* be 'compacted' (reduced in size from deleted messages)... my reply was on 8/23, thread titled Dovecot never release preallocated space in mdbox'... Ooops, sorry, it was about *automatically* compacting them... I think... And Timo seemed to reply that hole punching was something doveadm purge could conceivably do, but doesn't do at the moment. Timo, could you please clearify a bit here? Does non-preallocated (mdbox_preallocate_space=no) m-files get hole punched (or space re-used for new messages) after running doveadm purge? Or can we end up with a huge $mdbox_rotate_size size m-file, with only a single small message remaining after all other messages has been purged? -jf
Re: [Dovecot] mdbox - healthy rotation size vs default
On Sat, Aug 24, 2013 at 10:47:56AM +0200, Michael Grimm wrote: I am running mdbox_rotate_size = 100m for approx. a year now on a small server (a handful of users, only). All mailboxes are around 1G each with a lot of attachments. I never had an issue so far. How much space are your mdboxes using, compared to to quota usage? I.e. how much space is wasted on deleted messages? (not sure this will be easy to measure, because of compression..) -jf
Re: [Dovecot] Dovecot tuning for GFS2
On Thu, Aug 22, 2013 at 08:57:40PM -0500, Stan Hoeppner wrote: 130m to 18m is 'only' a 7 fold decrease. 18m inodes is still rather large for any filesystem, cluster or local. A check on an 18m inode XFS filesystem, even on fast storage, would take quite some time. I'm sure it would take quite a bit longer to check a GFS2 with 18m inodes. We use GPFS, not GFS2. Luckily we've never needed to run fsck on it, but it has support for online fsck so hopefully it would be bareable (but please, lets not talk about such things, knock on wood). Any reason you didn't go a little larger with your mdbox rotation size? Just that we didn't see any clear recommendation/documentation for why one would want to switch from the default 2MB. 2 MB should already be packing 50-100 messages/file, so why are we only seeing 7x decrease in number of files.. Hmm, I see the m-files isn't really utilizing 2 MB. Looking at my own mdbox-storage I see 59 m-files, using a total of 34MB (avg. 576KB/file)-- with sizes ranging from ~100 KB to 2 MB. Checking our quarantine mailbox I see 3045 files, using 2.6GB (avg. 850KB/file). Guess I should look into changing to a larger rotation size. BTW, what happens if I change the mdbox_rotate_size from 2MB to 10MB? Will all the existing 2MB m-files grow to 10MB, or is it just new m-files that will use this new size? Can I get dovecot to migrate out of the 2MB files, and reorganize to 10MB files ? -jf
Re: [Dovecot] Dovecot tuning for GFS2
On Wed, Aug 21, 2013 at 02:18:52PM +0200, Andrea gabellini - SC wrote: So you are using the same config I'm testing. I forgot to write that I use maildir. I would strongly suggest using mdbox instead. AFAIK clusterfs' aren't very good at handling many small files. It's a worst case random I/O usage pattern, with high rate of metadata operations on top. We use IBM GPFS for clusterfs, and have finally completed the conversion of a 130+ million inode maildir filesystem, into a 18 million inode mdbox filesystem. I have no hard performance data showing the difference between maildir/mdbox, but at a minimum mdbox is much easier to manage. Backup of 130+ million files is painfull.. and also it feels nice to be able do schedule batches of mailbox purges to off-hours, instead of doing them at peak hours. As for your settings, we use: mmap_disable = yes # GPFS also support cluster-wide mmap, but for some reason we've disabled it in dovecot.. mail_fsync = optimized mail_nfs_storage = no mail_nfs_index = no lock_method = fcntl and of course Dovecot Director in front of them.. -jf
Re: [Dovecot] The docs a re a bit weird on Directory hashing
On Fri, Aug 09, 2013 at 12:02:34AM +0300, Eliezer Croitoru wrote: I use: mail_home = /srv/mailstore/%256LRHu/%Ld/%Ln R what for?? I do understand a Lower case on the names and have seen the effect but how would R be helpful?? According to http://wiki2.dovecot.org/Variables %H hash function is a bit bad if all the strings end with the same text, so if you're hashing usernames being in user@domain form, you probably want to reverse the username to get better hash value variety, e.g. %3RHu. -jf
Re: [Dovecot] The docs a re a bit weird on Directory hashing
On Thu, Aug 08, 2013 at 01:42:43AM +0300, Eliezer Croitoru wrote: And means a two layers cache of max 16 directories on the first layer and 256 directories on the second layer. The above allows millions of files storage and can benefit from all ext4 lower kernel levels of compatibly rather then do stuff on the user-land.. Since I am not 100% sure that the scheme I understood is indeed what I think I assume the above will need a small correction. I use: mail_home = /srv/mailstore/%256LRHu/%Ld/%Ln which gives me 256 buckets containing domainname/username/, and the buckets are a hash of Lowercase Reverse usernames. To get the same layout as squid, I would try: mail_home = /srv/mailstore/%16LRHu/%256LRHu/%Lu Ref: http://wiki2.dovecot.org/Variables for variables and modifiers. BTW: I'm lowercasing everything, because I once got bitten by a variable not being lowercased in one version, and suddenly this changing in another version. It's probably redundant here -- but it was painful to fix when it happened.. -jf
Re: [Dovecot] LDA vs. LMTP
On 07/26/2013 05:45 PM, Martin Burgraf wrote: Hi there, I'm using Dovecot together with Postfix; as I understand it, there are two ways to transfer the mail from Postfix to Dovecot. 1.) by using LDA with mailbox_command = /usr/libexec/dovecot/dovecot-lda -f $SENDER -a $RECIPIENT 2.) by using LMTP with mailbox_transport = lmtp:unix:private/dovecot-lmtp (currently using number 1) I'm interessted in the differences and the advantages/disadvantages of each of those solutions. You cannot use the LDA method if SMTP and IMAP services reside on different machines, which would be the case in larger scale mail system setups. My advice is to go with LMTP anyway! Cheers Jan -- MAX-PLANCK-INSTITUT fuer Radioastronomie Jan Behrend - Rechenzentrum Auf dem Huegel 69, D-53121 Bonn Tel: +49 (228) 525 359, Fax: +49 (228) 525 229 jbehr...@mpifr-bonn.mpg.de http://www.mpifr-bonn.mpg.de Die digitale Unterschrift dieser Mail kann durch das Zertifikat der DFN Global Hierarchie überprüft werden: https://ca.mpg.de/certs/root-DGP/deutsche-telekom-ca2-root-cert.der Weitere Informationen zur CA der MPG finden Sie unter: https://ca.mpg.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] convert to mdbox
On Tue, Jul 23, 2013 at 10:08:57AM +0300, Birta Levente wrote: How can I convert all virtual mailboxes from maildir to mdbox? Manually, one by one, working, but I have a lot ... I've converted around 4-500.000 users from maildir to mdbox by the following on a server configured for using MDBOX as default: 1 - Search for all users with mailMessageStore attribute in LDAP 2 - Convert user to mdbox: dsync -v -u $username mirror maildir:$maildir + check returncode dsync -v -u $username mirror maildir:$maildir + check returncode 3 - Delete mailMessageStore attribute from LDAP and add mailLocation: mdbox:~/mdbox 4 - pkill -HUP -u dovecot -f dovecot/auth -- to make sure auth cache is updated 5 - doveadm kick $username -- on all servers, in case user was logged in.. 6 - Do final sync: dsync -v -u $username mirror maildir:$maildir 7 - Delete maildir. Only 26554 users left to convert.. -jf
Re: [Dovecot] Dovecot never release preallocated space in mdbox
On Mon, Jul 29, 2013 at 11:48:00AM +0200, Stéphane BERTHELOT wrote: mdbox_rotate_size = 128M mdbox_rotate_interval = 1d mdbox_preallocate_space = yes On mailboxes patterns with low incoming mail ( 100kb / day) this would waste much space. Of course I can decrease rotate size a lot but it would then produce a lot of files and would certainly become similar performance-wise to sdbox/maildir/... 128MB is quite a large rotate size if you care about disk space.. We use the default 2 MB, which still packs quite a lot of messages per file compared to maildir. Single maildir-files seems to be around 5-30KB (compressed), which should amount to 50-400 messages per m-file. I don't think that should be similar to maildir/sdbox performance-wise. -jf
Re: [Dovecot] reload without shutting imap connections down
Hi, we have some problems with users who report connectionproblems to dovecot sometimes. According to the logs there are dovecot reloads at this times. Seems that a reload also causes dovecot to shut all imapconnections down: Just a wile guess: Could it have something to do with the shutdown_clients setting, perhaps..?
Re: [Dovecot] login_trusted_networks from webmail ?
On Thu, Jul 04, 2013 at 08:51:47PM +0200, Benny Pedersen wrote: Timo Sirainen skrev den 2013-07-03 22:34: If backend has login_trusted_networks pointing to directors, then the IP gets forwarded to backends as well. how does imap get ip from http ? The webmail-server will use the HTTP REMOTE_ADDR header in the IMAP ID when initiating the IMAP connection. a ID (x-originating-ip $REMOTE_ADDR) -jf
[Dovecot] login_trusted_networks from webmail ?
I'd like to get the IP-address of the webmail-klient logged in my maillog (for being compliant with coming data retention policies). I've noticed that with login_trusted_networks pointing at my dovecot directors, we get rip=client-ip logged on the backends. How is the proxy providing this to the dovecot backends? Anybody know what magic we need to implement in our webmail-solution to be able to forward the webmail-client-ip and have it logged as rip= in dovecot? I belive it will be enough to have it logged as rip= on the directors, maybe not needed to be forwarded all the way to the backends (but that would be nice as well). -jf
Re: [Dovecot] login_trusted_networks from webmail ?
On Wed, Jul 03, 2013 at 11:34:56PM +0300, Timo Sirainen wrote: a ID (x-originating-ip 1.2.3.4) Perfect, thanks! Feature request for SOGo filed: http://www.sogo.nu/bugs/view.php?id=2366 -jf
Re: [Dovecot] Dovecot + SELinux permission problems
On Sun, Jun 23, 2013 at 04:21:17PM +0100, Johnny wrote: I had thought SELinux would log something, but /var/log/audit/audit.log is blank... Are you running auditd? I believe that if you're not running auditd, the denials should be logged to the kernel ring buffer. Does dmesg show any denials ? Likely dovecot doesn't have access user_home_dir_t/user_home_t. Is all users maildirs below /home/user/data1/Maildir/ ? If so, you can probably fix this by creating a labeling rule for this, and re-label everything below this directory: semanage fcontext -a -t mail_spool_t /home/user/data1/Maildir(/.*)? restorecon -R /home/user/data1/Maildir -jf
Re: [Dovecot] dovecot enterprise release
On 6/20/2013 10:54, Benny Pedersen wrote: On the dovecot enterprise release pages, only debian 6 compatibility is shown. Are there any plans to support wheezy? (as 7 is stable now, and we are running it...) apt-get source dovecot -b will not work ?, if not then your enterprise is building on precompiled problems I'm not sure I understand..?
Re: [Dovecot] dovecot enterprise release
dovecot is opensource, so why depend on someone that will not package it for enterprise ? get the tarballs. create a deb package. install, be happy Ah right. :-) But the advantage of using the http://www.dovecot.fi/ 'enterprise dovecot' would be that they provide up-to-date versions of dovecot. And currently we're running debian wheezy with it's default dovecot, version 2.1.7. MJ
[Dovecot] dovecot enterprise release
Hi all, Not sure if this is the right place to ask, but...: On the dovecot enterprise release pages, only debian 6 compatibility is shown. Are there any plans to support wheezy? (as 7 is stable now, and we are running it...) Regards, Mourik Jan
Re: [Dovecot] Mailbox conversion/importing
Hi, We have used Rick's tools to migrate from scalix to dovecot, and they worked out incredibly well for us. Also Rick was very responsive to questions and suggestions. I consider it $35 USD well spent. And that's the end of this commercial. ;-) Mourik Jan On 06/17/2013 04:31 AM, Rick Sanders wrote: A specialised migration tool must be less tested (and perhaps more buggy) than pop/imap servers that are in use around the world constantly. On the other hand a tool which is specifically built to do IMAP migration can do the job quickly and efficiently. My experience is that a well-designed IMAP Migration tool which has been tested over the years is often the best bet. Just my own 2 cents worth. Rick Sanders rfs9...@earthlink.net http://www.athensfbc.com/imap-tools
Re: [Dovecot] dovecot enterprise release
Hi Timo, list, Wheezy is supported already as well. I guess the web page needs updating. Ah, thanks for the quick reply. MJ
