similar to: Help needed: Index filesystem permissions problem after switch to V1.2 and back to V1.1

In V1.1.15 that I fell back to. Again: # 1.1.15: /usr/local/etc/dovecot.conf # OS: AIX 3 0001378F4C00 listen: *:143 ssl_listen: *:993 disable_plaintext_auth: no verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login login_processes_count: 12 login_max_processes_count: 774 max_mail_processes: 1024 verbose_proctitle: yes first_valid_uid: 200

I recently upgraded from DC 1.1.15 to 1.2.6. The /var/dcindx index root directory is: drwxrwsrwt 3962 root sys 192512 Nov 13 11:56 ./ thus 3777. It appears that the user index directories created under DC1.1 look like this (here for /var/dcindx/cep): drwx--S--- 5 cep sys 256 Nov 13 14:26 cep/ while those created under V1.2 look like: drwx------ 3

Last Wednesday at 12:21 I made this switch, which seemed to be uneventful. In any case, no user has reported problems since the migration. Not content to leave well enough alone, this morning I scanned the syslog and maillog for dovecot related errors. What I found was that: Before the Migration=========================== I saw a lot of SSL errors that look like this: > Jan 14 11:49:23

Want to have some users with Maildir, some with mbox, as I migrate from mbox format to maildir over the space of a month. After everyone is converted to maildir, I'll change the mail_location in dovecot.conf. During the interim, can I use the Custom mailbox location script (at the bottom of the Mail Location DC Wiki page)? > if [ -d $HOME/.maildir ]; then > export

Don't know if anyone else uses Berkeley derived filesystem quota, but IBM's AIX does. A little over a week after migrating from UWIMAP to DC (with mbox format unchanged) everything is clean except for this one problem: When users go over quota, when they login the next time, the folder list is blank. You can imagine the panicked calls to the Helpdesk. If their quotas are raised or

My production DC machine owns the mail filesystems and is running DC V1.0.15 and mbox folder format. I am looking to test V1.1.3 on another machine, which NFS mounts the mail filesystems, but has its own local index FS. I have made this test environment my default connection in TBird, and it seems to work just fine. Also, I have made sure that my TBird client isn't connecting to the

From reading the wiki for a filesystem quota, I took my shot at 1) building my binaries using the mods in AIXPluginsSupport 2) changing dovecot.conf and 3) putting the plugins in the library But I'm getting this error message when I invoke dovecot: Plugin imap_quota not found from directory /usr/local/lib/dovecot Error: imap dump-capability process returned 89 It would seem that a) I have

I have Dovecot 1.0 in trial use by the IT staff, and have some locking questions Background, the mail server runs procmail, sendmail and NFS exports the user homedir and mailbox to a) a login shell host and b) a mailing list services host. It runs UWIMAP on the usual ports and dovecot on a arbitrary port number. Because of concern with NFS and file access contention. I have the following

Thunderbird (2.0) is all of a sudden checking mail server capabilities and keep posting a popup saying: "Mail Server imap.bard.edu is not an IMAP4 mail server". To the best of my knowledge, neither Tbird nor DC have been updated, though the DC imap host was rebooted today 3 hours ago. Any info on what this is about? DC is currently serving out of a special port and in evaluation

Most likely non-Dovecot, but I'd appreciate any comments on WTF might be going on here. Preparatory to migration from mbox to maildir format on our AIX mail server, I am migrating from the JFS filesystem (being deprecated by IBM) to JFS2 to better handling the jump in the number of files. Two nights ago, I took the first step and migrated the IT homedir filesystem: copied it to a scratch

Because of user access growth, the number of processes associated with IMAP has increased and I thought to change some of the configured parms. dovecot -n yields: # 1.1.14: /usr/local/etc/dovecot.conf # OS: AIX 1 005A928C4C00 listen: *:143 ssl_listen: *:993 disable_plaintext_auth: no verbose_ssl: yes login_dir: /var/run/dovecot/login login_executable: /usr/local/libexec/dovecot/imap-login

As I explained, I want to be able to run a second instance of DC through another port to do testing while not interrupting the users using the primary instance in the the regular port. I was instructed to create a second config file with different listen ports and a separate base_dir. I did so and invoked dc with -c pointing to dovecot2.conf. Jun 7 10:04:23 mercury mail:info dovecot:

Our DC has been using a Verisign certificate. Over the past year, we've been using a Digicert Wildcard Plus certificate for almost all of our machines, and I wanted to switched over our DC mailserver. I used the following command to generate the CSR and key: openssl req -new -newkey rsa:1024 -nodes -out star_bard_edu.csr -keyout star_bard_edu.key -subj "/C=US/ST=NY/L=ourtown/O=Bard

I guess the alert function is not part of the spec, because it appears to be unimplemented in Dovecot, even though most clients implement it. Timo, I would hope this would be easy to implement, and it's functionality that will be valuable to every installation. Here's why. America recently had the tragedy of a shooting rampage on a large university campus (yes, America should do

For the record/archive, so some other unfortunate dovecot implementer won't spend weeks figuring out this particular way dotlocks can have problems... here is what was trashing our dotlocks Basically, I was seeing this: May 14 15:59:58 mercury mail:warn|warning dovecot: IMAP(sdean): Our dotlock file /var/spool/mail/sdean.lock was deleted (kept it 1 secs) > May 14 15:59:58 mercury

1) I see that the --without-pop3d option has gone away. What does this imply, i.e why was that done? Is there some other way that you now avoid compiling the POP code? Are there any other discontinued options? 2) There was some talk a while back about changing how and where the plugins were to be built and their code located. Was this implemented? If so, is there any doc on it? -- ====

<permit me my perhaps foolish preference...an explanation> I run mail service for a small college. I've long joked that if someone stole the mail server, the phone would ring before the alarm (which has a 1 minute delay) did, that the user base expected 25x8x367 coverage. Making updates/upgrades to the mail server feels like a tightrope walk with no net. I always appreciated

I purely love that kind of crap. As if presentations meant anything, as if there aren't all kinds of scholarly work about theoretical perfect world algorithms and conceptual systems that will never be implemented and are as practical and effective as wings on a pig. Please. I'm reminded of the story about how, during the American Civil War, when the North had finally, after years of

The day I switch our user to dovecot and it goes into production, there will be a few thousand people all generating their indices for the first time (we have a legacy requirement for procmail, at least for now), so I wondered: 1) Is there is anyway to pre-emptively force indexing? 2) Is there any value in doing so? That is, will I gain much in terms of making the first time everyone connects

I am using the base AIX Unix authentication with NIS. There is a base /etc/password file (though the passwords are in a funny, IBM-peculiar file, /etc/security/passed) of just 18 lines...since NIS is in use, the last line is the standard for-anything-you-don't-find-here-try NIS indicator: +::0:0::: When I start up DC, I get these error massages: Apr 9 14:44:59 mercury mail:err|error