[Dovecot] Dovecot indexing questions

2008-01-07 Thread Asheesh Laroia
I was playing with Dovecot 1.1 full text indexing through Squat in late 
October, which was working pretty well.  I wanted to ask about this 
behavior I had:


When an email arrives in INBOX using procmail (which delivers to my 
Maildirs), and I see it in Dovecot, when I next do a search (IMAP SEARCH 
TEXT) of that folder, the search takes a long time.  Successive searches 
are lickety-split.


My question is: Can there be an option to "index greedily"?  As soon as 
Dovecot sees the message, I'd like it to update the Squat index.  That 
way, searches are always fast.


I guess this implies a small performance hit - namely, that my IMAP server 
spends CPU and disk time indexing every message at the first time it is 
seen rather than being able to do batch indexing each time SEARCH TEXT is 
issued.  But when I think about that, that sounds like the server 
can waste its time so I don't waste mine - which is exactly why I 
like these computing machines!


(That, and because I can waste my time programming them.)

-- Asheesh.

--
Use extra care when cleaning on stairs.


Re: [Dovecot] Please help me resolve why mail isn't being delivered to virtual users

2008-01-07 Thread Asheesh Laroia

On Mon, 7 Jan 2008, Andrew Falanga wrote:


I have to admit that I'm not quite sure why no one has responded to me about
this one.  If I'm not providing enough information or incorrect information
please tell me.  It's quite important that this e-mail system be working.


Well, I can try to help.  In general that's what we'll all do, but we have 
other things to do in our lives, too. (-:


Zeroth question: Why use virtual users rather than regular-old UNIX users? 
The regular way requires much less configuration, after all!



I have created a system user ID called "vmail" which is referenced in my
PostgreSQL database for UID/GID stuff.  All virtual user home directories and
INBOXes are made owner "vmail" and group is "users."


First question:

If you do 'su - vmail -s /bin/sh' you will get a shell running as user 
vmail.  Run 'deliver' with the arguments it takes to deliver to a target 
user; does mail get delivered?


If not, we better fix that first!

Originally, I had my sendmail "/etc/mail/aliases" file setup to "map" 
all mail sent to these virtual users to the system user "vmail." 
However, none of the virtual users were getting any mail and vmail was 
just getting swamped. After doing more digging, I found that I just 
didn't understand the home directories and INBOX, mbox and such. 
That's what drove me to configuring what's in there now.


Now, following directions on this WIKI page: 
http://wiki.dovecot.org/LDA/Sendmail?highlight=%28deliver%29 I'm still 
unable to get the e-mail working for them.  Continually, sendmail bails 
with errors saying it, "Can't create output."  Because I am using *.mc 
files, I made a new *.m4 file as directed in 
/usr/share/sendmail/cf/mailer.


Can you turn up the verbosity from sendmail?

Dovecot does allow the virtual users to login.  In fact, when I did, the 
first time, there appears a "mail" directory in their home directories 
after login. This would indicate to me that the login was successful. 
Further, I cut/pasted a message sent to one of the virtual users from 
the vmail INBOX (/var/mail/vmail) into the virtual user's INBOX 
(/var/mail/jdunkin).  Then, logged in as this virtual user and ACTUALLY 
got the mail.  I know this stuff works.  What must be done to make 
sendmail do its thing for deliver?


So it sounds like Dovecot is fine and this is a sendmail question.

We can try to help, but I don't use Sendmail (I do use Dovecot...), so 
it's not clear that we'll be able to.



What is necessary to fix this situation?


Reply with answers to 0 and 1 and we'll see where we can go.

-- Asheesh.

--
People are going to scream bloody murder about that.
-- Seen on linux-kernel


Re: [Dovecot] Problem with passwords surrounded by curly braces

2008-01-07 Thread Benjamin R. Haskell

On Mon, 7 Jan 2008, Frank Kintrup wrote:


Hello,

one of my users set his password to something surrounded by curly braces,
and promptly all access to his mailbox was refused. After looking through
the logs I found an entry "Unknown password scheme ", where ""
is the user's password, but without the curly braces.
I then browsed through the documentation and there was explained that it
is possible to prefix the password with the password scheme in curly
braces, like "{PLAIN}" where  is the password itself.

Manually altering the users password in the database to "{PLAIN}"
(where "" is the user's password WITH curly braces) fixed this problem
for me at this time, but the time a user chooses such a strange password
I would have to edit the table again. So in my opinion the {SCHEME}-prefix
is not a useful thing. Why would anyone need it, anyway? Shouldn't all
passwords have the same scheme which is set in the dovecot.conf file once?

If the feature is indeed used: with a database lookup it should be
replaced by an optional database field or, if that's not possible, it
should be possible to disable this feature from the config file.


Frank



Regardless of how secure your password file/database might be, it seems 
like a bad idea to enter users' passwords in plain text. Use something 
else. With the other schemes it's at least a huge annoyance for an 
attacker to recover a password. But, you can still easily set the 
passwords to known values as an administrator. (That's the whole point of 
a one-way hash like 'crypt' or 'MD5'.)


Best,
Ben


Re: [Dovecot] What's the difference between mbox and maildir

2008-01-07 Thread Andrew Falanga
On Tuesday 01 January 2008 02:16:47 Gunter Ohrner wrote:
> Am Dienstag, 1. Januar 2008 schrieb Andrew Falanga:
> > .imap/.imap/   (other than directories)
>


On this WIKI page: http://wiki.dovecot.org/VirtualUsers


[Dovecot] Please help me resolve why mail isn't being delivered to virtual users

2008-01-07 Thread Andrew Falanga
follow up:

I forgot to mention, that I discovered my system doesn't appear to have 
procmail on it.  So, I'm not sure what must be done for delivery of mail 
concerning that "LDA/Sendmail" dovecot WIKI page.

Andy


[Dovecot] Please help me resolve why mail isn't being delivered to virtual users

2008-01-07 Thread Andrew Falanga
Hi,

I have to admit that I'm not quite sure why no one has responded to me about 
this one.  If I'm not providing enough information or incorrect information 
please tell me.  It's quite important that this e-mail system be working.

I do not quite understand what it is that I'm missing now.  I have the need to 
setup and configure various users as virtual users.  To this end, I've 
configured them so that their home directories are "/virtusers/" and 
their INBOXes are "/var/mail/."

I have created a system user ID called "vmail" which is referenced in my 
PostgreSQL database for UID/GID stuff.  All virtual user home directories and 
INBOXes are made owner "vmail" and group is "users."

Originally, I had my sendmail "/etc/mail/aliases" file setup to "map" all mail 
sent to these virtual users to the system user "vmail."  However, none of the 
virtual users were getting any mail and vmail was just getting swamped.  
After doing more digging, I found that I just didn't understand the home 
directories and INBOX, mbox and such.  That's what drove me to configuring 
what's in there now.

Now, following directions on this WIKI page: 
http://wiki.dovecot.org/LDA/Sendmail?highlight=%28deliver%29 I'm still unable 
to get the e-mail working for them.  Continually, sendmail bails with errors 
saying it, "Can't create output."  Because I am using *.mc files, I made a 
new *.m4 file as directed in /usr/share/sendmail/cf/mailer.

Dovecot does allow the virtual users to login.  In fact, when I did, the first 
time, there appears a "mail" directory in their home directories after login.  
This would indicate to me that the login was successful.  Further, I 
cut/pasted a message sent to one of the virtual users from the vmail INBOX 
(/var/mail/vmail) into the virtual user's INBOX (/var/mail/jdunkin).  Then, 
logged in as this virtual user and ACTUALLY got the mail.  I know this stuff 
works.  What must be done to make sendmail do its thing for deliver?

What is necessary to fix this situation?

Andy


Re: [Dovecot] Imap assertion (dovecot-1.1.beta13)

2008-01-07 Thread Nuno Lopes


Timo Sirainen wrote:
> On Mon, 2008-01-07 at 15:38 +, Nuno Lopes wrote:
>   
>> Hi,
>>   I continue testing the beta versions and have seen a great improvement
>> over the last few ones.
>> On beta13 I'm seeing the following assert on some client folders:
>>  file index-mail.c: line 759 (index_mail_stream_destroy_callback):
>> assertion failed: (mail->data.destroying_stream)
>>
>> If you need I can try and reproduce this in a more controled environment
>> to pinpoint the problem.
>> 
>
> A few people have now reported this, but I haven't managed to reproduce
> it myself. So it would be nice if someone told me how..
>
>   
Sorry, missed those. So here goes some more detail:

this happens when I connect to a folder (in my case Sent). I've
reproduced the bug by sending the following commands directly to the
imap server:


3 select "Sent"
4 getquotaroot "Sent"
5 UID fetch 1:* (FLAGS)
6 UID fetch 1:201 (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From
To Cc Subject Date Message-ID Priority X-Priority References Newsgroups
In-Reply-To Content-Type)])


then the server crashes. Attached you can find an strace log made after
command 5. If you need any more detail I'll be glad to give it ...

Hope this helps,
--
Nuno Lopes
03:42:42.009485 gettimeofday({1199763762, 9719}, {0, 0}) = 0
03:42:42.009773 gettimeofday({1199763762, 9790}, NULL) = 0
03:42:42.009828 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, 
{fd=0, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}], 2, 1729) = 0
03:42:43.754391 gettimeofday({1199763763, 754415}, {0, 0}) = 0
03:42:43.754460 gettimeofday({1199763763, 754472}, NULL) = 0
03:42:43.754508 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, 
{fd=0, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}], 2, 5000) = 0
03:42:48.769219 gettimeofday({1199763768, 769268}, {0, 0}) = 0
03:42:48.769322 gettimeofday({1199763768, 769337}, NULL) = 0
03:42:48.769370 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, 
{fd=0, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}], 2, 2559) = 0
03:42:51.340389 gettimeofday({1199763771, 340414}, {0, 0}) = 0
03:42:51.340460 gettimeofday({1199763771, 340472}, NULL) = 0
03:42:51.340508 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL}, 
{fd=0, events=POLLIN|POLLPRI|POLLERR|POLLHUP|POLLNVAL, revents=POLLIN}], 2, 
2429) = 1
03:42:51.842406 gettimeofday({1199763771, 842433}, {0, 0}) = 0
03:42:51.842483 read(0, "6 UID fetch 1:201 (UID RFC822.SI"..., 4031) = 172
03:42:51.842798 
open("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot.index.cache", 
O_RDWR|O_LARGEFILE) = 10
03:42:51.843662 fstat64(10, {st_mode=S_IFREG|0600, st_size=15857, ...}) = 0
03:42:51.843826 mmap2(NULL, 16384, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40149000
03:42:51.843893 pread(10, 
"\1\10\0\0^F\202G\225G\202G\0\0\0\0\0\0\0\0,\1\0\0\0\0\0"..., 4096, 0) = 4096
03:42:51.843999 pread(10, "\0\0\0\0\351\0\0\0\n\0\0\0", 12, 32) = 12
03:42:51.844066 pread(10, 
"\1\10\0\0^F\202G\225G\202G\0\0\0\0\0\0\0\0,\1\0\0\0\0\0"..., 4096, 0) = 4096
03:42:51.844203 
open("portugalmail.pt/ob/mnuno.lopes/.Sent/cur/1083034619.20947_0.frodo,S=410:2,S",
 O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
03:42:51.845149 umask(0177) = 077
03:42:51.845198 time(NULL)  = 1199763771
03:42:51.845247 
lstat64("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot-uidlist.lock", 
0xbfffeee0) = -1 ENOENT (No such file or directory)
03:42:51.845584 
open("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot-uidlist.lock", 
O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 11
03:42:51.849987 write(11, "19464:eowyn", 11) = 11
03:42:51.850048 fstat64(11, {st_mode=S_IFREG|0600, st_size=11, ...}) = 0
03:42:51.850188 close(11)   = 0
03:42:51.852372 
lstat64("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot-uidlist.lock", 
{st_mode=S_IFREG|0600, st_size=11, ...}) = 0
03:42:51.852546 umask(077)  = 0177
03:42:51.852592 stat64("portugalmail.pt/ob/mnuno.lopes/.Sent", 
{st_mode=S_IFDIR|0700, st_size=496, ...}) = 0
03:42:51.852722 chown32(0x8104458, 0x1f5, 0x) = 0
03:42:51.853368 open("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot-uidlist", 
O_RDONLY|O_LARGEFILE) = 11
03:42:51.853455 close(11)   = 0
03:42:51.853496 stat64("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot-uidlist", 
{st_mode=S_IFREG|0600, st_size=10763, ...}) = 0
03:42:51.853638 fstat64(8, {st_mode=S_IFREG|0600, st_size=10763, ...}) = 0
03:42:51.853818 brk(0x814b000)  = 0x814b000
03:42:51.853908 alarm(180)  = 0
03:42:51.853961 fcntl64(6, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=0, 
len=0}, 0xb070) = 0
03:42:51.854715 alarm(0)= 180
03:42:51.854835 stat64("portugalmail.pt/ob/mnuno.lopes/.Sent", 
{st_mode=S_IFDIR|0700, st_size=496, ...}) = 0
03:42:51.855149 chown32(0x8104490, 0x1f5, 0x) = 0
03:42:51.856022 
stat64("portugalmail.pt/ob/mnuno.lopes/.Sent/dovecot.index.log", 
{st_mode=S_IFREG|0600, st_size=2168, ...}) = 

Re: [Dovecot] Imap assertion (dovecot-1.1.beta13)

2008-01-07 Thread Timo Sirainen
On Mon, 2008-01-07 at 15:38 +, Nuno Lopes wrote:
> Hi,
>   I continue testing the beta versions and have seen a great improvement
> over the last few ones.
> On beta13 I'm seeing the following assert on some client folders:
>  file index-mail.c: line 759 (index_mail_stream_destroy_callback):
> assertion failed: (mail->data.destroying_stream)
> 
> If you need I can try and reproduce this in a more controled environment
> to pinpoint the problem.

A few people have now reported this, but I haven't managed to reproduce
it myself. So it would be nice if someone told me how..



signature.asc
Description: This is a digitally signed message part


Re: [Dovecot] assertion with outlook

2008-01-07 Thread Timo Sirainen
On Mon, 2008-01-07 at 22:53 +0100, Guenther Sommer wrote:
> Jan  7 18:27:01 siege dovecot: IMAP(userA): file strfuncs.c: line 165 
> (p_strndup): assertion failed: (max_chars != (size_t)-1)

Fixed since v1.0.6:

- CREATE: Don't assert-crash if trying to create namespace prefix.

I don't know why Outlook would try to do that though.



signature.asc
Description: This is a digitally signed message part


Re: [Dovecot] Problem with passwords surrounded by curly braces

2008-01-07 Thread Timo Sirainen
On Mon, 2008-01-07 at 23:59 +0100, Frank Kintrup wrote:
> Manually altering the users password in the database to "{PLAIN}"
> (where "" is the user's password WITH curly braces) fixed this problem
> for me at this time, but the time a user chooses such a strange password
> I would have to edit the table again. So in my opinion the {SCHEME}-prefix
> is not a useful thing. Why would anyone need it, anyway? Shouldn't all
> passwords have the same scheme which is set in the dovecot.conf file once?

Often they are, but there are installations which use multiple schemes.
For example otherwise it would be pretty much impossible to change a
scheme for an existing installation.

> If the feature is indeed used: with a database lookup it should be
> replaced by an optional database field or, if that's not possible, it
> should be possible to disable this feature from the config file.

It's possible since v1.0.8. I guess I should write about this to wiki as
well:

+ Authentication: Added "password_noscheme" field that can be used
  instead of "password". "password" treats "{prefix}" as a password
  scheme while "password_noscheme" treats it as part of the password
  itself. So "password_noscheme" should be used if you're storing
  passwords as plaintext. Non-plaintext passwords never begin
  with "{", so this isn't a problem with them.



signature.asc
Description: This is a digitally signed message part


Re: [Dovecot] Problem with passwords surrounded by curly braces

2008-01-07 Thread Przemyslaw Wegrzyn

Frank Kintrup wrote:

I would have to edit the table again. So in my opinion the {SCHEME}-prefix
is not a useful thing. Why would anyone need it, anyway? Shouldn't all
passwords have the same scheme which is set in the dovecot.conf file once?
  
Sometimes one has to import the user data from some legacy system using 
a different scheme than the one you'd like to use.

Believe me, it is really useful for anyone migrating from legacy systems :)

Przemyslaw




[Dovecot] Problem with passwords surrounded by curly braces

2008-01-07 Thread Frank Kintrup
Hello,

one of my users set his password to something surrounded by curly braces,
and promptly all access to his mailbox was refused. After looking through
the logs I found an entry "Unknown password scheme ", where ""
is the user's password, but without the curly braces.
I then browsed through the documentation and there was explained that it
is possible to prefix the password with the password scheme in curly
braces, like "{PLAIN}" where  is the password itself.

Manually altering the users password in the database to "{PLAIN}"
(where "" is the user's password WITH curly braces) fixed this problem
for me at this time, but the time a user chooses such a strange password
I would have to edit the table again. So in my opinion the {SCHEME}-prefix
is not a useful thing. Why would anyone need it, anyway? Shouldn't all
passwords have the same scheme which is set in the dovecot.conf file once?

If the feature is indeed used: with a database lookup it should be
replaced by an optional database field or, if that's not possible, it
should be possible to disable this feature from the config file.


Frank



[Dovecot] Deliver core dump in b13 (hg 20080102)

2008-01-07 Thread mikkel
Hi there


I'm redirecting e-mails from [EMAIL PROTECTED] to another account
([EMAIL PROTECTED]) using sieves "redirect" with sieve 1.1.3. The e-mail
is redirected just fine.
But deliver still creates a core dump and returns an "e-mail
undeliverable" to the sending account (even though delivery is
successful).


My .dovecot.sieve contains just this:
redirect "[EMAIL PROTECTED]";
keep;


As stated before the e-mail is both forwarded and delivered locally just
fine.
But the sending account receives this error:
"<[EMAIL PROTECTED]>: Command died with signal 6:
"/opt/freeware/dovecot-20080102/libexec/dovecot/deliver""


Also deliver.log shows some errors (shown below).

The “nfs_flush_file_handle_cache_dir” error makes me wonder - seems like
it tries to delete the homedir of the accounts maildir storage.

Also it seems to me like a minor error since the delivery functions as it
should, apart from the delivery error it returns and the core dump.

Regards, Mikkel


[EMAIL PROTECTED] tail -f /log/deliver.log | grep @euro123.dk
deliver([EMAIL PROTECTED]): Jan 07 22:20:02 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:02 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:02 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:02 Info:
msgid=<[EMAIL PROTECTED]>: forwarded to <[EMAIL PROTECTED]>
deliver([EMAIL PROTECTED]): Jan 07 22:20:03 Info:
msgid=<[EMAIL PROTECTED]>: saved mail to INBOX
deliver([EMAIL PROTECTED]): Jan 07 22:20:03 Panic: file index-mail.c: line
1042 (index_mail_close): assertion failed: (!mail->data.destroying_stream)
deliver([EMAIL PROTECTED]): Jan 07 22:20:03 Error: Raw backtrace: 0x855c0
-> 0x4decc -> 0x4e360 -> 0x55204 -> 0x2266c -> 0x2040c
deliver([EMAIL PROTECTED]): Jan 07 22:20:04 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:05 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:06 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:07 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:07 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:07 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:07 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:07 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argument
deliver([EMAIL PROTECTED]): Jan 07 22:20:07 Error:
nfs_flush_file_handle_cache_dir: rmdir(/nfs/euro123.dk/mikkel) failed:
Invalid argumen

[Dovecot] assertion with outlook

2008-01-07 Thread Guenther Sommer
i saw two crashes in my syslog with dovecot, and google did not report 
any known problems. i have no problems using dovecot, thus bugreport is 
just for information.


following information:
ubuntu gutsy gibbon server
amd64
ext3

outlook 2003 & 2007, just retrieving mails. mails have been migrated via 
imapsync 2 days before to this server. dovecot is imap-server and LDA.


has been seen with two different users, following syslog entries:

Jan  7 18:27:01 siege dovecot: IMAP(userA): file strfuncs.c: line 165 
(p_strndup): assertion failed: (max_chars != (size_t)-1)
Jan  7 18:27:01 siege dovecot: IMAP(userA): Raw backtrace: imap 
[0x46372e] -> imap [0x46349c] -> imap(t_strndup+0) [0x470cf0] -> 
imap(cmd_create+0xd1) [0x4142c1] -> imap [0x4178f7] -> imap [0x417989] 
-> imap(_client_input+0x6d) [0x417fbd] -> 
imap(io_loop_handler_run+0x101) [0x468e61] -> imap(io_loop_run+0x18) 
[0x467f28] -> imap(main+0x3f2) [0x41f6c2] -> 
/lib/libc.so.6(__libc_start_main+0xf4) [0x2b974f225b44] -> imap [0x4132e9]

Jan  7 18:27:01 siege dovecot: child 27443 (imap) killed with signal 6

Jan  7 18:35:36 siege dovecot: IMAP(userB): file strfuncs.c: line 165 
(p_strndup): assertion failed: (max_chars != (size_t)-1)
Jan  7 18:35:36 siege dovecot: IMAP(userB): Raw backtrace: imap 
[0x46372e] -> imap [0x46349c] -> imap(t_strndup+0) [0x470cf0] -> 
imap(cmd_create+0xd1) [0x4142c1] -> imap [0x4178f7] -> imap [0x417989] 
-> imap(_client_input+0x6d) [0x417fbd] -> 
imap(io_loop_handler_run+0x101) [0x468e61] -> imap(io_loop_run+0x18) 
[0x467f28] -> imap(main+0x3f2) [0x41f6c2] -> 
/lib/libc.so.6(__libc_start_main+0xf4) [0x2ad667dfeb44] -> imap [0x4132e9]

Jan  7 18:35:36 siege dovecot: child 27902 (imap) killed with signal 6

user authentifaction is done against local unix users.

# 1.0.5: /etc/dovecot/dovecot.conf
log_timestamp: %Y-%m-%d %H:%M:%S
ssl_cert_file: /etc/ssl/certs/mail.pem
ssl_key_file: /etc/ssl/private/mail.key
login_dir: /var/run/dovecot/login
login_executable: /usr/lib/dovecot/imap-login
mail_extra_groups: mail
mail_location: maildir:~/Maildir
imap_client_workarounds: outlook-idle netscape-eoh tb-extra-mailbox-sep
namespace:
  type: private
  prefix: INBOX.
  inbox: yes
auth default:
  passdb:
driver: pam
  userdb:
driver: passwd
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix


with kind regards, guenther sommer.


Re: [Dovecot] What would you tell the CIO in an "ABCs of Email" overview?

2008-01-07 Thread Esther Schindler

And finally, part 2 is published too!

Let me know if I made any boo-boos.

ABC: An Introduction to E-Mail Technology
E-mail works so quickly and well that its complexity is hidden from end
users. That's a good thing. But IT managers should know the very basics
of how an e-mail message gets from sender to recipient, and what can
delay or prevent its arrival. Read this introduction to the technology
basics and e-mail protocols.
http://www.cio.com/article/169700

Esther Schindler
senior online editor, CIO.com

P.S. I suspect you'd like your management and users to understand this
stuff, so that you don't have to explain it over and over. So if you'd
be so kind as to nudge it up on digg.com (
http://digg.com/software/What_Makes_E_mail_Tick ) or slashdot (
http://slashdot.org/firehose.pl?op=view&id=454656 )? I wouldn't mind  
at all.


On Aug 7, 2007, at 11:09 AM, Esther Schindler wrote:


The article is live... as part 1, anyway.

As you'll soon see, it was impossible to do an ABCs of Email that  
covered both technology and people issues. So I've split these into  
two articles. I'll do the "POP vs IMAP" stuff separately... as soon  
as I recover from this one.


I tried to make this document the one you want to print out and  
slap on an exec's desk when they do something totally dumb. (This  
way it's not YOU saying they were clueless.) Feel free to post  
anywhere you  like... I'm such a slut for pageviews.


Comments and corrections are welcome, particularly if they also  
include praise. :-)

ABC: An Introduction to E-mail Management

Helping nontechnical managers calibrate expectations, learn the key  
issues in e-mail management and identify issues in setting  
corporate e-mail policies.
http://www.cio.com/article/128450/ 
ABC_An_Introduction_to_E_mail_Management


Esther Schindler
senior online editor, CIO.com



On May 7, 2007, at 12:37 PM, Esther Schindler wrote:

One of the key points that came up when I researched and wrote the  
"Five Things CIOs Should Know about Fighting Spam" article (http:// 
www.cio.com/article/28830) was that they should know the basics of  
how email works. Otherwise, said plenty of techies, the CIO won't  
have the first idea of what the email admin is complaining about.


So I'm going to do my part. I'm going to write an "ABCs of Email"  
article (to accompany the many other ABCs articles we have on  
CIO.com, at http://www.cio.com/article/40242 ). I'd like your  
input on the topics that should be included, keeping in mind the  
fact that the target reader is a CIO, IT manager, or someone who  
wants to understand the basics, *not* actively get involved in  
email management.


You don't need to write an essay for me or inundate me with links  
(though hey, if you want to make my life easier I shall not  
complain). What I'm looking for, primarily, are the categories of  
information that I should cover. In other words, if your CIO had  
an email ephiphany and asked you to give a half-hour presentation,  
what would you include?


This won't be an "Expert says..." article nor will it be "Geek on  
the street says" I intend to compile and research the "least  
you need to know" for the not-necessarily-techie bosses out there.  
And hopefully the end result will be that you have one less dumb  
question to deal with in your life.


So: any suggestions? (You can reply privately if you prefer.)

Esther Schindler
senior online editor, CIO.com
her blog: http://advice.cio.com/taxonomy/term/34








[Dovecot] do not lose mail when dovecot is dead

2008-01-07 Thread Daniel
Hi!

Recently I've experienced problems with dovecot. Dovecot died silently, 
what means is that there are no core files, nor any indication in the 
log files, just the "kevent(): Invalid argument" messages. Dovecot just 
died, so deliver could not connect to the auth-master socket, which 
means that messages couldn't been delivered. The problem is that 
postfix thought that the delivery was successful, and didn't place the 
message to delay, but deliver(LDA) couldn't deliver the message, so it 
got lost.

An example:
postfix/pickup[29619]: 8A1C6F261: uid=1001 from=
postfix/cleanup[19148]: 8A1C6F261: 
message-id=<[EMAIL PROTECTED]>
postfix/qmgr[29441]: 8A1C6F261: from=<[EMAIL PROTECTED]>, size=585, nrcpt=1 
(queue active)
deliver(leva): Loading modules from 
directory: /usr/local/lib/dovecot/lda
deliver(leva): Module 
loaded: /usr/local/lib/dovecot/lda/lib10_quota_plugin.so
deliver(leva): Module 
loaded: /usr/local/lib/dovecot/lda/lib90_cmusieve_plugin.so
deliver(leva): Can't connect to auth server 
at /var/run/dovecot/auth-master: Connection refused
postfix/pipe[8582]: 8A1C6F261: to=<[EMAIL PROTECTED]>, orig_to=, 
relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0
.68, dsn=2.0.0, status=sent (delivered via dovecot-lda service)
postfix/qmgr[29441]: 8A1C6F261: removed

See? Postfix removed it from the queue, so basically all bets are off, 
and everything depends on deliver, but it just dropped the message.
Is there anything that can be done regarding this issue?

Thanks!

Daniel


[Dovecot] Imap assertion (dovecot-1.1.beta13)

2008-01-07 Thread Nuno Lopes
Hi,
  I continue testing the beta versions and have seen a great improvement
over the last few ones.
On beta13 I'm seeing the following assert on some client folders:
 file index-mail.c: line 759 (index_mail_stream_destroy_callback):
assertion failed: (mail->data.destroying_stream)

If you need I can try and reproduce this in a more controled environment
to pinpoint the problem.

Thanks,
--
Nuno Lopes