Re: [Dovecot] [OT] PGP Key
* Robert Schetterer, 2007-04-07 02:59 [EMAIL PROTECTED]:~ gpg --search-keys --keyserver subkeys.pgp.net Schetterer gpg: searching for Schetterer from hkp server subkeys.pgp.net (1) Robert Schetterer [EMAIL PROTECTED] 1024 bit DSA key F475EA81, created: 2007-03-27 thx for putting my nose to this No problem, and thanks for the quick fix! :-) Bye, Thomas -- =-= - Thomas ZlatkO Zajic [EMAIL PROTECTED] Linux-2.6.20 Thunderbird-1.5 - - It is not easy to cut through a human head with a hacksaw. (M. C.) - =-=
Re: [Dovecot] Request for additional logging
On 6.4.2007, at 23.29, Richard Stockton wrote: At 12:32 PM 4/6/2007, you wrote: It would be helpful to me if there were more logging options available. For example, I would like to see a record of each email deleted, with the filename (if maildir), and size in the log. See http://wiki.dovecot.org/Plugins/MailLog It won't log the size or the filename though. Should be pretty easy to modify the sources to log them too. Maybe I'll make it configurable some day what it logs. That would great! I took a quick look at the sources, but could not easily see where to add this to the logging. But then again I'm much more comfortable with perl or php. [grin] src/plugins/mail-log/mail-log-plugin.c - mail_log_action() change the i_info() to something like: i_info(%s: uid=%u, msgid=%s%s, size=%PRIuUOFF_T, filename=%s, action, mail-uid, msgid == NULL ? (null) : str_sanitize(msgid, MSGID_LOG_LEN), mailbox_str, mail_get_physical_size(mail), mail_get_special (mail, MAIL_FETCH_UIDL_FILE_NAME)); PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] zlib plugin
On 7.4.2007, at 3.08, guenther wrote: Well, here at least. ;) I recently found out by accident about support for gzip compressed mbox files. While this is great for archives to keep wasting of space down to a minimum, unfortunately it is read only -- no support for rw access. Is implementing write access by any chance planned for future releases? Nope. Not planned at all. It would require changing quite a lot of code. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Inbox inside the mail location
On 7.4.2007, at 3.11, guenther wrote: However, I'd like to confirm what I see is how it is expected to work. Since the Inbox with this layout is is part of the ~/.mail dir just like any other mbox file (or subdir), I am concerned with getting a second Inbox mail folder in the client. I did not, which is great. So, is this expected behavior, and the Inbox mbox file actually being the Inbox and only the Inbox? Will it always be excluded from the list of IMAP mail folders? INBOX is actually always included in the list of IMAP folders. Dovecot anyway does all kinds of duplicate checking so it won't return the INBOX multiple times in any situation. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] fork bomb?
On 7.4.2007, at 6.31, Timothy Martin wrote: Apr 6 21:19:34 design1st dovecot: Temporary failure in creating login processes, slowing down for now Apr 6 21:19:34 design1st dovecot: Created login processes successfully, unstalling Hmm. This should probably be changed so that it won't even try unstalling that fast.. Eventually the entire server became unresponsive. Normally I wouldn't even think of blaming dovecot, but the hosting tech support said that when the checked out top there were crazy amounts of imap processes (maybe they just aren't used to dovecot's methods of dealing with logins etc) but they blamed my imap server. imap or imap-login? You can limit the max. number of imap processes from max_mail_processes setting and imap-login processes from login_max_processes_count. So by default it'll create max. 1024+128 processes. If this is too much for your server then you can drop them to some more reasonable limits.. Any way I can find out if it's really dovecot that's causing this? I recognize it might not be a dovecot issue, but it's the only hint i've got right now. I guess the only way would be to find out how many imap processes really were running at that time, but there's no really easy way to do that. You'd have to be looking at the login/logout lines and figure it out based on them.. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Error - Mailbox conversion: Failed to create destination storage with data
On 6.4.2007, at 15.36, Mart Pirita wrote: dovecot: Apr 06 15:16:13 Error: POP3(spam): Mailbox conversion: Failed to create destination storage with data: maildir:/home/ testMaildir This should fix it: http://dovecot.org/list/dovecot-cvs/2007-April/ 008619.html PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] 1.0.rc30 released
On 6.4.2007, at 21.14, Justin McAleer wrote: Timo Sirainen wrote: On 6.4.2007, at 17.55, Justin McAleer wrote: Timo, in rc30, deliver is not creating user directories properly. It looks like it goes straight to creating the maildir, without creating the home directory first if it doesn't exist. It also seems to be doing this before chrooting, as the following errors occur even after manually creating the home directory (with proper permissions): Apr 6 10:26:23 node7 postfix/qmgr[21815]: D2242D39A5: from=, size=556, nrcpt=1 (queue active) Apr 6 10:26:23 node7 deliver([EMAIL PROTECTED]): mkdir(/cur) failed: Permission denied Looks like deliver doesn't chroot at all if you did chrooting by using /./ in the home directory. Since deliver doesn't work that great chrooted anyway (can't send bounces by running sendmail), maybe this is a good thing. For the record, I was not using /./ in the home directory. For this user the home directory (and maildir) is /var/mailstore/af/4f/ 510590. While that may be a good thing, that deliver fails to create a user's maildir is a big problem for me, as I will have to actively provision maildirs for all new accounts before they can receive mail (or be converted)... so for the record, can I no longer count on dovecot to create user directories that don't exist? Umm. So are you even trying to use the chrooting? Deliver doesn't try to do that by default. So if it's trying to create /cur directory, it sees the mail directory as /. Also, the convert plugin seems to assume the home dir exists when it tries to create it's lock file. However, manually creating the home dir does allow convert to continue successfully. This happens only if it the source storage creation succeeds. So you're moving user's home directory also? All I'm dealing with here is mail. I'm converting from CommuniGate mailboxes to dovecot, so the whole concept of a home directory is just a technicality. In fact, I was initially just setting users' home to '' and using the mail_location setting to generate the path. The only reason I went back to setting home is because convert seems to create it's lock file in the home dir (so lock creation was failing trying to open /.temp...). Here is what I'm feeding to convert: Yea, it does. Maybe you could set the home directory to be the CommuniGate's directory? In any case I don't really like the idea of convert plugin creating home directory. An alternative is for you to create the home directory yourself before Dovecot runs: http://wiki.dovecot.org/PostLoginScripting PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Inbox inside the mail location
On Sat, 2007-04-07 at 10:55 +0300, Timo Sirainen wrote:
On 7.4.2007, at 3.11, guenther wrote:
However, I'd like to confirm what I see is how it is expected to work.
Since the Inbox with this layout is is part of the ~/.mail dir just like
any other mbox file (or subdir), I am concerned with getting a second
Inbox mail folder in the client. I did not, which is great.
So, is this expected behavior, and the Inbox mbox file actually being
the Inbox and only the Inbox? Will it always be excluded from the list
of IMAP mail folders?
INBOX is actually always included in the list of IMAP folders.
Dovecot anyway does all kinds of duplicate checking so it won't
return the INBOX multiple times in any situation.
I see, thanks, Timo. :)
Coincidentally I came across a similar example to what I have in mind
(inbox being implicitly inside the mail_location by not specifying
INBOX) by reading the docs and checking for some general tweaking and
options.
Btw, long time no see -- it's been a while since you have been hanging
out in #evolution at GimpNET. Nice to meet you again.
guenther
--
char *t=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Dovecot] MANAGESIEVE patch v4 for dovecot 1.0.rc28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Bosch schrieb: Hello dovecot users, I have updated the MANAGESIEVE patch to fix the currently known small problems with the protocol implementation. It is designed for rc28, but also compiles cleanly with the current cvs branch_1_0. Change Log V4 - - Added managesieve_implementation_string setting to the managesieve configuration. This can be used to customize the default IMPLEMENTATION capability response (as requested by John Peacock). - Denied ANONYMOUS login until proper support is implemented - Fixed problem with authenticate command regarding continued responses. In V3 only initial response would work. Problem was caused by rc2 - rc28 upgrade. One of the clear reasons why code duplication is a very bad idea. - Fixed readlink bug as indicated by Timo: return value of readlink can also be -1. - Fixed bug in the regular file rescue code, as introduced in the previous version. Used stat instead of lstat. This caused the symlink to be rescued subsequently in the next activation, thus still overwriting the initially rescued script. This patch still includes (yet another) instance of the CMU Sieve source, as explained in one of my previous e-mails (http://dovecot.org/list/dovecot/2006-July/015016.html). It can be downloaded at: http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc28-MANAGESIEVE-v4.diff.gz A design related README is located at src/managesieve after applying the patch. Have fun testing the patch. Notify me when there are problems. Regards, -- Stephan Bosch [EMAIL PROTECTED] IRC: Freenode, #dovecot, S[r]us Hi Stephan, i have success with patch dovecot with your patch but having problems in understanding how to configure the sieve server in dovecot.conf , do you have some small faqs for me, the readme wasnt enough for me to do this - -- Mit freundlichen Gruessen Best Regards Robert Schetterer https://www.schetterer.org Munich/Bavaria/Germany -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGF4BdfGH2AvR16oERAoAEAJ40YWzPARtH9SJA+fksKk5PKX2cDACffURP zMBDPCYmlGS6os33C23r/Gc= =I0O5 -END PGP SIGNATURE-
Re: [Dovecot] Shared mailbox plans
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Timo Sirainen schrieb:
** Configuration **
namespace shared {
prefix = user/%u/
location = maildir:/home/%u/Maildir:INDEX=~/Maildir/shared-indexes
}
So the only difference to how it's configured now is that %u is expanded
to whatever user whose mailboxes we're accessing. ACL plugin then uses
that user as the owner in the namespace's mailbox owner. Since the
default ACL is to not give any access to non-owners, the mailboxes
without dovecot-acl files will be invisible.
If ACL plugin isn't loaded, I suppose the mailboxes can be accessed if
the process has filesystem permissions to access them.
** ACL vfile speedups **
Currently it stat() the dovecot-acl file a bit too often. It doesn't do
it more than once a second, but there's really no need to do it even
that often. I guess it could be changed to be configurable with default
being something like 5 minutes.
Create a new dovecot-acl-list file which lists all the mailboxes which
have dovecot-acl file with l right (visible in mailbox list) to any
non-owner. It could be in timestamp mailbox name format. This
allows other users to quickly get a list of mailboxes that are
potentially visible to them. They still need to read the dovecot-acl
file from the mailbox before knowing for sure.
If the dovecot-acl-list file doesn't exist or if at any time any
timestamp doesn't match dovecot-acl file's current mtime, the file is
rebuilt by looking into all mailboxes' dovecot-acl files (if the reading
user has write permissions to the directory, otherwise it just keeps it
in memory). Whenever Dovecot modifies dovecot-acl file, it also updates
the dovecot-acl-list file. This means that the file can contain stale
data only if a new dovecot-acl file is created without updating
dovecot-acl-list file. Even that will be fixed the next time the owner
does a LIST (or select the mailbox, or anything that causes its
dovecot-acl file to be stated), which causes ACL plugin to notice the
desync.
There exist also global ACL files. These need to be included in the
dovecot-acl-list file as well. The only issue with them is that user
doesn't necessarily have a mailbox even though the global ACL file
exists. So these need to be marked somehow in the dovecot-acl-list file
as non-existing mailboxes. Then if user creates a mailbox with such
name, the mark is removed. Deleting the mailbox puts the mark back.
After the visible mailbox list has been figured out once, only the
dovecot-acl-list file needs to be stat()ed once in a while instead of
all the mailboxes' dovecot-acl files.
** User list **
The next problem is how to quickly get a list of users whose mailboxes
are visible to ourself so they can be included in mailbox list. I
couldn't figure out anything new and great for this, so the options are
the same as in http://dovecot.org/list/dovecot/2006-October/017082.html
Although for dict backend I could make it a bit more secure. Currently
dict has private and shared read-write options to store the data
with. The shared users list could be done with shared read-only.
** Virtual domains **
ACL plugin could support virtual [EMAIL PROTECTED] to give access to
usernames ending with @domain. Or perhaps the group could support
wildcards? [EMAIL PROTECTED]? That way it wouldn't be required to have @
really in the username.
Anyway, I think anyone should then be aliased to [EMAIL PROTECTED]. If
there are multiple virtual domains and you let the users manipulate the
ACLs themselves, I'd think they want anyone to mean anyone within my
domain (my organization) rather than really anyone who just happens to
be using the same server.
I think it would also be annoying if anyone could really force their own
mailboxes to be visible to a lot of people. That could be used for
spamming as well..
If administrator wants to have global mailboxes that really are visible
to all domains, they could be done with public namespaces (not shared).
** Quota **
This is kind of problematic. The behavior depends entirely on quota
backend:
- Filesystem quota of course tracks the quota based on the file's owner
- Maildir++ quota counts the quota for the user whose maildir the
shared mailbox exists in. This means it also requires filesystem level
access to maildirsize file, otherwise the quota updating happens
sometimes later when the quota is recalculated.
- Dict quota.. I think it'll need a new path for each shared mailbox,
which is modifiable by any user. So while your own quota would exist in
private/quota/storage, the shared mailboxes' quota would exist in
shared/quota/storage. This means that the dict quota needs to be able to
know what mailboxes the current user has shared. It also gets a bit
tricky to update the quota if mailbox is unshared. The quota could be
tracked individually for each mailbox also, but I'm not sure if that's
such a great idea
Re: [Dovecot] Error - Mailbox conversion: Failed to create destination storage with data
Tere. On 6.4.2007, at 15.36, Mart Pirita wrote: dovecot: Apr 06 15:16:13 Error: POP3(spam): Mailbox conversion: Failed to create destination storage with data: maildir:/home/testMaildir This should fix it: http://dovecot.org/list/dovecot-cvs/2007-April/008619.html Pathed the v1.30 failed: patch -p0 paik patching file convert-storage.c Hunk #1 FAILED at 251. Hunk #2 succeeded at 278 with fuzz 2 (offset -3 lines). Hunk #3 succeeded at 289 with fuzz 2. 1 out of 3 hunks FAILED -- saving rejects to file convert-storage.c.rej But I added it manually, and it works great, Maildir will be automatically created thank You. -- Mart
Re: [Dovecot] Shared mailbox plans
On 7.4.2007, at 14.31, Robert Schetterer wrote: for acl public folders with virtual domains, wouldnt it be a good idea to have them in sql as backend? Why? PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Shared mailbox plans
On 7.4.2007, at 19.02, Troy Engel wrote: What I was finding with testers is that each person's login process was rewriting permissions on the subscriptions file and the index files didn't work out for the same reason; 1 person would drop an email into a subfolder (MissedSpam e.g.), Dovecot would write indexes 0600 to that named user then everyone else would start getting errors. You'll need to create dovecot-shared file as http://wiki.dovecot.org/ SharedMailboxes describes. Although it doesn't affect the subscriptions file. I'll have to figure out what to do with subscriptions in general. I think all the subscriptions for all the namespaces should exist in a single file. PGP.sig Description: This is a digitally signed message part
[Dovecot] Fully virtualized w/ postfix?
Hi folks, I've poked through the archives and google and have not seen how do do this. Is it possible to virtualize ALL emails on a system? That is, I want delivery only to e.g. /var/mail/vmail/domain.tld/user/Maildir/, and for authentication userdb to: 1) Try /etc/passwd, and if someone is there, automatically append the default domain, otherwise, 2) Authenticate off a mysql db or similar. Is this kind of fallthrough user lookup and auth. possible with dovecot? I assume the delivery can probably be done by just telling postfix to use dovecot as the local delivery agent. Thanks for your help! --JB
Re: [Dovecot] Fully virtualized w/ postfix?
If you want #1, it seems that you're not really looking to virtualize all emails on the system, but rather have fall-through virtualization. I don't know if that's possible or not. I *do* know, because I have it set up this way, that's it possible to virtualize everything, and then, in your database, specifically say what needs to get delivered to the local box. I needed to do that for mailman lists. Anyway, for postfix, look into the virtual_* config options. For dovecot, I'm still running 1.0beta8, which is a few versions behind, so I don't know what to look for these days. FWIW, I use passdb sql and userdb static. On Apr 7, 2007, at 9:23 AM, [EMAIL PROTECTED] wrote: Hi folks, I've poked through the archives and google and have not seen how do do this. Is it possible to virtualize ALL emails on a system? That is, I want delivery only to e.g. /var/mail/vmail/domain.tld/user/Maildir/, and for authentication userdb to: 1) Try /etc/passwd, and if someone is there, automatically append the default domain, otherwise, 2) Authenticate off a mysql db or similar. Is this kind of fallthrough user lookup and auth. possible with dovecot? I assume the delivery can probably be done by just telling postfix to use dovecot as the local delivery agent. Thanks for your help! --JB
Re: [Dovecot] Fully virtualized w/ postfix?
On 19:26:45 2007-04-07 Ben [EMAIL PROTECTED] wrote: 2) Authenticate off a mysql db or similar. I have a fully virtualised mail system based on sqlite database with exim and dovecot and deliver. Basicaly you tell the MTA where to check for accounts to accept mails Tell dovecot and deliver where to auth and find account dirs And that's about it :)
Re: [Dovecot] chdir failed, but requires group permissions
Thanks for the suggestion, That's a good idea, but unfortunately where the home directories lie, the users actually need to be members of 2 groups - so they both can't be primary. However, it seems odd to me that Dovecot would REQUIRE access to the $HOME directory, when I am only using it to pop mail from /var/mail (which it has full access to) - and I am not using imap access at all. Brent. -Original Message- From: Timo Sirainen [mailto:[EMAIL PROTECTED] Sent: Fri 4/6/2007 1:01 AM To: Brent Nesbitt Cc: dovecot@dovecot.org Subject: Re: [Dovecot] chdir failed, but requires group permissions On 4.4.2007, at 1.48, Brent Nesbitt wrote: My home directories are set up with 770 permissions as follows: /home/group name/user name Using this method, users MUST be a member of the appropriate group to access their own home directory. If they are not, they can't chdir past /home. Could the group be the user's primary group? Then it works. Otherwise there's not much else you can do except modify the sources.
Re: [Dovecot] chdir failed, but requires group permissions
On 7.4.2007, at 20.35, Brent Nesbitt wrote: However, it seems odd to me that Dovecot would REQUIRE access to the $HOME directory, when I am only using it to pop mail from /var/ mail (which it has full access to) - and I am not using imap access at all. Well, you don't HAVE to give Dovecot any home directory at all. See the bottom of http://wiki.dovecot.org/MailLocation/Mbox PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Fully virtualized w/ postfix?
On 7.4.2007, at 19.23, [EMAIL PROTECTED] wrote: 1) Try /etc/passwd, and if someone is there, automatically append the default domain, otherwise, auth_default_realm is probably helpful here. Is this kind of fallthrough user lookup and auth. possible with dovecot? http://wiki.dovecot.org/Authentication/MultipleDatabases PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] chdir failed, but requires group permissions
Thanks - I hadn't seen that before. If I'm understanding what you're getting at, you're referring to: Modify mail_location setting so that the mail root directory is also the empty directory and append :INDEX=MEMORY to it. For example: mail_location = mbox:/var/empty:INBOX=/var/mail/%u:INDEX=MEMORY Which unfortunately, doesn't work. Even with these settings, or putting mbox, INBOX, INDEX all in /var/mail - dovecot still fails after successful authentication with an error that it can't chdir to the mail user's home directory; which, of course, it can't - but again, it shouldn't need to. -Original Message- From: Timo Sirainen [mailto:[EMAIL PROTECTED] Sent: Sat 4/7/2007 10:43 AM To: Brent Nesbitt Cc: dovecot@dovecot.org Subject: Re: [Dovecot] chdir failed, but requires group permissions On 7.4.2007, at 20.35, Brent Nesbitt wrote: However, it seems odd to me that Dovecot would REQUIRE access to the $HOME directory, when I am only using it to pop mail from /var/ mail (which it has full access to) - and I am not using imap access at all. Well, you don't HAVE to give Dovecot any home directory at all. See the bottom of http://wiki.dovecot.org/MailLocation/Mbox
[Dovecot] How to get rid of locks
Although Dovecot is already read-lockless and it uses only short- lived write locks, it's be really nice to just get rid of the locking completely. :) I just figured out that O_APPEND is pretty great. If the operating system updates seek position after writing to a file opened with O_APPEND, writes to Dovecot's transaction log file can be made lockless. I see that this works with Linux and Solaris, but not with OS X. Could you BSD people try if it works there? http://dovecot.org/ tmp/append.c and see if it says offset = 0 (bad) or non-zero (yay). The O_APPEND at least doesn't work with NFS, so it'll have to be optional anyway. Currently Dovecot always updates dovecot.index file after it has done any changes. This isn't really necessary, because the changes are already in transaction log, so the dovecot.index file can be read to memory and the new changes applied on top of it from transaction log (this is pretty much how mmap_disable=yes works). So I'm going to change this to work so that the dovecot.index is updated only if a) there are enough changes in transaction log (eg. 8kB or so) and b) it can be write-locked without waiting. Maildir then. It has this annoying problem that readdir() can skip files if another process is rename()ing them, causing Dovecot to think that the message was expunged. The only way I could avoid this by locking the maildir while synchronizing it. Today I noticed that this doesn't happen with OS X. I'm not sure if I was just lucky or if there really is something special implemented in it, because it doesn't work anywhere else. I'm not sure if this is tied to HFS+, or if it will work with zfs also (Solaris+zfs didn't work). So perhaps the locking could be disabled while running with OS X. More importantly I figured out that it can also be avoided with Linux +inotify. As long as the inotify event buffer doesn't overflow, the full list of files can be read by combining the readdir() output and files listed by inotify events. If the inotify buffer overflows (highly unlikely), the operation can just be retried and it most likely works the next time. So with these changes in place, changing a message flag or expunging a message would usually result in: - lockless write() call to dovecot.index.log - lockless read()ing (or looking into mmaped) dovecot.index.log to see if there's some new data besides what we just wrote that needs to be synchronized to maildir - rename() or unlink() calls to maildir. If a call return ENOENT, the maildir needs to be readdir()ed with inotify enabled to find the new filename. Not a single lock in the operation, assuming that dovecot.index file wasn't updated. Assigning UIDs to newly delivered mails would require locking though. dovecot-uidlist needs to be locked, and the UIDs need to be written to dovecot.index.log file in the correct order, which can also be done with dovecot-uidlist locking. Actually a single write() to dovecot.index.log isn't enough. I think there needs to be some kind of a flag written to the beginning of the transaction which marks the transaction as truly finished. If the flag isn't there, any reader knows to stop and wait until the flag is set. So this means that the writer needs to: 1. Do a single O_APPENDed write() call writing the whole transaction 2. Get the current offset with lseek(fd, 0, SEEK_CUR) (this is what the append.c tester checks) 3. pwrite() the finished-flag to beginning of the transaction Except at least with Linux pwrite() doesn't work if O_APPEND is enabled. There are two ways to work around this: a) fcntl(disable O_APPEND) + pwrite() + fcntl(enable O_APPEND) b) Keep two file descriptors open for the transaction log. First with O_APPEND flag and second without. pwrite() to the second one. a) is probably better because it doesn't waste file descriptors. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] chdir failed, but requires group permissions
On 7.4.2007, at 21.56, Brent Nesbitt wrote: Which unfortunately, doesn't work. Even with these settings, or putting mbox, INBOX, INDEX all in /var/mail - dovecot still fails after successful authentication with an error that it can't chdir to the mail user's home directory; which, of course, it can't - but again, it shouldn't need to. Yes, but I meant that you could change the userdb not to return a home directory at all for users. Or are you using passwd as userdb? Then it gets trickier.. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] chdir failed, but requires group permissions
On 7.4.2007, at 22.36, Brent Nesbitt wrote: Yes, I am using passwd - as I also have webmail using these same logins - so changing the actual home directory won't work either. At this point I am using popa3d instead of dovecot - but Dovecot is a much more capable program, so I thought it SHOULD have worked. Dovecot doesn't work that great with multiple groups currently. You could always modify the sources to just disable the chdir(). It's not that important. Perhaps I should just move it later after the privileges are really dropped. I'm not actually sure why it's done earlier. The code related to it is pretty huge already. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] How to get rid of locks
On Sat, Apr 07, 2007 at 10:30:25PM +0300, Timo Sirainen wrote: I just figured out that O_APPEND is pretty great. If the operating system updates seek position after writing to a file opened with O_APPEND, writes to Dovecot's transaction log file can be made lockless. I see that this works with Linux and Solaris, but not with OS X. Could you BSD people try if it works there? http://dovecot.org/ tmp/append.c and see if it says offset = 0 (bad) or non-zero (yay). FreeBSD 5.2: 5,10,15 etc, so yay ancient BSD/OS: ditto [my FreeBSD 6.2 system is unavailable at the moment, but I can't imagine that they broke it there] mm
Re: [Dovecot] Outlook: incoming mail lands in sent folder
Finally, why does Outlook suck? Outlook is - and always has been - designed first and foremost as a client for Microsoft Exchange. It actually works very well in that environment. It also woakrs reasonably well as a standlone POP client, but its IMAP support has always been lees than happy-making. I'll be *really* happy when the Mozilla Sunbird Project is mature, and Lightning is a full featured, fully functional Calendar extension for Thunderbird. -- Best regards, Charles
Re: [Dovecot] MANAGESIEVE patch v4 for dovecot 1.0.rc28
Andraž 'ruskie' Levstik schrieb:
On 13:28:29 2007-04-07 Robert Schetterer [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Bosch schrieb:
Hello dovecot users,
I have updated the MANAGESIEVE patch to fix the currently known small
problems with the protocol implementation. It is designed for rc28,
but also compiles cleanly with the current cvs branch_1_0.
Hi Stephan,
i have success with patch dovecot with your patch
but having problems in understanding how to configure the sieve server
in dovecot.conf , do you have some small faqs for me, the readme wasnt
enough for me to do this
I needed to do the following:
to my protocols line added managesieve
protocols = imap managesieve
Then added a protocol managesieve with:
protocol managesieve {
listen = *:2000
login_executable = /usr/libexec/dovecot/managesieve-login
mail_executable = /usr/libexec/dovecot/managesieve
}
That's what was needde to gt it working here...
--
Andraž ruskie Levstik
Source Mage GNU/Linux Games grimoire guru
Geek/Hacker/Tinker
Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html
Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C
Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Hi Andraž
thx i will try that
--
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Munich/Bavaria/Germany
Re: [Dovecot] Shared mailbox plans
Timo Sirainen schrieb: On 7.4.2007, at 14.31, Robert Schetterer wrote: for acl public folders with virtual domains, wouldnt it be a good idea to have them in sql as backend? Why? Hi Timo, as imap clients that are able to edit imap acls are rare ( thunderbird, Outlook cant do it yet i think ) i think it would be helpfull to have acls in sql for writing php clients i.e squirrelmail plugins etc, or do i fail here? -- Mit freundlichen Gruessen Best Regards Robert Schetterer https://www.schetterer.org Munich/Bavaria/Germany
Re: [Dovecot] MANAGESIEVE patch v4 for dovecot 1.0.rc28 / problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Schetterer schrieb:
Andraž 'ruskie' Levstik schrieb:
On 13:28:29 2007-04-07 Robert Schetterer [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan Bosch schrieb:
Hello dovecot users,
I have updated the MANAGESIEVE patch to fix the currently known small
problems with the protocol implementation. It is designed for rc28,
but also compiles cleanly with the current cvs branch_1_0.
Hi Stephan,
i have success with patch dovecot with your patch
but having problems in understanding how to configure the sieve server
in dovecot.conf , do you have some small faqs for me, the readme wasnt
enough for me to do this
I needed to do the following:
to my protocols line added managesieve
protocols = imap managesieve
Then added a protocol managesieve with:
protocol managesieve {
listen = *:2000
login_executable = /usr/libexec/dovecot/managesieve-login
mail_executable = /usr/libexec/dovecot/managesieve
}
That's what was needde to gt it working here...
--
Andraž ruskie Levstik
Source Mage GNU/Linux Games grimoire guru
Geek/Hacker/Tinker
Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html
Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C
Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Hi Andraž
thx i will try that
Hi,ok setui above works
using avelsieve squirrelmail plugin
with managesieve dovecot latest
(perhaps i shouldnt use 1.30 rc)
as well there may be other problems between suse and quotawarn patches )
please see this just as info to help coders to debug
following problems in logs appear
/var/log/messages
9 04:51:41 suse10-2-vmware kernel: managesieve-log[2326]: segfault at
rip rsp 7fff8995b938 error 14
i have no idea where this comes from
/var/log/dovcot.info
dovecot: Apr 09 04:55:00 Info: IMAP([EMAIL PROTECTED]): Disconnected:
Logged out
dovecot: Apr 09 04:55:08 Info: managesieve-login: Login:
user=[EMAIL PROTECTED], method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS
dovecot: Apr 09 04:55:08 Info: MANAGESIEVE([EMAIL PROTECTED]): Effective
uid=1001, gid=1001
dovecot: Apr 09 04:55:08 Info: MANAGESIEVE([EMAIL PROTECTED]): sieve
storage: Using active sieve script path:
/usr/local/virtual/[EMAIL PROTECTED]//.dovecot.sieve
( this line looks strange to me, but it musnt be false )
dovecot: Apr 09 04:55:08 Info: MANAGESIEVE([EMAIL PROTECTED]): sieve
storage: Using mail-data: maildir:/usr/local/virtual/[EMAIL PROTECTED]/
dovecot: Apr 09 04:55:08 Info: MANAGESIEVE([EMAIL PROTECTED]): sieve
storage: Using sieve script storage path:
/usr/local/virtual/[EMAIL PROTECTED]/
dovecot: Apr 09 04:55:08 Info: MANAGESIEVE([EMAIL PROTECTED]): sieve
storage: Relative path to sieve storage in active link:
dovecot: Apr 09 04:55:08 Info: MANAGESIEVE([EMAIL PROTECTED]): Disconnected
in squirrlemail avelsieve
C: IMPLEMENTATION dovecot\r\n
C: SASL PLAIN\r\n
C: SIEVE FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY
SUBADDRESS RELATIONAL COMPARATOR-I;ASCII-NUMERIC\r\n
C: STARTTLS\r\n
C: OK Welcome\r\n
S: STARTTLS\r\n
C: OK Begin TLS negotiation now.\r\n
S: CAPABILITY\r\n
C: IMPLEMENTATION dovecot\r\n
C: SASL PLAIN\r\n
C: SIEVE FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY
SUBADDRESS RELATIONAL COMPARATOR-I;ASCII-NUMERIC\r\n
C: OK TLS negotiation successful.\r\n
S: AUTHENTICATE PLAIN {72+}\r\n
S:
dGVzdGVyQGRhcmtjaGF0cm9vbS5kZQB0ZXN0ZXJAZGFya2NoYXRyb29tLmRlAHRlc3Rlcg==\r\n
C: IMPLEMENTATION dovecot\r\n
C: SASL PLAIN\r\n
C: SIEVE FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY
SUBADDRESS RELATIONAL COMPARATOR-I;ASCII-NUMERIC\r\n
C: OK Capability completed.\r\n
S: CAPABILITY\r\n
C: OK Logged in.\r\n
S: PUTSCRIPT phpscript {777+}\r\n# This script has been automatically
generated by avelsieve\n# (Sieve Mail Filters Plugin for
Squirrelmail)\n# Warning: If you edit this manually, then the changes
will not \n# be reflected in the users'
front-end\!\n#AVELSIEVE_VERSIONYTo0OntzOjU6Im1ham9yIjtpOjE7czo1OiJtaW5vciI7aTo5O3M6NzoicmVsZWFzZSI7aTo3O3M6Njoic3RyaW5nIjtzOjU6IjEuOS43Ijt9\n#AVELSIEVE_CREATED1176087308\n#AVELSIEVE_MODIFIED1176087308\nrequire
[];\nif\n#START_SIEVE_RULEYTo0OntzOjQ6ImNvbmQiO2E6MTp7aTowO2E6NDp7czo0OiJ0eXBlIjtzOjY6ImhlYWRlciI7czo2OiJoZWFkZXIiO3M6NjoidG9vcmNjIjtzOjk6Im1hdGNodHlwZSI7czo4OiJjb250YWlucyI7czoxMToiaGVhZGVybWF0Y2giO3M6MzoiKioqIjt9fXM6NDoidHlwZSI7czoxOiIxIjtzOjk6ImNvbmRpdGlvbiI7czozOiJhbmQiO3M6NjoiYWN0aW9uIjtzOjE6IjIiO30%3DEND_SIEVE_RULE\nheader
:contains [to, cc] ***\n{\ndiscard;\n}\r\n
C: IMPLEMENTATION dovecot\r\n
C: SIEVE FILEINTO REJECT ENVELOPE VACATION IMAPFLAGS NOTIFY
SUBADDRESS RELATIONAL COMPARATOR-I;ASCII-NUMERIC\r\n
C: OK Capability completed.\r\n
S: SETACTIVE phpscript\r\n
C: NO line 8: Unsupported features in require line\r\n
- --
Mit freundlichen Gruessen
Best Regards
Robert Schetterer
https://www.schetterer.org
Munich/Bavaria/Germany
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5
Re: [Dovecot] How to get rid of locks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Timo Sirainen wrote on 7-4-2007 21:30: Could you BSD people try if it works there? http://dovecot.org/tmp/append.c and see if it says offset = 0 (bad) or non-zero (yay). The O_APPEND at least doesn't work with NFS, so it'll have to be optional anyway. 5.4-RELEASE-p6: yay 6.0-RELEASE: yay Greets, Nils -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) iD8DBQFGGDMqMzNX/a06Wq0RAkhiAJ9RjtMRHDRASuHiIrCxmPTJZZ1MFwCfasOR 6W2/mjFuPyf7jbTQfe6zpII= =Y9Zk -END PGP SIGNATURE-
