[Dovecot] dovecot-2.0.beta4: compiler gets stuck making master-service-settings.o Mac OS X 10.6.2
dovecot-2.0.beta4 Environment: MacOS X 10.6.2, Xcode 3.2.1 (gcc-4.2) Problem: ./configure --sysconfdir=/usr/local/conf/ make [...] /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-settings -DPKG_RUNDIR=\/usr/local/var/run/dovecot\ -DSYSCONFDIR=\/usr/local/conf/dovecot\ -DBINDIR=\/usr/local/bin\ -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT master-service-settings.lo -MD -MP -MF .deps/master-service-settings.Tpo -c -o master-service-settings.lo master-service-settings.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-settings -DPKG_RUNDIR=\/usr/local/var/run/dovecot\ -DSYSCONFDIR=\/usr/local/conf/dovecot\ -DBINDIR=\/usr/local/bin\ -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -MT master-service-settings.lo -MD -MP -MF .deps/master-service-settings.Tpo -c master-service-settings.c -fno-common -DPIC -o .libs/master-service-settings.o never ends (well, I let it take over 3 minutes of cpu on a Xserve 2.26GHz Xeon and over 5 minutes on a Core 2 Duo before killing it). Any ideas? Thanks Giuliano
Re: [Dovecot] dovecot-2.0.beta4: compiler gets stuck making master-service-settings.o Mac OS X 10.6.2
On 3 Apr, 2010, at 3:35 PM, Axel Luttgens wrote: Hello Giuliano, You may want to add flag -fno-reorder-blocks to line 121 of src/lib-master/Makefile: CFLAGS = -std=gnu99 -g -O2 -fno-reorder-blocks -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 then run make. [...] Thank you Axel! The Makefile mod worked. That was an experiment for me, I have then decided to compile and run 1.1.8 for this particular server as it is a production one, albeit just a fully backed up archive... Giuliano
Re: [Dovecot] creating skeleton Maildir
On S 24 May, 2009, at 23:55 , Daniel Black wrote: just create the Maildir directory and dovecot will create anything else it needs. Daniel ah, easy peasy... Thanks! Giuliano
Re: [Dovecot] creating skeleton Maildir
On M 25 May, 2009, at 11:51 , Roy Sigurd Karlsbakk wrote: On 24. mai. 2009, at 23.55, Daniel Black wrote: just create the Maildir directory and dovecot will create anything else it needs. What should be user/group ownership on the directory? user and group the same as the owner of the account. Access 700. That is, group does not really matter. Giuliano
[Dovecot] creating skeleton Maildir
Dear all, when I had a courier installation still in place I used to create the Maildir tree for a new user using its maildirmake (IIRC) utility. Now that I had to rebuild a server from scratch, and using dovecot did not install courier, I have to create Maildirs without that utility. I seem to remember that libexec/imap could be called in a way to create the Maildir and its required subfolders (.Sent, .Drafts, etc). Do I remember correctly? If so what are the command line options? I cannot find pointers in the wiki or elsewhere. If not, I will just create a template and script the whole process. Thanks Giuliano
Re: [Dovecot] migration and conversion from courier
On M 18 May, 2009, at 01:00 , Timo Sirainen wrote: On Mon, 2009-05-18 at 00:57 +0200, Giuliano Gavazzi wrote: There's only one point that escapes me, why perform the conversion when migrating (using the --convert option) given that on the system where I did not perform it the flags have been preserved (the files got their name change consistently). Does dovecot detect the presence of the courierimapkeywords/:list file and use its content? No. Seems unlikely as a grep on the source does not reveal any match. Maybe it's the MUA (Mail.app in the instance I checked) that did synchronise the flags? I guess something like that is possible. But did you check that it's also correct on the server side too and not just on client side? yes, is on the server: that's why I said that the files had the consistent name change. Well, that means that with all its faults Mail.app is not sooo bad! I checked on another system with many OutLook and Thunderbird clients and it looks like they might have lost the flags previous to the change. I could write a script to update those files consistently to the current dovecot-keywords, when required. This could be an option of the migration script, say a --fix switch that would make it look in courierimapkeywords and add the keys to dovecot-keywords when they do not exist and then update the name of the message files when required. Giuliano
Re: [Dovecot] migration and conversion from courier
On S 17 May, 2009, at 20:45 , Timo Sirainen wrote:
On Fri, 2009-05-15 at 10:55 +0200, Giuliano Gavazzi wrote:
Perhaps the only solution is to have a new script that deletes the
garbage lines and renumbers the following ones, so that the above
example would become:
0 JunkRecorded
1 $NotJunk
2 $Junk
3 Redirected
4 $Forwarded
and then renames all *g files to *e.
You don't have to do any renaming, the keywords don't need to be
sequential. Just delete those lines with broken keywords. When adding
new keywords Dovecot will then use the missing spots.
that's great, thanks!
I suppose something like this should work, repeated over all maildirs:
/usr/local/etc/rc.d/dovecot stop
find . -name dovecot-keywords2 -exec sed -E -i .bu -e '/
^[0-9]\ .*[^[:print:]].*$/d' \{\} \;
/usr/local/etc/rc.d/dovecot start
(adapt to your system way to stop and start service)
There's only one point that escapes me, why perform the conversion
when migrating (using the --convert option) given that on the system
where I did not perform it the flags have been preserved (the files
got their name change consistently). Does dovecot detect the presence
of the courierimapkeywords/:list file and use its content? Seems
unlikely as a grep on the source does not reveal any match. Maybe it's
the MUA (Mail.app in the instance I checked) that did synchronise the
flags?
Giuliano
[Dovecot] migration and conversion from courier
Dear all, back in January I posted about migration from courier and in particular on the script courier-dovecot-migrate.pl. That script had a bug on BSD (or should I say not-Linux?) type systems*. On FreeBSD (6.1) and MacOSX (10.5) it appended a lot of binary garbage at the end of dovecot-keywords files. On a couple of systems I had not actually run the script with the -- convert option, as I had misunderstood the procedure, so those systems, ironically, are the ones that I migrated better... Now to the issue. My final question at the time was (http://dovecot.org/pipermail/dovecot/2009-January/036292.html): can one delete the dovecot-keywords and rerun the script (leaving alone the dovecot-uidlist)? There is a problem if this cannot be done, as those files have the following structure: 0 flag0 1 flag1 ... m binary garbage [optionally followed by more lines like the last] and if a new keyword is added, the file ends up like (this is copy and paste example): 0 JunkRecorded 1 $NotJunk 2 $Junk 3 Redirected 4 ^AF0# 5 B096# 6 $Forwarded It does not look like a nice thing to me. I doubt though that the script will cope with flags correctly, as in principle will get the flags from an out of date courierimapkeywords, thus missing any new ones. Perhaps the only solution is to have a new script that deletes the garbage lines and renumbers the following ones, so that the above example would become: 0 JunkRecorded 1 $NotJunk 2 $Junk 3 Redirected 4 $Forwarded and then renames all *g files to *e. Thoughts? Giuliano * This bug was fixed back then by Timo who replaced the script on the site http://www.dovecot.org/tools/courier-dovecot-migrate.pl. But there's no note of the change on the site nor was an announcement made to the list, AFAIK.
Re: [Dovecot] Migration questions...
On F 15 May, 2009, at 09:39 , Seth Mattinen wrote: This raises an interesting question for me actually... given that we've now decided dovecot and maildir is the way forward for us, which delivery method should we use in exim? exim can support maildir, (right?) and so can dovecot, so should i use dovecot's deliver mechanism, or exim's own internal mechanism? Only dovecot 'deliver' will update the index on delivery. well, using an LDA makes a little more cumbersome to check the local recipient at RCPT time. What repercussion has not updating the index on delivery? My systems use exim to deliver and they seem to act normally... Giuliano
Re: [Dovecot] Migration questions...
On F 15 May, 2009, at 12:30 , Steffen Kaiser wrote: On Fri, 15 May 2009, Giuliano Gavazzi wrote: well, using an LDA makes a little more cumbersome to check the local recipient at RCPT time. Huh? exim won't try local deliver unless it has decided it is a local recipient. You won't get overquota status this way, did you mean that? No. The problem is the try... or at least, it was when I had a cyrus + exim setup five years ago. With cyrus it was impossible to easily check if the recipient was an existing local user. It required either the use of the mbpath utility or a recipient callout with lmtp over tcp. I suppose that with a virtual users setup this is a moot point, but with system users nothing beats the simplicity of an all exim setup! (If you use exim, that is). Giuliano
Re: [Dovecot] Dovecot 1.0.7 domain variable
On W 13 May, 2009, at 04:37 , elli...@n.0o0.bz wrote: Okay, I've now also tried changing auth_username_format = %n-%d and adding a user for each account. Authentication works fine but I still get maildir: data=/var/mail/vhosts//elliott-n.0o0.bz in the logs! What's the deal? When does the %d variable get set and how can I use it?? Thanks for any pointers! this has come up recently. The gist of it is this: the username from which the % variables are expanded is the same that has been authenticated by the authentication mechanism. One trick, that I used with my system users, in order to keep the domain in the location path, is to use the home directory to build it (by concatenation and a simple symbolic link). As you have virtual users, you are even free to set the home to what you need for the location path. Giuliano
Re: [Dovecot] where are variables expanded? Was: %d does not expand to domain
On W 29 Apr, 2009, at 22:21 , Giuliano Gavazzi wrote: I am trying to patch the source so that the %d expansion variable uses original_username (instead of user I suppose) of auth_request, but I cannot find where this expansion is done.. Pointers? Thanks Giuliano I thought it was in auth_request_get_var_expand_table, and changed thus: //GGtab[2].value = strchr(auth_request-user, '@'); tab[2].value = strchr(auth_request-original_username, '@'); //GG test to keep domain but this makes no difference (well, not in the expansion for mail_location). I found other places where var_expand_table is set (easy, as you always use tab as a local variable), but as they were not passed auth_request it was not possible to get the original_username. I think I can see a reason behind this: ignoring the domain passed when authenticating means that the domain part has not been checked and thus its use unwarranted. In the case of system users this would pose no threat, but for virtual users it might, in principle, allow an unauthorised access to other maildirs. Giuliano
[Dovecot] where are variables expanded? Was: %d does not expand to domain
I am trying to patch the source so that the %d expansion variable uses original_username (instead of user I suppose) of auth_request, but I cannot find where this expansion is done.. Pointers? Thanks Giuliano
Re: [Dovecot] %d does not expand to domain
On M 27 Apr, 2009, at 23:23 , Giuliano Gavazzi wrote: For me it's not a big deal, as was trying this only to give a different layout to users' mailboxes. but it would be a big deal if I wanted to create domain specific public mailboxes. In order to allow extra parameters passed by the client (like in this case the domain name) to survive for subsequent use, perhaps there should be a username_format for all passdb (and userdb) methods, like the is for passwd-file. One could then let auth_username_format alone and preserve the %d variable for subsequent use. If I did not want %d to be used at all, I would not specify it in the client configuration from the start... The documentation would have to be quite clear though, as auth_username_format seems more specific to authentication/ authorisation, while username_format would seem a global one, while, as it is now, auth_username_format rewrites globally the username, and username_format is specific to the authentication/authorization where it is allowed and defined. Giuliano
[Dovecot] %d does not expand to domain
Hello, dovecot-1.1.7 on FreeBSD 7.1. Usernames have dot in them (like uname.example for a user in example.com). in dovecot.conf I have: mail_location: maildir:/userhomes/maildirs/%d/%n/Maildir and for authentication: username_format: %Ln In the client, tried with CONE and Mail.app, I put the username as: uname.exam...@example.com So, the authentication works fine, as it extracts the uname.example from the uname.exam...@example.com supplied. The mail_location does not: Apr 27 17:21:26 drum dovecot: imap-login: Login: user=uname.example, method=PLAIN, rip=88.149.183.86, lip=88.149.202.106, TLS Apr 27 17:21:26 drum dovecot: IMAP(name.example): Effective uid=1301, gid=1301, userhomes=/userhomes/example.com/uname Apr 27 17:21:26 drum dovecot: IMAP(uname.example): Namespace: type=private, prefix=INBOX., sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes Apr 27 17:21:26 drum dovecot: IMAP(uname.example): maildir: data=/ userhomes/maildirs//uname.example/Maildir Apr 27 17:21:26 drum dovecot: IMAP(uname.example): maildir++: root=/ userhomes/maildirs//uname.example/Maildir, index=, control=, inbox=/ userhomes/maildirs//uname.example/Maildir it looks like the %d expands to the empty string. Could this be due to the . in the username? Thanks Giuliano
Re: [Dovecot] %d does not expand to domain
On M 27 Apr, 2009, at 20:31 , Timo Sirainen wrote: On Mon, 2009-04-27 at 17:31 +0200, Giuliano Gavazzi wrote: and for authentication: username_format: %Ln This drops the domain part entirely, so after processing this %d will return empty. If you don't want it, try to figure out another way to do this. You didn't say what passdb you're using, so I can't give an example. Ah, do you mean that the following: # Username formatting before it's looked up from databases. You can use # the standard variables here, eg. %Lu would lowercase the username, %n would # drop away the domain if it was given, or %n-AT-%d would change the '@' into # -AT-. This translation is done after auth_username_translation changes. auth_username_format = %Ln actually changes the username supplied, not just for database lookups (including the system passwd that I use), but also for subsequent uses that do not involve any more lookups (like in the mail_location). I think this should be specified clearly (might be somewhere, I haven't read the whole documentation). I do not see, but I must be mistaken, why the supplied credentials are not left alone, and the transformed value only used for the lookups. As it is some variables will have little use outside of database lookups! For me it's not a big deal, as was trying this only to give a different layout to users' mailboxes. Thanks Giuliano
[Dovecot] changing architecture
Dear all, moving Maildirs from a PPC cpu to an Intel one (MacOS X to FreeBSD) not surprisingly I got: Apr 23 12:08:50 drum dovecot: IMAP(x): Rebuilding index file /usr/home/ x/Maildir/dovecot.index: CPU architecture changed Apr 23 12:08:52 drum dovecot: IMAP(x): Corrupted index cache file /usr/ home/x/Maildir/dovecot.index.cache: field header points outside file Apr 23 12:09:01 drum dovecot: IMAP(x): fscking index file /usr/home/x/ Maildir/.Drafts/dovecot.index Apr 23 12:09:01 drum dovecot: IMAP(x): Corrupted transaction log file / usr/home/x/Maildir/.Drafts/dovecot.index.log: file size shrank Apr 23 12:09:01 drum dovecot: IMAP(x): fscking index file /usr/home/x/ Maildir/.Posta indesiderata/dovecot.index Apr 23 12:09:01 drum dovecot: IMAP(x): Corrupted transaction log file / usr/home/x/Maildir/.Posta indesiderata/dovecot.index.log: file size shrank I suppose owed to the endianness change. Can I thus just remove those dovecot.index files, including dovecot.index.cache and dovecot.index.cache.log? I know I could let dovecot do it, but as the cache files in particular are quite large, it would save me band simply not transferring them with rsync from the old server. thanks Giuliano
Re: [Dovecot] changing architecture
On T 23 Apr, 2009, at 12:20 , Giuliano Gavazzi wrote: I suppose owed to the endianness change. Can I thus just remove those dovecot.index files, including dovecot.index.cache and dovecot.index.cache.log? I know I could let dovecot do it, but as the cache files in particular are quite large, it would save me band simply not transferring them with rsync from the old server. sorry, just found on this list a message from Timo stating that this deletion is safe. Giuliano
Re: [Dovecot] Script: Moving Maildirs between servers
On T 5 Feb, 2009, at 00:13 , Timo Sirainen wrote: For Maildir message files incomplete messages aren't just unlikely, they're never possible. I was implying Maildir of course. I am not familiar with the specification though. Does it require files to be written initially in tmp to be moved in new once complete? g
Re: [Dovecot] help on writing a rule for perventing spam
On S 24 Jan, 2009, at 21:45 , mouss wrote: From what I understand he is rejecting backscatter that is sent to some of his old addresses (with an identical forged sender, Note the from in claims to be sent FROM but this is irrelevant) and from there forwarded to his mail server. Very bad. If you have configured forwarding somewhere you must be prepared to accept anything from there, or else you will be the cause of backscatter as the peer server is a genuine server and not a spambot. you misunderstd ;-p whoops! I wrote with an identical forged sender, but this is irrelevant, clearly that was NOT irrelevant. I should have paid more attention to that. Anyway, your document should not be just called backscatter how-to, as backscatter will have (if really such), most of the time, an empty sender. The only exception are some idiotic virus scanners. g
Re: [Dovecot] TLS / SSL login with Thunderbird very slow ?
On S 24 Jan, 2009, at 20:50 , Matthias Andree wrote: On Sat, 24 Jan 2009, Marko Weber | Salondigital.de wrote: Hi , i use dovecoz 1.1.4 with TLS / SSL only. i takes up to ~10 seconds that Thunderbird login and send the mail. send the mail has nothing to do with Dovecot, but with the SMTP server, such as Exim (which may try ident queries that your client possibly firewalls) or Postfix. true, but if Marko's Thunderbird is configured to save sent messages on the IMAP server, the sending process will complete, from the client point of view, when the message has been stored on the IMAP server. So the change in Dovecot might cause a perceived slowdown. Also, with other IMAP server (no idea if this applies to Dovecot) you could even have the sending process start by copying the message in a particular outbox without direct interaction between the MUA and the SMTP server. Giuliano
Re: [Dovecot] help on writing a rule for perventing spam
On T 22 Jan, 2009, at 11:49 , Charles Marcus wrote: On 1/21/2009, Giuliano Gavazzi (dev+li...@humph.com) wrote: The postfix backscatter readme is a good start, esppecially is you are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA... I don't use postfix, because I use exim... And as I said... the CONCEPTS can be applied to ANY MTA... well, first of all backscatter is not really the issue of this thread. Secondly the concepts are not all that good. In particular the one entitled: Blocking backscatter mail with forged sender information that states: Like many people I still have a few email addresses in domains that I used in the past. Mail for those addresses is forwarded to my current address. Most of the backscatter mail that I get claims to be sent from these addresses. Such mail is obviously forged and is very easy to stop. From what I understand he is rejecting backscatter that is sent to some of his old addresses (with an identical forged sender, but this is irrelevant) and from there forwarded to his mail server. Very bad. If you have configured forwarding somewhere you must be prepared to accept anything from there, or else you will be the cause of backscatter as the peer server is a genuine server and not a spambot. The old Postel rule Be conservative with what you send and liberal with what you receive (or something on those lines) might be too liberal in the current internet, but certainly should not be relaxed on the conservative part... The first thing an administrator should look for is to avoid generating spam of any sort, then he can think of ways to stop it (and even more responsibly to place a further burden on spammers with delays and the like, but this is something you can only do on an MTA). Giuliano
Re: [Dovecot] help on writing a rule for perventing spam
On W 21 Jan, 2009, at 12:25 , Charles Marcus wrote: On 1/21/2009, Giuliano Gavazzi (dev+li...@humph.com) wrote: you are much better off rejecting those even before seing the DATA, if that address is in the envelope sender, or after, if it is only in the From: message header. ? If he did that, then he wouldn't see his own messages to this list. you are quite right. Indeed I never check the From: header, but the MAIL FROM. I extended the rule for the benefit of the list, and it came out wrong... But I agree that fighting this kind of spam is best done at the MTA level, and isn't really a dovecot (or sieve) issue. The postfix backscatter readme is a good start, esppecially is you are using postfix - and if you aren't, why aren't you? ;) ... but the concepts can be applied to any MTA... I don't use postfix, because I use exim... g
Re: [Dovecot] deliver rejection bounces
On T 20 Jan, 2009, at 12:38 , Steffen Kaiser wrote: So you can hack sendmail. Exim, too, if I remember correctly. I would not call that hack in exim case though. It is possible to avoid all backscatter, first of all by avoiding delivery by an external programme*. This will still leave the possibility of a failure in forwarding, but by changing the envelope sender to the local administrator address (setting errors_to in the delivering routers) even a failure in forwarding will only cause a locally delivered failure report. There is no excuse for backscatter and whoever causes it will likely and rightly end up in some blacklist, local or distributed, sooner or later. Giuliano
Re: [Dovecot] help on writing a rule for perventing spam
On W 21 Jan, 2009, at 06:34 , Sophia Alikhani wrote: Hi I used qmail + dovecot-1.1.7 + dovecot-sieve + now everything works well but there are many spam in Bulk folders from every user address to their address for example from us...@mydomain to us...@mydomain in the real the sender and reciever are the same . they are spam but since everyday , everyvirtual user has many of these spams in their Bulk i need a rule in dovecot.sieve to prevent them Can anybody help me for writing this rule. you are much better off rejecting those even before seing the DATA, if that address is in the envelope sender, or after, if it is only in the From: message header. No need to accept them, so no need for dovecot to even see them. So this is an issue you should take, if necessary, to the mailing list of your MTA of choice. Giuliano
Re: [Dovecot] deliver rejection bounces
You message was rejected by... no thank you, I do not want ever to see this: On M 19 Jan, 2009, at 10:24 , Steffen Kaiser wrote: On Sun, 18 Jan 2009, Seth Mattinen wrote: As a mail admin, I never want to see deliver generating its own messages to potentially forged addresses and spamming innocent people. The MTA should do this during the SMTP transaction. Which MTA tries to deliver the mail during the SMTP dialogue? Neither Postfix nor sendmail does, unfortunately. Well, one would open yet another can of worms, if doing so, I guess. he meant SMTP time reject, not bounces or NDR or whatever. Giuliano
Re: [Dovecot] new flags in Maildir files
I think the problems is around line 436 of http://www.dovecot.org/tools/courier-dovecot-migrate.pl as it reads the dot dirs after having read :list in the previous block of code. So, the content of the directories is appended to dovecot- keywords. I know nothing of perl! So I cannot really understand why it is so and how to fix it... (Note that this error happens on BSD systems, that is MacOSX and FreeBSD, I might run it on a Linux virtualbox as a cross test, just in case it is a perl platform quirk). Giuliano
Re: [Dovecot] new flags in Maildir files
Well, now 1.1.8 on MacOSX (from courier + conversion script run) on a fourth system and I get the name change here too. I will upgrade other systems (where I did not run the conversion script) to 1.1.8 and see if the name change is owed to the dovecot version or having run the script. g
Re: [Dovecot] Enforcing TLS
On T 6 Jan, 2009, at 14:59 , Ed Schouten wrote:
My question: is there support to enforce TLS when people connect to
non-SSL ports? If someone comes up with a solution, I'll add it to the
SSL article on the Wiki.
I'm using Dovecot 1.1.7, installed on a FreeBSD 6.4-STABLE system.
not sure I understand the question correctly, if I do then the answer
would be you cannot. If the client wants to speak plain it will. I do
not see why you would want to keep on listening on port 143 if you
want to enforce SSL, but if you really want to:
protocol imap {
listen = 127.0.0.1:143
ssl_listen = *:993 interface-ip:143
}
You can of course drop interface-ip:143.
Giuliano
Re: [Dovecot] Enforcing TLS
On F 9 Jan, 2009, at 13:11 , Giuliano Gavazzi wrote: On T 6 Jan, 2009, at 14:59 , Ed Schouten wrote: My question: is there support to enforce TLS when people connect to non-SSL ports? If someone comes up with a solution, I'll add it to the SSL article on the Wiki. I'm using Dovecot 1.1.7, installed on a FreeBSD 6.4-STABLE system. not sure I understand the question correctly, if I do then the answer would be you cannot. If the client wants to speak plain it will. I do not see why you would want to keep on listening on port 143 if you sorry, I wasn't aware that disable_plaintext_auth would suppress the AUTH=PLAIN capability list. I would not rely on that though, there might be around buggy clients (of which there are in general plenty!) that would ignore that... g
Re: [Dovecot] new flags in Maildir files
all right, the suffix lowercase letters do correspond to the relevant dovecot-keyword. Problem is, on system where courier-dovecot- migrate.pl has not been applied dovecot-keywords consist of: 0 $NotJunk 1 etc. while on system that have undergone courier-dovecot-migrate.pl the files then continue with what look like extraneous lines: 0 JunkRecorded 1 Junk 2 $NotJunk 3 $Forwarded 4 NotJunk 5 $Junk 6 Redirected 7 Forwarded 8 7p/^...@^l^@^d^...@^@^@C5\...@^l^@^d^b...@^^\/^...@^p^^e:li...@6CD9p/ ^...@8^-.3908840.1172611369.h459121p73525.[a very long line her...@^@^...@^@^@ 9 C5\...@^l^@^d^...@^@^@C4\...@^l^@^d^b...@^@C6 \...@^t^@^D^K.Newsletter[ ditto ]...@^t^@^D and so on. In this particular case the suffix letters go from a to i, so from 0 to 7, and the keywords 8 onwards are thus bogus, consistently with the content of the file. Ideas? Giuliano
Re: [Dovecot] new flags in Maildir files
On F 9 Jan, 2009, at 15:59 , Timo Sirainen wrote: Not really. Any idea how to reproduce it? yes, if it is safe, and makes sense, to delete dovecot-keywords and rerun the script I could do it on a copy of an account, just to be on the safe(r) side... giuliano
Re: [Dovecot] new flags in Maildir files
On F 9 Jan, 2009, at 15:59 , Timo Sirainen wrote: On Jan 9, 2009, at 9:57 AM, Giuliano Gavazzi wrote: while on system that have undergone courier-dovecot-migrate.pl the files then continue with what look like extraneous lines: 0 JunkRecorded 1 Junk 2 $NotJunk 3 $Forwarded 4 NotJunk 5 $Junk 6 Redirected 7 Forwarded 8 7p/^...@^l^@^d^...@^@^@C5\...@^l^@^d^b...@^^\/^...@^p^^e:li...@6CD9p/ ^...@8^-.3908840.1172611369.h459121p73525.[a very long line her...@^@^...@^@^@ 9 C5\...@^l^@^d^...@^@^@C4\...@^l^@^d^b...@^@C6 \...@^t^@^D^K.Newsletter[ ditto ]...@^t^@^D Are these broken lines written by the migration script, or by Dovecot afterwards? done a test: they are written by the migration script. For some reason I managed to have still the old (your version v1.1.8), but now that I have the new (# cpanel12 - maildir-migrate) linked from http://wiki.dovecot.org/Migration/Courier , I get the same result (with the new --to-dovecot option). I suppose it might come form a broken courierimapkeywords directory? I could send you a simple sample courierimapkeywords that reproduces it. thanks g
[Dovecot] new flags in Maildir files
Sorry if this is a dumb question: I migrated my third system from courier to dovecot. My previous two were MacOSX the third is FreeBSD 6. I noticed (because of an rsync process taking longer than usual...) that on FreeBSD the message files have, most of them at least, gained extra suffix letters (in the range a-h I'd say) that I do not see (mostly if not at all) on my MacOS systems. I wonder if this is because of a different migration process, as in the first two cases I wrongly run courier-dovecot-migrate.pl without the --convert option as I was satisfied that the OK result for all Mailboxes was enough... (no pop here), while on FreeBSD I correctly applied the --convert option. The other difference is the version, 1.1.6 for MacOSX, 1.1.7 for FreeBSD. Cannot find a relevant entryin the ChangeLog. (now running rsync with the --fuzzy option, hopefully it will find the files cutting on transfer times!) Thanks Giuliano
Re: [Dovecot] Dot in user name. Was: Re: Apple patch 9
Here is the reason of the login failure on Mac OS X (Server) when using secondary short names: the unix username is x_y, the additional short name (accepted for authentication) is x.y: Jan 6 15:38:58 dns dovecot[281]: Fatal: auth(default): BROKEN NSS IMPLEMENTATION: getpwnam() lookup returned different user than was requested (x_y != x.y). Jan 6 15:38:58 dns dovecot[281]: imap-login: Internal login failure (auth failed, 1 attempts): user=x.y, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured the secure.log report no errors: Jan 6 15:38:58 dns com.apple.SecurityServer[35]: checkpw() succeeded, creating credential for user x.y Jan 6 15:38:58 dns com.apple.SecurityServer[35]: checkpw() succeeded, creating shared credential for user x.y Jan 6 15:38:58 dns com.apple.SecurityServer[35]: Succeeded authorizing right system.login.tty by client /usr/local/libexec/ dovecot/dovecot-auth for authorization created by /usr/local/libexec/ dovecot/dovecot-auth. Back in 2006 Timo wrote in response to the same problem: Well, you could simply remove the check from src/auth/userdb-passwd.c. Perhaps I could make this also optional. I'd anyway not want to remove that check completely because nss_ldap is still not fixed. This is not vital, but perhaps it is time to allow control on this behaviour that seems to potentially affect various platforms? Or perhaps should getpwnam return the short user name that matches the passwd field supplied (if it exists)? Giuliano
Re: [Dovecot] Dot in user name. Was: Re: Apple patch 9
On T 6 Jan, 2009, at 16:08 , Timo Sirainen wrote: On Tue, 2009-01-06 at 16:02 +0100, Giuliano Gavazzi wrote: Jan 6 15:38:58 dns dovecot[281]: Fatal: auth(default): BROKEN NSS IMPLEMENTATION: getpwnam() lookup returned different user than was requested (x_y != x.y). .. This is not vital, but perhaps it is time to allow control on this behaviour that seems to potentially affect various platforms? Or perhaps should getpwnam return the short user name that matches the passwd field supplied (if it exists)? http://hg.dovecot.org/dovecot-1.1/rev/5858d901b2af that was quick! Thanks g
[Dovecot] Dot in user name. Was: Re: Apple patch 9
Sorry for sneaking in this thread, but it might be a reason for a patch on the Apple side. Up until 10.3.9 Server, and 10.4 Client, I used to be able to create users with short name containing a dot. The latest OS doesn't allow that easily (there seem to be some not so clean workarounds), but the closest thing I can do is to create the primary short name with another character in place of the dot (for instance an underscore) and add an extra short name with the dot as I want it. Now, if I use PAM for authentication dovecot will not permit using the alternative dotted short name as it will seem to fail authentication. I do not remember exactly what is the issue, but I can do a test if you like. Other servers seem not to have an issue, just dovecot. Perhaps it is just an issue when interacting with PAM. Giuliano
Re: [Dovecot] Firewalls are [essentially] free - WAS: Re: Source patches from Apple
On S 14 Dec, 2008, at 19:42 , Charles Marcus wrote: But I think, like Zed, this thread is dead. uh? who is this Zed? My remark was just a frivolous post mortem then. Its a reference to the movie 'Pulp Fiction'... http://www.youtube.com/watch?v=y7Yp2L6c2KM what? They don't wear no helmet... I must admit I missed that movie! To make this post less idle, let me say that even without patches dovecot runs very well on Mac OS X, both server and client (10.5 and 10.4), under launchd. I am glad nevertheless that Apple is taking an interest in it; maybe one day my setups (exim + courier once, now exim + dovecot) will be more standard ones. Giuliano
Re: [Dovecot] Source patches from Apple
On S 13 Dec, 2008, at 14:56 , Charles Marcus wrote: On 12/13/2008, Dave McGuire (mcgu...@neurotica.com) wrote: and I'm not interested in running a firewall on my mail server. Wow.. I can't imagine NOT running a mail server without a firewall... you put in so many negatives there that the meaning came out the opposite of what you wanted, I suppose. g
Re: [Dovecot] Firewalls are [essentially] free - WAS: Re: Source patches from Apple
On S 14 Dec, 2008, at 17:22 , Charles Marcus wrote: On 12/14/2008 9:09 AM, Giuliano Gavazzi wrote: and I'm not interested in running a firewall on my mail server. Wow.. I can't imagine NOT running a mail server without a firewall... you put in so many negatives there that the meaning came out the opposite of what you wanted, I suppose. Two is not 'so many'... the meaning is plain (for anyone who understands english)... you make my point, as the negatives were three (can not - NOT - with no) for anyone understanding english... so the meaning was reversed (unless you meant otherwise...). But I think, like Zed, this thread is dead. uh? who is this Zed? My remark was just a frivolous post mortem then. Giuliano
Re: [Dovecot] workaround for shared maildirs
On S 18 Oct, 2008, at 22:06 , Giuliano Gavazzi wrote:
[...]
namespace public {
separator = .
prefix = INBOX.Public.
inbox = no
location = maildir:/SharedMaildirs/Public:CONTROL=~/Maildir/
control/Public:INDEX=~/Maildir/index/Public
hidden = yes
list = yes
subscriptions = yes
}
Tested also with dovecot-1.2.alpha2.
As for file permission, my dovecot-shared is
-rw---+ 1 dovecot staff0 Oct 18 14:58 dovecot-shared
(all users belong to group staff).
Since this does not give access to the group, I have also an inherited
ACL (file system ACL) that gives read/write access those users (or
group of users) who need access to the public folders.
Works well, as far as I can tell, with no more:
... fchown() failed with file ...
on the index file. It turned out that this was happening when the
shared folders had group access.
Now, I have to work out how to limit delete to message owners (and the
T flag private) so that only owners or the administrator can delete
files.
Giuliano
[Dovecot] workaround for shared maildirs
Hello, this is my first post to the list.
I have several mailservers running courier-imap, but am planning to
convert one (and maybe more) to dovecot 1.1.4. In the process I am
also looking to finally implement shared maildirs.
As it is well known some clients (notable Apple's Mail) have problems
in showing shared folders if the correct private namespace (INBOX) is
set in the client, as only folders beneath the INBOX root are displayed.
I have seen some solutions proposed, but none satisfactory.
As the problem stems in the invisibility of secondary namespaces from
Mail.app, I though that tricking the namespace prefix to push the
shared mailboxes inside the private INBOX namespace could be a
solution and tried the following:
namespace public {
separator = .
prefix = INBOX.Public.
inbox = no
location = maildir:/SharedMaildirs/Public:CONTROL=~/Maildir/
control/Public:INDEX=~/Maildir/index/Public
hidden = yes
list = yes
subscriptions = yes
}
note the bogus INBOX.Public prefix.
Note also that CONTROL might be better not set as this is a Maildir
(see Keyword sharing in http://wiki.dovecot.org/SharedMailboxes)
Initially I had defined an additional public namespace with the same
maildir and a normal prefix, but this seems not necessary.
Well, after some tests from Thunderbird, Mail and cone (yes, the
courier UA) I can say it works . Still have to check Outlook and
Opera, but this is encouraging.
As the public namespace Public is actually contained inside the
private (INBOX), as if it was a private mailbox (with no messages)
called Public, it is actually possible to create such a mailbox inside
INBOX and end up with a private mailbox called Public containing
private messages AND public mailboxes... Any mailbox that a user
creats inside Public instead, will end up being a public mailbox as
expected.
Thanks or any comments.
Giuliano
