Re: [Dovecot] PATCH Deliver forgets sendmail_path if DEBUG is set
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 13 May 2007, Timo Sirainen wrote: + putenv(DEBUG); /* BTW this is a short living fork + of deliver */ putenv() without '=' in the string isn't a standard, so I didn't want to use that when I wrote the code. Oh, I wasn't aware of it. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRkgguy9SORjhbDpvAQJLHwgAyPadcaJjJ2u7T0Mlbr1IlQjshkQE5Osa nPDCgdBoguAx2gOl/HJje0BXqLTepYJNKLZEV/KsjXtsNjafyDraFA6Ax6j1EhaG fsso2S9Kg8plvvHeH+QzMLrQlBWRo6eQ5drgLlnfioG4FcPO6ZFGj3ItHT+3rJKG rzUybuTBm+nFMcO5KhbtWlqop94oH82Ud7vJDf9t5zigKfvcUtyr+D5CulMZrH5y MiJPSy4FMsgfNkDXiyJrtYZw6GjSujHpfKxwlTXQCQH0rpmkwm7mXUVUhvXWXhS6 IE3lWAkkhrD7hVQK1kwVxlHLwfAnmUSqc7PMrbByaQ8j0allxeFx8Q== =lBk4 -END PGP SIGNATURE-
Re: [Dovecot] PATCH: sendmail-like DSNs in Dovecot deliver (EX_TEMPFAIL always)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 13 May 2007, Timo Sirainen wrote: Since I can't think of any other modes, I'm going to look into adding LMTP to deliver ;-) sendmail supports LMTP even for a spawned LDA rather than a LMTP deamon. However, I don't know what to prefer. Shouldn't it be stderr, not stdout? Although I guess both might work. Well, I'm not sure. But as far as I know sendmail communicates primarily with stdin/stdout with the LDA (as inetd). However, for permanent failures both stdout and stderr are joint together. I haven't read the sendmail sources well enough to find the actual piece of code, though. For now I added the -e parameter. Currently it only works if the delivery actually fails. I'm not sure how I should handle rejections in Sieve scripts. http://dovecot.org/list/dovecot-cvs/2007-May/008761.html I think Dovecot should. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRkgiTy9SORjhbDpvAQJQXwgAvqA59iy/9iIbbyq5QxK+or0aslb1oBvf oLmnEsafskweYr0zUMnyKmV3UEWFn5Oh/oX/5azLA8TFeDfqf8lFwu1VfByngIW0 zzkDmA3+ldWgjqLVRegNMF94dChCdktMy7q1CWo0hBnLAtVIM+4X0u+OKZqKqEM0 F2bd2LYbeSeBGnTp6LkMi5y28r4u8+T6xJXrmn0TzDSiW3BAlLIgp11rlnn6UgoB 1LC0amTV9uaTzJTU0HB2u9p+DbCnfyLVeK3AQt7bNpIsVfE4AHMe6MClrt8W7ZBB AiU3P1h/p29oWT9EDsaclDTJMCJEmn995Eg/+jq6YTDFnk3WfbscLw== =hL0g -END PGP SIGNATURE-
Re: [Dovecot] How to get rid of locks
On Sat, 2007-04-07 at 22:30 +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. Well, almost. Log rotation isn't possible without some sort of locking. But the locks could still be reduced: - Normally keep the .log file read-locked all the time (multiple processes can have it read-locked) - Write to it with O_APPEND - If you notice that the log is going to be rotated soon, drop the read lock and acquire it only for the duration of appends - When the log is wanted to be rotated, try to get a write-lock. If it fails, try again later. If it succeeds, it's safe to rotate the log. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Deliver sending bounces from 'MAILER-DAEMON@'
Hello Timo, On 2007-05-11, 16:18, Timo Sirainen wrote: On Tue, 2007-04-24 at 12:49 +0200, Erland Nylend wrote: | Apr 24 11:42:08 smtp2 postfix/qmgr[6176]: 05BAE3B67E: from=, size=3055, nrcpt=1 (queue active) | Apr 24 11:42:08 smtp2 postfix/qmgr[6176]: 05BAE3B67E: to=MAILER-DAEMON@, relay=none, delay=0.01, delays=0.01/0.01/0/0, dsn=5.1.3, status=bounced (bad address syntax) .. It seems to me that dovecot is sending bounce messages from 'MAILER-DAEMON@' .. It says to=MAILER-DAEMON@ so I'd guess the Return-Path: header in the message was that? Could you have a look at this case again? The messages to deliver have the smtp mail from and Return-Path set to . (they're bounces) I can reproduce the problem by telnet'ing to the postfix server, and sending bounce mails to an account over quota. It seems that deliver is sending bounces on the bounces, which I think is an error. -- Erland Nylend
Re: [Dovecot] Problems with Shared Mailbox
On Fri, May 11, 2007 at 03:07:12PM +0300, Timo Sirainen wrote: On Mon, 2007-05-07 at 14:11 +0200, Gerhard Schmidt wrote: location = mbox:/var/mail/shared:CONTROL=/var/mail/shared/.control:INDEX=/var/mail/shared/.index mbox has no CONTROL directory. I've got this line from an Example on the Web. -rw-rw 1 dovecot vhsal 0 May 7 13:50 dovecot-shared -rw--- 1 estartu vhsal376 May 7 13:53 dovecot.index -rw-rw 1 dovecot vhsal 23552 May 7 13:53 dovecot.index.cache -rw-rw 1 dovecot vhsal 7116 May 7 13:53 dovecot.index.log How can I gate dovecot to set the permissions of this files to rw-rw mbox doesn't support dovecot-shared file either. So unfortunately this won't work. Also if you used maildir, the dovecot-shared would have to be in the maildir directory, not in the index directory. It was a Test. Didn't expect it to work. I've check the soucecode some. In lib-index/mail-index.c the file rights for the index files are hard set to 0600. I've changed this to 0660 and mbox shared mailboxes do function. It might be a bood idea to make this configurable. e.g. location = mbox:/var/mail/shared:INDEX=/var/mail/shared/.index;0660 Stetting the index mode globaly to 0660 is no problem in the enoirement my server is running but it is not option for most of the others. Bye Estartu -- Gerhard Schmidt| Nick : estartu IRC : Estartu | Fischbachweg 3 || PGP Public Key 86856 Hiltenfingen | EMail: [EMAIL PROTECTED] | on request Germany|| pgpT5wKoYxPdA.pgp Description: PGP signature
Re: [Dovecot] Thinking Outside the Box - Extending IMAP
On Sun, 2007-05-13 at 06:55 -0700, Marc Perkel wrote: Here's some thoughts I'd like to throw out there. I know it's not standard IMAP protocol but someone has to try new ideas first and I want to see what people (Timo) think of this. IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? Why do you always want to stuff everything into IMAP? For example, personalized server settings. Isn't there some protocol similar to IMAP that solves this? Who likes this idea? I strongly disagree with this idea. Too little definition, too much server dependence, not portable across installations. IMHO defining some behaviour that is so little related to the original purpose of IMAP is counterproductive. Besides, why do you need to do this with IMAP? There's a protocol that supports all this already, it's called ssh. You can even tunnel pre-auth IMAP tunnels through the same ssh connection :) johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Thinking Outside the Box - Extending IMAP
Vulpes Velox wrote: On Sun, 13 May 2007 06:55:59 -0700 Marc Perkel [EMAIL PROTECTED] wrote: Here's some thoughts I'd like to throw out there. I know it's not standard IMAP protocol but someone has to try new ideas first and I want to see what people (Timo) think of this. IMAP establishes a connection between the client and the server. Wouldn't it be great if it could be a conduit to let custom Thunderbird plugins talk to custom server application over the IMAP interface? For example, personalized server settings. Suppose for example I want Thunderbird to edit my server side white lists or black lists or any other setting? Wouldn't it be nice if IMAP supported these changes? The connection is made. It's a secure connection that's been authenticated. Lets use it! Here's my initial thoughts on this. Suppose we extended IMAP to include an EXECUTE command as follows: EXECUTE command parameter, parameter On the server side is a config file that has the commands that execute will allow and what programs they run. When the execute command is seen by Dovecot then Dovecot runs the program in the list with the parameters passed. For example, suppose there is a command to add a user to a server side blacklist. 100 execute blacklist add [EMAIL PROTECTED] 100 ok I like the idea of having to and from added to the w/b list. That way it would be way nicer to use with SpamAssassin. Dovecot would open a two way connection to the server application allowing the client to talk to any application that is configured and can send and receive text. The connection persists until the server end terminates or the client closes the connection. With a tool like this one can write generic applications easily that would greatly expand what email clients can do interacting with the server. Not only can setting be changes but you could interact with server side calendars, pick up voice messages from phone systems, run any sort of groupware, all over a generic IMAP connection with this simple extension. Example: 100 EXECUTE calendar 100 ok 100 list schedule today 8:00 10:00 100 8:00 make coffee 100 9:00 meeting with boss 100 9:30 Call Joe Blow at 415-555-1212 100 ok 100 quit 100 ok One thing I'd like to use it for is an outgoing SMTP connection to send outgoing email over IMAP. A session might look like this: 999 EXECUTE smtp 999 220 darwin.ctyme.com ESMTP Exim 4.67 Sun, 13 May 2007 06:52:26 -0700 999 helo ctyme.com 999 250 darwin.ctyme.com Hello localhost [127.0.0.1] 999 mail from:[EMAIL PROTECTED] 999 250 OK 999 rcpt to:dovecot@dovecot.org 999 250 Accepted .. 999 quit 999 OK Who likes this idea? I love that idea. Especially if it could run it through a specified program for deliver as well as passing the username, from, and password to the program. It may seem like a silly idea to pass that to the program, but it does have a awesome usage. That way the backend program can fetch the outgoing SMTP server through some method and figure out how to send it. Been kicking around writing something like that for QPSMTPD. It would be nice for with squirrelmail. I would think that when Dovecot executed the server end program that they would pass through in environment variables all the user name and connection info so that the server had that info for lookups.
[Dovecot] Maildir POP3 UID larger than next_uid bug
dovecot 1.0.0; Free BSD 6.2; x86; UFS; no NFS IMAP not uses at all, POP3 only Problem description: POP3 client can't fetch second e-mail message from Maildir if first POP3 connect occurs before any message placed in Maildir. Details: 1. POP3-client first time tries to receive mail: May 14 16:17:36 host dovecot: pop3-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=192.168.0.100, lip=192.168.0.3 May 14 16:17:36 host dovecot: POP3([EMAIL PROTECTED]): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 dovecot creates Maildir for that user: /var/mail/virtual/mydomain.ru/user/Maildir/ /cur /new /tmp dovecot.index dovecot.index.cache dovecot.index.log 2. Postfix MTA receives message for that user and places it at /var/mail/virtual/mydomain.ru/user/Maildir/new/1179145269.V43I3f5a4M116738.host.mydomain.local 3. POP3-client tries to receive mail: May 14 16:23:09 host dovecot: pop3-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=192.168.0.100, lip=192.168.0.3 May 14 16:23:09 host dovecot: POP3([EMAIL PROTECTED]): Disconnected: Logged out top=0/0, retr=1/786, del=1/1, size=770 dovecot creates file dovecot-uidlist with next_uid=1 (!!!): 1 1179145056 1 1 1179145269.V43I3f5a4M116738.host.mydomain.local:2, Message fetched successfully. 4. POP3-client tries to receive mail: May 14 16:23:29 host dovecot: pop3-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=192.168.0.100, lip=192.168.0.3 May 14 16:23:29 host dovecot: POP3([EMAIL PROTECTED]): UID larger than next_uid in file /var/mail/virtual/mydomain.ru/user/Maildir/dovecot-uidlist (1 = 1) May 14 16:23:29 host dovecot: POP3([EMAIL PROTECTED]): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 File dovecot-uidlist disappears. 5. Postfix MTA receives message for that user and places it at /var/mail/virtual/mydomain.ru/user/Maildir/new/1179145534.V43I3f5a4M116827.host.mydomain.local 6. POP3-client tries to receive mail: May 14 16:47:20 host dovecot: pop3-login: Login: user=[EMAIL PROTECTED], method=PLAIN, rip=192.168.0.100, lip=192.168.0.3 May 14 16:47:20 host dovecot: POP3([EMAIL PROTECTED]): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 Dovecot creates file dovecot-uidlist: 1 1179145056 2 1 1179145534.V43I3f5a4M116827.host.mydomain.local Dovecot moves message from new to cur directory and adds flag :2,: /var/mail/virtual/mydomain.ru/user/Maildir/cur/1179145534.V43I3f5a4M116827.host.mydomain.local:2, Message not fetched. And POP3 client can't fetch it at all. All next messages fetches normally as they arrives. # /usr/local/etc/dovecot.conf protocols: pop3 pop3s ssl_cert_file: /etc/ssl/certs/host.mydomain.ru.crt ssl_key_file: /etc/ssl/private/host.mydomain.ru.key disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/pop3-login login_greeting: POP3 server ready verbose_proctitle: yes first_valid_gid: 0 mail_extra_groups: mail mail_location: maildir:~/Maildir mail_executable: /usr/local/libexec/dovecot/pop3 mail_plugin_dir: /usr/local/lib/dovecot/pop3 pop3_uidl_format: %08Xu%08Xv pop3_client_workarounds: outlook-no-nuls oe-ns-eoh auth default: mechanisms: plain login digest-md5 cram-md5 apop ntlm default_realm: mydomain.ru passdb: driver: pam passdb: driver: passwd-file args: /etc/auth/%d/passwd userdb: driver: passwd userdb: driver: static args: uid=5000 gid=5000 home=/var/mail/virtual/%d/%n socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master:
Re: [Dovecot] Mails, work and so on
On Fri, May 11, 2007 at 07:41:53PM +0300, Timo Sirainen wrote: - Get the rewritten Squat full text search index working. It probably needs a name change, since it's not all that close to Cyrus Squat anymore. Suggestions? Could of course be just fts_dovecot. squatimo ? (or squatmo) Mr. Marcus's dovesquat was pretty good. mm
Re: [Dovecot] dbmail benchmarking
Could someone please update the dbmail wikipedia page with this info ;) http://en.wikipedia.org/wiki/DBMail_IMAP_and_POP3_server I suppose what would be nicer would be to extend the dovecot entry and reference that from the dbmail entry ;) On Sat, May 12, 2007 at 03:16:05AM +0300, Timo Sirainen wrote: I thought I'd try benchmarking with dbmail (v2.2.4) to see how much slower a SQL backend could actually be. Skip to bottom for the conclusions. Originally I ran the tests with the databases being in XFS filesystem. MySQL's performance was horrible. It went 3-7x faster with ext3. MySQL 5.0.30 backend (innodb): ./imaptest clients=1 - append=100 seed=1 secs=30 msgs=100 logout=0 Logi Sele Appe 100% 100% 100% 5% 1 291 303 So that's 10 messages/sec saved. Now how about with 5 concurrent clients? Logi Sele Appe 100% 100% 100% 5% 5 1259 1332 Pretty well. Then something more generic: ./imaptest clients=1 seed=1 secs=30 msgs=100 logout=0 Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe 100% 50% 50% 100% 100% 100% 50% 100% 100% 100% 30% 5% 1 37 36 75 73 110 34 24 73 78 Without Fetc (header/metadata fetching): Logi List Stat Sele Fet2 Stor Dele Expu Appe 100% 50% 50% 100% 100% 50% 100% 100% 100% 30% 5% 1 94 94 199 283 102 85 198 210 PostgreSQL 8.1.5 backend: ./imaptest clients=1 - append=100 seed=1 secs=30 msgs=100 logout=0 Logi Sele Appe 100% 100% 100% 5% 1 267 277 ./imaptest clients=5 - append=100 seed=1 secs=30 msgs=100 logout=0 Logi Sele Appe 100% 100% 100% 5% 5 1094 1144 ./imaptest clients=1 seed=1 secs=30 msgs=100 logout=0 Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe 100% 50% 50% 100% 100% 100% 50% 100% 100% 100% 30% 5% 9 29 40 74 72 99 22 12 64 71 ./imaptest clients=1 seed=1 secs=30 msgs=100 logout=0 fetch=0 Logi List Stat Sele Fet2 Stor Dele Expu Appe 100% 50% 50% 100% 100% 50% 100% 100% 100% 30% 5% 35 105 95 200 277 54 70 165 175 The last two tests gave Unexpected tagged reply: errors that I didn't get with MySQL. So apparently there's some PostgreSQL-specific bug in dbmail. The same values with Dovecot 1.0 + maildir: ./imaptest clients=1 - append=100 seed=1 secs=30 msgs=100 logout=0 Logi Sele Appe 100% 100% 100% 5% 1 346 364 ./imaptest clients=5 - append=100 seed=1 secs=30 msgs=100 logout=0 Logi Sele Appe 100% 100% 100% 5% 5 1408 1470 ./imaptest clients=1 seed=1 secs=30 msgs=100 logout=0 Logi List Stat Sele Fetc Fet2 Stor Dele Expu Appe 100% 50% 50% 100% 100% 100% 50% 100% 100% 100% 30% 5% 1 130 133 259 258 382 123 127 257 271 ./imaptest clients=1 seed=1 secs=30 msgs=100 logout=0 fetch=0 Logi List Stat Sele Fet2 Stor Dele Expu Appe 100% 50% 50% 100% 100% 50% 100% 100% 100% 30% 5% 1 155 163 339 478 169 175 338 354 So, what are the conclusions? - In raw append speed dbmail is almost as fast as maildir. - In raw read/write speed maildir is about 1,6 times faster - When adding metadata fetches Dovecot is 4 times faster than dbmail. This is most likely because dbmail doesn't have a cache equivalent to dovecot.index.cache so it has to do the fetches the slow way. I would have liked to also run the generic tests with more than 1 client, but then I start hitting dbmail bugs and the test stops (reported already to their bugtracker). -- -- Troy Benjegerdes'da hozer'[EMAIL PROTECTED] Somone asked me why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life. -- Charles Shultz
Re: [Dovecot] Thinking Outside the Box - Extending IMAP
Hi Eric, SSH tunnelling requires an SSH login though, right? Even if that's via PAM or other authentication method, it's another set of authentication to set up, why not keep it all in the same system (i.e. Dovecot?) I wouldn't allow SSH access connections to a public-facing server, mainly for the fact I'd have to disclose the details to my user-base, which the majority are non-techies, and it'd be harder to audit logins (there's only my team that login to each server so it's easy to spot if someone's intruding/attempting to.) SSH is for tunneling a connection from the user's client machine to the server which encrypts data over the connection. Why should the average user have to download a piece of software (such as PuTTY), configure an SSH session and tunnel, connect to SSH, then run their usual mail client just to blacklist/whitelist a sender? It'd open up a world of interesting problems for our support guys and is a massive overhead that's unnecessary. Why would a user logged into their mailbox want to make changes to another user's mailbox? More importantly, why would I, as the administrator, want to let them? If one user owns more than 1 mailbox, then they just switch over to the other account - like myself, my Thunderbird has both my -lists account and my normal account in the same window. It takes one click to switch accounts. I also disagree with your comment about code security. The fact it requires another system, in whatever fashion, means there's a completely different code-base which could pose even more of a security problem rather than extending an existing code-base which is already well-known (and guaranteed) for it's security anyway? As Timo is offering 1,000 EUR to find a security hole, I very much doubt he'd release an extension that isn't secure. The way it's been suggested, Dovecot would run an external program to set/get the metadata anyway. The comment about another set of authentication was, if you've already established an IMAP connection, why not use it for something else? If you take it as you said with SSH authentication, the user has to have authenticated via SSH first (to open the tunnel), then authenticates via IMAP. Sure if your IMAP component recognises an SSH tunnelled connection, and doesn't require authentication for it (not sure if Dovecot can be set up like this), then that closes the door for using your mail account on a different machine without having to set up the SSH tunnel as well. Using the suggested metadata extension, any IMAP-capable client could be configured to use it with no dependencies on anything else. The original question was suggesting that Dovecot could extend the IMAP protocol to do other things (SMTP was an example, as was black- and white-listing.) Andy. Eric Rostetter wrote: Quoting [EMAIL PROTECTED]: I disagree about SSH. Good for you. Firstly, how do virtual users fit into your proposed setup? You can setup a ssh tunnel on the server on any port. The user then sets up to connect to that port. The authentication can be done anyway you want, or not at all. We're not talking ssh logins to the server, we're talking ssh tunneling. Secondly, as a service provider to the general public, the absolute LAST thing I want to be doing is opening up SSH access to my servers. Why? An SSH tunnel can be useful, and can increase rather than decrease your security. Now, if you meant logins, that would be a different story. Mark has a valid point in that you have to connect to the server via IMAP to get your mail, why should you have to have a second protocol to do other things with the same mailbox? Because some of these things may not involve the same mailbox? And because it makes for several smaller code bases which are then easier to secure, audit, debug, etc. (instead of one massive code base that is harder to secure, audit, debug, etc). And because then the authors only need to know and understand one protocol, instead of trying to know and understand any number of protocols that they may not use, have any interest in, etc. And so that those who only want 1 protocol can install only that protocol, and not have to worry about all the others? And, well, you should get the idea by now. And why worry about a whole second set of authentication when you've got a pre-authenticated connection ready and waiting? That was what the SSH connection was about I think. I agree it's not portable, and not ideal (ie. look at M$ Exchange's handling of custom server features), but Timo's suggestion of using the METADATA extension may strike the ideal balance between an extensible feature and the IMAP standard. Yes, but it only would handle some situations (maybe whitelist/blacklist) and not others (like SMTP) so it isn't what the original question was about really. Andy.
Re: [Dovecot] dbmail benchmarking
Timo Sirainen wrote: I thought I'd try benchmarking with dbmail (v2.2.4) to see how much slower a SQL backend could actually be. Skip to bottom for the conclusions. Originally I ran the tests with the databases being in XFS filesystem. MySQL's performance was horrible. It went 3-7x faster with ext3. Timo, what was the hardware you used for this test? - In raw append speed dbmail is almost as fast as maildir. - In raw read/write speed maildir is about 1,6 times faster - When adding metadata fetches Dovecot is 4 times faster than dbmail. This is most likely because dbmail doesn't have a cache equivalent to dovecot.index.cache so it has to do the fetches the slow way. I would have liked to also run the generic tests with more than 1 client, but then I start hitting dbmail bugs and the test stops (reported already to their bugtracker).
Re: [Dovecot] Thinking Outside the Box - Extending IMAP
Quoting Andy Shellam [EMAIL PROTECTED]: Hi Eric, SSH tunnelling requires an SSH login though, right? No. SSH tunneling connects to a service, and that service can require authentication if it so desires. SSH tunneling is just port forwarding via SSH. It can be used to tunnel (and hence encrypt) pop3, imap, smtp, popassd, telnet, ftp, etc. The client/server applications using an SSH tunnel will carry out their own authentication procedures (if any) the same way they would without the encrypted tunnel. Even if that's via PAM or other authentication method, it's another set of authentication to set up No, it uses the existing authentication already in the service, if any, and no additional authentication is needed. why not keep it all in the same system (i.e. Dovecot?) I I never moved it out. I only moved the encryption and some session managment out. wouldn't allow SSH access connections to a public-facing server, mainly for the fact I'd have to disclose the details to my user-base, which If you are already running IMAP, then you are already exposing this. Tunneling the IMAP via SSH exposes nothing more than the IMAP exposes, except that you are using an SSH tunnel (meaning if they can find an SSH vulnerability, then can crack you). the majority are non-techies, and it'd be harder to audit logins (there's only my team that login to each server so it's easy to spot if someone's intruding/attempting to.) No. It may be harder to diagnose problems, but not harder to audit logins. The logins are no different than before, only the transport is. SSH is for tunneling a connection from the user's client machine to the server which encrypts data over the connection. Why should the average user have to download a piece of software (such as PuTTY), configure an SSH session and tunnel, connect to SSH, then run their usual mail client just to blacklist/whitelist a sender? It'd open up a world of interesting problems for our support guys and is a massive overhead that's unnecessary. Yes, that would be fairly rediculous. You'd have to have support in your mail client or OS to make it worth doing. Why would a user logged into their mailbox want to make changes to another user's mailbox? Hopefully they wouldn't be allowed to. But one user might own multiple mailboxes, and want to manipulate them all. Plus there could be shared mailboxes, etc. More importantly, why would I, as the administrator, want to let them? If one user owns more than 1 mailbox, then they just switch over to the other account - like myself, my Thunderbird has both my -lists account and my normal account in the same window. It takes one click to switch accounts. Not sure why you bring this up actually. But there are of course obscure reasons (want to blacklist across all accounts, and not do it manually for each one, etc). I also disagree with your comment about code security. The fact it requires another system, in whatever fashion, means there's a completely different code-base which could pose even more of a security problem rather than extending an existing code-base which is already well-known (and guaranteed) for it's security anyway? As Timo is offering 1,000 EUR to find a security hole, I very much doubt he'd release an extension that isn't secure. The way it's been suggested, Dovecot would run an external program to set/get the metadata anyway. Yes, and so, the external program would be another code base not controlled by Timo, so... Well, you do the math. There are various theories about small vs large code bases. But if you look at security statistics, you will see small code bases almost always win over big code bases, if all other things are held equal. Of course, people can debate that until the cows come home, can you can't really prove it one way or the other, and there are always exceptions. The comment about another set of authentication was, if you've already established an IMAP connection, why not use it for something else? That was the whole point of the SSH connection. If you take it as you said with SSH authentication, the user has to have authenticated via SSH first (to open the tunnel), then First, it was not my idea to use SSH. I was simply trying to correct your assumption that SSH tunnels would require an authentication. Second, they don't have to authenticate via SSH first, so your assumption is wrong. the SSH tunnel as well. Using the suggested metadata extension, any IMAP-capable client could be configured to use it with no dependencies on anything else. As I pointed out, that only addresses issues like black/whitelist, not issues like SMTP via IMAP. The original question was suggesting that Dovecot could extend the IMAP protocol to do other things (SMTP was an example, as was black- and white-listing.) Yes, and no solution provided so far has addressed both of those in any real way. The SSH one at least has potential to do so, whereas I see no
Re: [Dovecot] dbmail benchmarking
On Mon, 2007-05-14 at 14:03 -0400, Justin McAleer wrote: Timo Sirainen wrote: I thought I'd try benchmarking with dbmail (v2.2.4) to see how much slower a SQL backend could actually be. Skip to bottom for the conclusions. Originally I ran the tests with the databases being in XFS filesystem. MySQL's performance was horrible. It went 3-7x faster with ext3. Timo, what was the hardware you used for this test? Intel Core 2 6600, 2GB 800MHz memory, Asus P5B, 300GB PATA Seagate disk with XFS filesystem, ext3 created as a 1GB file inside XFS (once I get another disk I'll move to ext3 completely). signature.asc Description: This is a digitally signed message part
[Dovecot] Refreshing Dovecot
If I've made configuration changes, is there a way to refresh...without killing and restartingDovecot? -- Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 [EMAIL PROTECTED] voice: 845-758-7475, fax: 845-758-7035
[Dovecot] Question: contention with blackberry
My production imap is currently UWIMAP with mbox.. One of the problems commonly observed is mailbox lock loss, which happens when: a) a VIP has multiple secretaries accessing a single mailbox (actually, they are professional enough to have figured the realities of conflicting access and rarely have a problem), b) somebody leaving their machine on at home and coming in and firing up their work computer c) important people with Blackberriesand the BB service polls the mailbox every so often and breaks the lock. In any case, the maillog ends up with a message like this: May 5 19:45:04 mercury mail:info imapd[2035774]: Logout user=x host=bda056.bis.na.blackberry.com [216.9.249.56] May 5 19:46:52 mercury mail:info imapd[2502902]: Killed (lost mailbox lock) user=x host=cpe-24-161-103-11.hvc.res.rr.com [24.161.103.11] How will this work with Dovecot? I regard what is happening now as OK, working as designed. Although we may eventually move to a different mailbox format, I am only switching from UW to DC in the first step. -- Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 [EMAIL PROTECTED] voice: 845-758-7475, fax: 845-758-7035
Re: [Dovecot] Question: contention with blackberry
Stewart Dean wrote: a) a VIP has multiple secretaries accessing a single mailbox (actually, they are professional enough to have figured the realities of conflicting access and rarely have a problem), b) somebody leaving their machine on at home and coming in and firing up their work computer c) important people with Blackberriesand the BB service polls the mailbox every so often and breaks the lock. In any case, the maillog Honestly, moving to Maildir will solve all your problems with (a) and (b), and most likely (c) as well. Especially with (a), you would be doing your VIP's people a huge favor by converting to Maildir during your IMAP daemon move... $0.02. -te -- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
[Dovecot] Processing too fast?
I'm trying to use Dovecot to make administering ASSP a bit easier. I've created a mailbox with a number of subfolders (Spam, Ham, etc.) and have ASSP setup to save mail in the appropriate folder e.g. /var/mail/ASSP/.INBOX.Ham/new. But I'm having problems with ASSP complaining about the newly created files - I believe the file gets opened, then it disappears before ASSP finishes writing to it. Is Dovecot grabbing the file from new and moving it to cur faster than ASSP can write? How can I get around this? ASSP only allows for a folder to save each category to - I can't specify an LDA. -- Daniel
Re: [Dovecot] global vs user script
On Tue, May 08, 2007 at 08:45:31AM +0200, Steffen Kaiser wrote: On Tue, 8 May 2007, M1 wrote: I glanced over the current Sieve library (CMU): 1) 3 global scripts, 1 execute before user script, 1 execute after user script, 1 execute only if there is no user script. I didn't found an easy way to let the parser read in more than one script in a row. There is a function that translates just one file into the bytecode. It is not iterative. 2) Call global script from user script or call user script from global script. Maybe, one could expand Sieve to have some sort of include statement. It could work. However, there are at least two other Sieve implementations, too, there had been some suggestions to look into them, but nobody jump into til now. Speaking as the author of one of them, maybe, depending on whether mine was one of the two you refer to, I can say how my implementation handles it. This is only quasi-on-topic, hit 'd' if you don't care; I hesitated quite a while before responding since I've rambled on about it here before, but in the end wasn't able to resist, as you can see. mvmda, which is the beast I refer to, is intended to be both system-admin-friendly and expert-user-friendly. Having both those things at once is hard to arrange. One of the ways it tries to do this is to defer a lot of its control flow and logic to a site-wide script, which the system administrator must install and tweak (well, you can get by without one, but that would be another tangent). This would be the global script. The global script executes in an admin mode in which all permissions are enabled, meaning that the global script can pretty much do what it wants. A typical script (typical because I'm using one like this and because one like it comes with the distribution) would do something like: - define namespaces and mailstore locations, probably tailored to the specific user being delivered to; - interpret any command line arguments as if they were script file names, and attempt to run them (e.g. from the user's homedir or base dir), each in turn, with admin mode turned off; - if no scripts are found, attempt to run one with a standard name (e.g. filter.mfl or filter.sieve -- so no script need be named on the command line); - if still no scripts have been found, attempt to run a system-wide one (the name could be derived from the username or the user's group name or any other variable information, to provide for classes of global scripts). Since control always returns to the site-wide script, there can also be common post-user-script actions taken. The scripting language is an mixture of Sieve and C-like constructs. User-level scripts need not use anything other than Sieve, but the system-wide script pretty much has to use non-Sieve elements (and advanced script writers can as well). http://www.mvmf.org/ I'm actively using it in dovecot environments as well as in UW environments, and in qmail as well as sendmail environments- it adapts well. One downside is indeed the requirement for a system-wide script and potentially other system-wide stuff, as that presents a steeper install/learning curve than you might expect from a delivery agent. On the upside, you can get a lot of consistency at the user script level, and you also get a nice qmail-smtpd replacement :) mm
Re: [Dovecot] Semi-static userdb...?
On 11/05/2007 15:57, Timo Sirainen wrote:
On Fri, 2007-04-20 at 14:00 +0100, John Robinson wrote:
I'm trying to add virtual mailboxes to a system. Real users with
different uids own domains. Each domain has a passwd-file passdb. I
don't want to use this passwd-file for the userdb, because I want to fix
the home, mail and uid/gid settings. Can I use the static userdb in a
less static manner, e.g.
userdb static {
args = uid=%{owner of /vmail/%d} gid=%{gid of /vmail/%d}
home=/vmail/%d/users/%u
mail=mbox:/vmail/%d/users/%u/mail:INBOX=/vmail/%d/users/%u/INBOX
}
Hmm. You could always use a checkpassword script which does everything,
but the above does look like it could be useful. I'm just not sure what
would be the best way to implement it so that it would be useful for
other kinds of configurations too..
One possibility would be to set uid_file=/vmail/%d gid_file=/vmail/%d.
I guess that would be good. Added to TODO, but I'm not sure when I get
around to implementing it.
Something like the attached? It applies cleanly to 1.0.0, I've tested it
lightly and it appears to work. My testing was to use passdb pam with
userdb static { args = uid_file=/home/%u gid_file=/home/%u home=/home/%u
}. It's perhaps not perfect: it doesn't complain if you set both uid and
uid_file, ditto gid and gid_file, and it doesn't do any sanity checks on
the result of the expansion[1].
Cheers,
John.
[1] Use uid_file=/vmail/%d and login with domain ../etc/passwd and you
end up looking at /etc/passwd. I don't know whether this matters: it's
only doing a stat(), hopefully dovecot won't let you check mail as root,
and anyway presumably the user has already had their password checked by
now, and someone logging in as [EMAIL PROTECTED]/etc/passwd or whatever would have
failed a password check.
diff -urN --exclude='*~' dovecot-1.0.0.orig/src/auth/userdb-static.c
dovecot-1.0.0-semistatic/src/auth/userdb-static.c
--- dovecot-1.0.0.orig/src/auth/userdb-static.c 2007-03-21 20:01:56.0
+
+++ dovecot-1.0.0-semistatic/src/auth/userdb-static.c 2007-05-15
02:46:32.0 +0100
@@ -10,6 +10,8 @@
#include userdb.h
#include stdlib.h
+#include unistd.h
+#include sys/stat.h
struct static_context {
userdb_callback_t *callback, *old_callback;
@@ -33,8 +35,10 @@
const struct var_expand_table *table;
struct auth_stream_reply *reply;
string_t *str;
- const char *const *args, *value;
+ const char *const *args, *key, *value;
unsigned int i, count;
+ bool ok = TRUE;
+ struct stat fileinfo;
t_push();
str = t_str_new(256);
@@ -46,17 +50,39 @@
args = array_get(module-template, count);
i_assert((count % 2) == 0);
for (i = 0; i count; i += 2) {
+ key = args[i];
if (args[i+1] == NULL)
value = NULL;
else {
str_truncate(str, 0);
var_expand(str, args[i+1], table);
value = str_c(str);
+ if (strcasecmp(key, uid_file) == 0) {
+ if (stat(value, fileinfo) != 0) {
+ ok = FALSE;
+ auth_request_log_info(auth_request,
static-userdb,
+ Can't stat uid_file %s:
%s,
+ value, strerror(errno));
+ } else {
+ key = uid;
+ value = dec2str(fileinfo.st_uid);
+ }
+ } else if (strcasecmp(key, gid_file) == 0) {
+ if (stat(value, fileinfo) != 0) {
+ ok = FALSE;
+ auth_request_log_info(auth_request,
static-userdb,
+ Can't stat gid_file %s:
%s,
+ value, strerror(errno));
+ } else {
+ key = gid;
+ value = dec2str(fileinfo.st_gid);
+ }
+ }
}
- auth_stream_reply_add(reply, args[i], value);
+ auth_stream_reply_add(reply, key, value);
}
- callback(USERDB_RESULT_OK, reply, auth_request);
+ callback((ok ? USERDB_RESULT_OK : USERDB_RESULT_INTERNAL_FAILURE),
reply, auth_request);
t_pop();
}
@@ -131,11 +157,14 @@
const char *const *tmp, *key, *value;
uid_t uid;
gid_t gid;
+ bool uid_file;
+ bool gid_file;
module = p_new(auth_userdb-auth-pool, struct static_userdb_module, 1);
uid = (uid_t)-1;
gid = (gid_t)-1;
+ uid_file = gid_file = FALSE;
tmp = t_strsplit_spaces(args, );
