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;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Dovecot] Shared mailbox plans
** 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 " " 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 either.
Perhaps a new quota backend coul
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 " " 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 cou
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] MANAGESIEVE patch v4 for dovecot 1.0.rc28
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
[Dovecot] Outlook: incoming mail lands in "sent" folder
The first word of the subject line probably says enough and shows my predisposition. Actually I used to like Outlook until we switched to IMAP, at which point my love turned to hate. I have a single user on Outlook 2007 complaining about (a) mail "stuck" in the outbox that is not delivered (until we reboot windows) and (b) mail showing up in the "sent" folder that was not originated by this user (as in "incoming mail"). Neither of these issues are consistent, but I have seen them with my own tired eyes. The user employs a horrific combination of Outlook and Act! (CRM with a pathetic Outlook clone which pitifully replaces the Outlook UI). They also have Outlook clients on two other machines. They have three accounts on the same server. It's only happening on one of them. We've turned off Outlook "rules" completely to be certain it's not user-induced. The probability of these two issues being Dovecot (or SMTP for the outgoing issue) are about as high as the existence of an orbiting teapot, but to satisfy the user and hopefully wean them off the Outlook drug I must show that the server isn't the culprit. Therefore I must do some very fine logging, but for this users' account only. Is this level of logging possible? - per user - per function - excluding spam processing Have others (perhaps countless?) encountered these same issues? Finally, why does Outlook suck? /m
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
Timo Sirainen wrote:
If ACL plugin isn't loaded, I suppose the mailboxes can be accessed if
the process has filesystem permissions to access them.
Kind of, but it doesn't really work in real life. I tried setting it up
initially around... say 1.0rc23 and it runs into permissions problems
writing the various dovecot.index files because they're 0600 mode to
that specific imap logged in user.
The config (commented out right now) looks like: (*)
# Spam Training
namespace public {
separator = .
prefix = SpamTraining.
location = maildir:/var/spool/imap_shared/SpamTraining
}
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.
Unfortunately I didn't have the time to do massive debugging right then
so just had to comment it out and save it for another day. :-/
-te
(*) right now it works with gnarly ugly symlinks in a user's ~/Maildir
under Courier-IMAP, and I have two shellscripts that nightly read the
contents of two subfolders - MissedSpam and FalsePositives - and passes
those to SpamAssassin with 'sa-learn --spam' e.g. then deletes each mail
file.
--
Troy Engel | Systems Engineer
Fluid Inc. | http://www.fluid.com
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// > > 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
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. Brent. -Original Message- From: Timo Sirainen [mailto:[EMAIL PROTECTED] Sent: Sat 4/7/2007 12:33 PM To: Brent Nesbitt Cc: dovecot@dovecot.org Subject: 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..
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 Apr 7, 2007, at 12:30, Timo Sirainen wrote: 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. I tested on Mac OS X. Works on Intel (offset = 5), but not PowerPC (offset = 0)... Both are running 10.4.9. Kernel versions: Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Darwin Kernel Version 8.9.1: Thu Feb 22 20:55:00 PST 2007; root:xnu-792.18.15~1/RELEASE_I386 -jim
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] How to get rid of locks
Timo Sirainen wrote: 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). OpenBSD 3.9 and 4.0 (i386) both give me 5, 10, 15 and so on, so yay! /Johan
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 i
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-
Re: [Dovecot] How to get rid of locks
Hi Timo, > 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 6.2: offset = 5 FreeBSD 4.10: offset = 5 FreeBSD 4.7: offset = 5 NetBSD 3.0.1: offset = 5 Cor
Re: [Dovecot] Shared mailbox plans
On 8.4.2007, at 1.04, Robert Schetterer wrote: 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? Keeping ACLs in SQL is different from keeping the whole mailbox data in SQL. Currently the ACL plugin supports only vfile backend, but it wouldn't be too difficult to add support for SQL backend. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Outlook: incoming mail lands in "sent" folder
On 7.4.2007, at 15.37, Mark Richards wrote: The probability of these two issues being Dovecot (or SMTP for the outgoing issue) are about as high as the existence of an orbiting teapot, but to satisfy the user and hopefully wean them off the Outlook drug I must show that the server isn't the culprit. Therefore I must do some very fine logging, but for this users' account only. Is this level of logging possible? a) rawlog logs all the IMAP traffic: http://dovecot.org/bugreport.html b) mail_log plugin: http://wiki.dovecot.org/Plugins/MailLog PGP.sig Description: This is a digitally signed message part
