Re: [Dovecot] deleting maildir files
Timo Sirainen wrote: Yea. Or I mean in both cases you can just delete the files inside the directory, but I'm pretty sure rm tmp/* will give you an error. :) This: $ ls -f ./tmp ./cur | xargs rm is really quite efficient, and doesn't fall prey to commandline globbing limits... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] deleting maildir files
Charles Marcus wrote: Hmmm... but will that take care of /tmp as well? Don't forget, this is a different system that is still served by courier - but happily I've been given a gree light to start planning their migration to dovecot... Don't forget that files exist in tmp only while they are being written to disk (and then they are mv'd directly to new). It is _never_ a problem to delete everything under cur. You don't even need to blow away the directory itself, just the files contained within ./cur... If you want to be really paranoid, just make sure that the client is not accessing the mailbox at the time. And when I click on the Trash folder in Thunderbird, it just goes into never-never land... Just upgrading to Dovecot might fix that; also make sure you are using the latest TBird 2.x release (there were some known timeout issues fixed after the 1.5.x series). John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] target doesn't allow inferior mailboxes
Adam Williams wrote:
Makes sense. Any solutions other then using a different MUA?
At least in Thunderbird (and presumably Seamonkey), you can configure
the mail client to:
1) delete mail immediately (instead of moving to trash);
2) not use subfolders.
#1 is on the Server Settings tab ("When I delete a message..."). #2 is
on the Advanced settings from that same page ("Server supports folders
that contain folders...").
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
Re: [Dovecot] Index question
David Favor wrote: I'm faced with a similar situation. I use an custom event looped MTA written in perl. By the time a message is ready to be delivered, it's temp file usually already resides on the physical disk where it will reside. That's not qpsmtpd is it??? ;-) What would be great is a stand alone program which could be run given a directory list to reindex. You could write one yourself; all it would take is some out of band program that connects via IMAP and requests the minimal IMAP command that would cause a reindex (Timo?). Presumably you have access to the username/password combination (since you are able to hardlink files into their mail directory). John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] [Fwd: Bounce action notification]
Antti-Juhani Kaijanaho wrote: Actually, it does include the bounce with headers. The bounce seems to have originated from 81.3.115.182, which reverse-resolves to canville-182.adsl.newnet.co.uk. Duh, of course you are right! I glanced at that block and thought that was the dovecot.org server itself generating the bounce. I concur that the above listed server is the cause of the bounce message; I've seen this before with badly written homemade spam filters... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] [Fwd: Bounce action notification]
Timo Sirainen wrote: Unable to deliver message to the following address(es) dovecot@dovecot.org Remote host said: 554 delivery error: This user doesn't have an account That isn't a terribly helpful error message, since it doesn't include the original e-mail message, with headers, so that you could see what Mailman thought the original Mail-From: address was (which is what is failing here)... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] APOP and CRAM-MD5 in checkpassword module
Ben Schumacher wrote: I would like to see this, too. After digging through the code some, it seems that the major sticking point is that dovecot would prefer to do the CRAM-MD5 internally and therefore expects to have access to the password in plaintext and doesn't pass the timestamp on to checkpassword... There is no way to use CRAM-MD5 without having the password stored in plaintext locally; it is a design "feature" since the hash is calculated using a different server key every time. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] ?? Error: child 1064 (imap) killed with signal 4
Benton Haynes wrote: I'm still not clear how one gets gdb to exec 'imap' WITH the config file. The usual method is 'man gdb' and read the documentation. ;-) I'll save you the effort and extract the appropriate section: run [arglist] Start your program (with arglist, if specified). meaning you start gdb $ gdb /usr/local/sbin/dovecot $ run -c /path/to/your/dovecot.conf HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] Dovecot LDA munging INBOX access times?
Steven F Siirila wrote: > We are running Dovecot 1.0.0 using mbox format (currently in the midst > of conversion from UW IMAP). We discovered today that the Dovecot LDA > is accessing the user's INBOX at delivery time! Umm, yeah, that's kind of the point. mbox format is one big file with all of the messages concatenated together. So if a new message is delivered, then the INBOX file has to be opened to append the new message. This isn't a bug by any stretch, but rather a different operational method than what you were expecting. I'm guessing that UW IMAP doesn't retrieve new messages until the user asks for them (e.g. out of /var/mail/something). If you are using deliver, it actually, you know, _delivers_ the message. I think that there is a way to have the same behavior as UW IMAP, but I don't know off the top of my head how to do that (since we use maildir instead). You may want to check the list archives first, rather than claiming dovecot is doing something wrong... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Dovecot] Return error instead of dying on time back skip?
Ben Winslow wrote: Clock drift of about 13 seconds/day (150 PPM) is (unfortunately) not uncommon, and 4-6 seconds/day (50-75 PPM) is about the norm for PC hardware in my experience. Of course, this is exactly the reason why you should run ntpd instead of ntpdate on a cron job (especially a once-per-day cron job...) I would again recommend clockspeed: http://cr.yp.to/clockspeed.html http://foo42.de/devel/sysutils/clockspeed-conf/ for machines which don't have continuous connection to the Internet (where [x]ntpd won't do you any good). It handily reigns in bad clock crystals with only a couple of external connections per month. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] Return error instead of dying on time back skip?
Amon Ott wrote: All our systems run ntpd, but they might be offline for a while before they get contact to a time server, e.g. because of DSL problems. When they do get contact and time is too far off, ntpd sets the new time directly (yes, it could gradually do that, but it might take ages). You might want to consider using clockspeed: http://cr.yp.to/clockspeed.html instad of ntpd, since clockspeed handles the underlying clock skew in a more robust fashion. This software needs only a couple of connections to figure out how bad the underlying hardware clock skews and automatically adjusts it in a smooth fashion. If you haven't used Dan Bernstein's software before, you will probably want to use clockspeed-conf: http://foo42.de/devel/sysutils/clockspeed-conf/ to manage the daemons. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] dovecot for imap
[EMAIL PROTECTED] wrote: They are for a fact invisible. I tried to subscribe to them. They dont show up. Then indeed you have the wrong mail_location directive in the configuration file. You should follow all of the steps listed here: http://wiki.dovecot.org/TestInstallation starting with step 5. Unless someone on the list has *exactly* the same setup as you do, I would perform those tests yourself, since anyone random user's suggestion for mail_location should be considered a WAG (wild a$$ed guess). However, new folders can be created. Looks like dovecot created a folder in /home/user named mail, and Maildir. mail has userfolders in it and Maildir has their inbox. Does this sound right? Currently my users inbox is /var/mail/spool/mail. For one thing, if your existing "user created folders" exist in the top level /home/username folder, then this is certainly wrong: mail_location = mbox:~/mail:INBOX=/var/mail/%u since that would store the user folders inside a directory called "mail" in their home directory (which is what you found, right?). One last suggestion, make sure that you restart dovecot completely after making changes to the config file; it sounds like at somepoint you had something else in mail_location, which is why you have a Maildir. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] dovecot for imap
[EMAIL PROTECTED] wrote: Users have inbox, trash and sent folder, but none of the other folders that they have created in /home/Username. Are the folders /invisible/ or not /subscribed/? Have one of the users go into the Horde folder subscribe page and see if their personal folders are displayed there. With other clients, e.g. Thunderbird, it is necessary to force the client to resubscribe to the folders when changing things. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc29 released
Geert Hendrickx wrote: What annoys me more (as dovecot maintainer for pkgsrc) is that the example config file changes with (almost) every release. The changes are mostly just in comments, but it makes users have to merge their configuration on every update. What part of "Release Candidate" isn't clear here... ;-) Seriously, until 1.0-final comes out, everything is up for grabs; though one would hope that the number of changes per RC is going to approach zero at some point... ;-) John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] can't receive mail from other hosts
Steve Strong wrote: > the logs show that postfix does not get the email to process. This isn't a dovecot issue then. You need to take this up with the postfix people, but before you do, make sure that your Postfix instance is actually listening to a public IP address: inet_interfaces = your.public.ip.address, 127.0.0.1 ::1 Under a default installation, only the 127.0.0.1 is enabled. HTH John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Dovecot] Version numbering
Frank Cusack wrote: On March 28, 2007 4:35:50 PM -0400 John Peacock <[EMAIL PROTECTED]> wrote: What this model does is to make many more small releases (no more RC129), each with a stable feature set. I don't see how that's different than a/b/rc numbering. You can still cut as many releases as you like. 1.1.0 1.2.0b1 1.2.0b2 1.2.0rc1 1.1.1 1.2.0rc2 1.2.0rc3 1.2.0 I can handle that too: version::AlphaBeta ;-) http://search.cpan.org/~jpeacock/version-AlphaBeta-0.06/lib/version/AlphaBeta.pm But the argument that numeric only works much better for packagers is very powerful, IMNSHO... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] Version numbering
Frank Cusack wrote: Right, so my point is, you have the same problem and can't tell which 1.3.x is newer than a 1.2.x (on a feature-by-feature or bugfix-by-bugfix basis). I guess it might not matter. But it's nice to say "use 1.2.5+" for such-and-such feature and not have to worry that 1.3.0 doesn't actually include that feature. No one should be "using" 1.3.x, since that is a dev release. To emphasize what I said earlier, no new features exist in 1.2.5 that weren't already in 1.2.0. 1.2.x is only for bugfixes, not features. Features go into 1.3.x and when that branch is stable, 1.4.0 is cut and you start all over again at 1.5.0 for developing new features. What this model does is to make many more small releases (no more RC129), each with a stable feature set. The highest even numbered release is always the "best choice" and there is never any feature in an even numbered release that wasn't developed in the preceding odd-numbered dev branch. For reference purposes, see how Apache project handles versions: http://apr.apache.org/versioning.html Although this doesn't hew to the even/odd model, it is still about as air-tight a scheme as is possible with OSS. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] Version numbering
Frank Cusack wrote: You misunderstood that. After the release of 1.2.0, 1.1.x is frozen and development starts again in 1.3.0. And then how do you release 1.2.1? This is a well understood process (even/odd development). Once 1.2.0 is released, all new development moves to 1.3.x. 1.2.1 is a bugfix only (typically implemented first in the 1.3.x branch and then backported). No development or bugfixes are made to the previous dev branch (1.1.x in this case). The choice to move from 1.x.x to 2.x.x is a completely independent determination, and is normally made based on whether the last dev release (odd) has a significant codebase from the latest stable (even) release. It is not unheard of to make _important_ security fixes to the prior stable release (if possible) even after a newer generation stable (1.4.x) release is available, depending on how widely distributed the prior stable release was to distros that don't keep up (*cough*Redhat*cough*). John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] Deliverm, vpopmail, and valias
John Peacock wrote: I have already accepted a message for an aliased address, but the MTA isn't going to be rewriting the envelope address, so how can I get dovecot's deliver to dereference the alias and deliver to the correct Inbox? Just to follow up on my own posting: it turns out that it is just as easy to rewrite the envelope address in Postfix either before or after dspam processing, so that's what I'll do. It actually simplifies the dspam handling to rewrite before procssing (since I already had to figure out the alias for training purposes). John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
[Dovecot] Deliverm, vpopmail, and valias
I'm in the final stages of testing my e-mail server to come and I seem to have hit a roadblock. One option of current vpopmail is to store all aliases in a valias table, that looks like this: +-+--+--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +-+--+--+-+-+---+ | alias | char(32) | NO | MUL | | | | domain | char(64) | NO | | | | | valias_line | text | NO | | | | +-+--+--+-+-+---+ where valias_line could be either an e-mail address (preceded by an ampersand) or a command (piped to vacation for example). I have already accepted a message for an aliased address, but the MTA isn't going to be rewriting the envelope address, so how can I get dovecot's deliver to dereference the alias and deliver to the correct Inbox? Because of the number of other hops[1] that the message is going through, I don't want to rewrite the destination address unless I really have to, but if that is the only option, that is what I'll have to do. Thoughts? John 1) inbound e-mail hits a qpsmtpd instance which validates e-mails using several different filtering techniques. Next the mail gets fed to a dspam appliance running two Postfix queues (one before dspam and one after). Mail that isn't quarantine by dspam gets sent to the delivery server (currently running qmail) and delivered to the final destination (modulo sieve rules under deliver). The only place I could conceivably rewrite the address would be the second Postfix queue. -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] Version numbering
Aredridel wrote: >> b) Odd-even numbering: 1.1.x (unstable) -> 1.2.0 (stable) >> >> With a) style the releases could be done by simply copying a nightly >> snapshot to releases/ directory and announcing the changes since the >> last release. I'm not sure if that's good or bad. > > For the sake of packagers, stick with numbers, always incrementing. > Makes our lives a ton easier. As the resident Perl version[1] expert, I concur that numbers and only numbers are the way to go... John 1) http://search.cpan.org/~jpeacock/version-0.71/lib/version.pod -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Dovecot] MANAGESIEVE patch v3 for dovecot 1.0.rc28
Stephan Bosch wrote: Hello dovecot users, I have updated the MANAGESIEVE patch to apply and compile against dovecot 1.0.rc28. Not much has changed with respect to the functionality of the previous version however: One thing that would be very important is some way to pretend that this server implements the timsieved daemon. All software that I've tried is hardcoded to assume something like this regex: "Cyrus timsieved (v1\.\d|v2\.\d)" Perhaps, instead of just plopping PACKAGE into that IMPLEMENTATION string, it would be better to add a configure option to set that string to something else than "dovecot" (which no software currently supports). FWIW, I've just fired up smartsieve: http://smartsieve.sourceforge.net/ and it works like a charm for editing scripts. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] MANAGESIEVE patch v3 for dovecot 1.0.rc28
Koen Vermeer wrote: Op ma, 26-03-2007 te 18:34 +0200, schreef Stephan Bosch: - Updated source to compile with dovecot 1.0.rc28, tested with rc27 (debian package) I downloaded the rc28 Debian source package, ran dpkg-source -x dovecot-1.0.rc28-1.dsc, applied the patch and ran dpkg-buildpackage -uc -us -rfakeroot, which resulted in the error: You should probably give up trying to use the debian package method if you are applying third-party patches like this. In particular, you will need to run autogen.sh, which isn't in the source tarballs, but is only available with you check out the CVS files (you will also need to have ylwrap, which can be found in the top level of the dovecot-sieve distro). John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc28 / v1.0 plans
Timo Sirainen wrote: > I don't understand why you think it's not able to parse the message. > What do you think it should be parsing from it? Doesn't it look for the headers and pull the Delivered-To: in order to determine where the message should be, you know, delivered to? I thought that was the whole point of adding the preline to the pipe. If I misunderstood the nature of the software, I'm sorry. Reading between the lines, it appears that deliver merely drops the mail into the executing user's mail folder (which in hindsight seems obvious) unless -d is passed to change that. Never mind... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: [Dovecot] 1.0.rc28 / v1.0 plans
Timo Sirainen wrote: That describes a way to make deliver work with system users. I wasn't sure if Qmail could be set up another way, so I didn't change that. Updated it now. I'm actually using vpopmail for virtual users, so I'm just as happy to force the issue with '-d', but I wanted to make you aware that it isn't apparently able to parse the message. I suppose it went to vpopmail user's INBOX (/var/mail/vpopmail?) Nope, nothing there either. I can do a full scan of the drive, but I suspect it is in the ether... ;-) -d makes it work with virtual users. I'm not sure why it didn't show Message ID in the log line. Did your message have it? Or did preline add an empty line in the middle of the headers for some reason? This is the entire message: = Return-Path: <[EMAIL PROTECTED]> Delivered To: <[EMAIL PROTECTED]> Received: (qmail 10024 invoked from network); 23 Mar 2007 16:30:05 -0400 Received: from unknown (HELO jpeacock.internal) (192.168.0.11) by entilza.rlpgbooks.com with SMTP; 23 Mar 2007 16:30:05 -0400 Date: Fri, 23 Mar 2007 16:27:06 -0400 To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Subject: test Fri, 23 Mar 2007 16:27:06 -0400 X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks This is a test mailing ========= John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc28 / v1.0 plans
Timo Sirainen wrote: * deliver + userdb static: Verify the user's existence from passdb, unless allow_all_users=yes + deliver: Ignore -m "" parameter to make calling it easier. + deliver: Added new -n parameter to disable autocreating mailboxes. It affects both -m parameter and Sieve plugin's fileinto action Is deliver supposed to work out of the box (not talking about sieve yet)? I have been testing it per the instructions here: http://wiki.dovecot.org/LDA/Qmail and with a message that already has the correct Return-Path: and Delivered-To: lines in the header already, the message is *not* delivered (anywhere, AFAICT), even though I get a: deliver(vpopmail): Info: msgid=: saved mail to INBOX message at the commandline. If I do it this way instead: | /usr/local/libexec/dovecot/deliver -d [EMAIL PROTECTED] it works properly (i.e. it is delivered to the correct user). Is the message parsing part of deliver not functioning? John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc28 / v1.0 plans
Timo Sirainen wrote: Many people think using PAM by default is the minimal configuration. :) But to run using PAM, dovecot has an external dependency, i.e. http://wiki.dovecot.org/PasswordDatabase/PAM which you don't provide as part of the tarball, though passwd support does work out of the box. That's is why I don't consider PAM to be "minimal". In any case, I just thought I'd mention it... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
Re: [Dovecot] 1.0.rc28 / v1.0 plans
Timo Sirainen wrote: I'll probably release 1.0.rc28 in a few days. Would be nice to get some testing for it first. http://dovecot.org/nightly/dovecot-latest.tar.gz contains pretty much what it's supposed to be. Downloaded and started testing - - vpopmail support didn't compile in rc27 I can already confirm that this works again in 28-to-be... FWIW, I think that the default dovecot-sample.conf should not have PAM support enabled by default (just comment it out). When I applied by local diffs to the new conf file, I missed out on that and had to immediately edit it out in order to bring up dovecot; not a big deal but the sample configuration should more or less work out of the box for an absolutely minimal configuration (and some limited definition of "work")... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
