from:"Benjamin R. Haskell"


On Sun, 2 Dec 2007, Timo Sirainen wrote:


On Sat, 2007-12-01 at 16:04 +0200, Velko Ivanov wrote:

Maybe it would be good to update the description of available

storage drivers in configure script.

Yes .. both 'configure --help' and the wiki are very uninformative on
this topic.


Fixed: http://hg.dovecot.org/dovecot/rev/84bcf1c8b07a


Is there a description of the raw format somewhere on the wiki? (No pages 
have 'raw' in their titles, and I don't see it on MailboxFormat.) What's 
"raw" about it?


And a general wiki question: is there some way you can remove the wiki 
help pages from the search results? A search for 'raw', for example, 
returns 41 results, 36 of which appear to be localized help pages that are 
installed by default. (Plus, 2 of the 5 'relevant' results are about 
halfway down the list.)


Best,
Ben

Re: [Dovecot] namespaces, shared mailboxes


On Sun, 2 Dec 2007, Timo Sirainen wrote:


On Sat, 2007-12-01 at 23:59 +0100, Alexander 'Leo' Bergolth wrote:

I'd like to provide shared mailboxes with maildir that should appear
like 'Shared/' to the clients.

Using the namespace configuration below, everything works fine, exept
one thing: Mail clients (only tested with Thunderbird) won't allow to
put mails directly in 'Shared/mailboxname' (the folder it is greyed
out). You currently have to create subfolders and put the mails in those
subfolders.

..

namespace shared {
  separator = /
  # hidden = yes
  prefix = Shared/spamrep/
  location =
maildir:/var/spool/mail/Shared/spamrep:CONTROL=~/Maildir/control/Shared/spamrep:INDEX=~/Mail\
dir/index/Shared/spamrep


I find it strange that this kind of configuration even appears to
work. :) If you somehow manage to get it working with v1.0, there's a
good chance that it won't work anymore with v1.1.

So if you want to access "Shared/spamrep" as a mailbox, the prefix must
be Shared/.

If you wanted users to have different views of what the mailboxes look
like, you could just change the location to be different for different
users. Create symlinks to the visible global mailboxes to those
locations.


Having multiple namespaces setup that way seems reasonable to me.

e.g.
/var/spool/mail/Shared/tech/...
/var/spool/mail/Shared/financial/...

where 'Shared/tech' would be visible to many, but 'Shared/financial' would 
be visible only to execs/accountants. And both would show up under a 
common 'Shared/' prefix to keep them distinct from user folders.


It sounds like he just wants to be able to SELECT the root of a namespace.

Best,
Ben

Re: [Dovecot] namespaces, shared mailboxes


On Sun, 2 Dec 2007, Nikolay Shopik wrote:


On 02.12.2007 23:21, Alexander 'Leo' Bergolth wrote:



[...]

I'd like to be able to deliver e.g. new mail to the technical support
directly to "Shared/tech/" but if that's not possible, it isn't a big
problem, I'll just use "Shared/tech/INCOMING".

Cheers,
--leo


You can't deliver to namespaces using 1.0 dovecot tree only 1.1 support it.



Using dovecot's 'deliver' in 1.0, you can't. It's pretty easy using 
another MDA/LDA.


e.g. using procmail: DEFAULT=/var/spool/mail/Shared/tech/

Best,
Ben

Re: [Dovecot] namespaces, shared mailboxes


On Sun, 2 Dec 2007, Alexander 'Leo' Bergolth wrote:

On 12/02/2007 09:35 PM, Benjamin R. Haskell wrote:

On Sun, 2 Dec 2007, Nikolay Shopik wrote:

On 02.12.2007 23:21, Alexander 'Leo' Bergolth wrote:

[...]
I'd like to be able to deliver e.g. new mail to the technical support
directly to "Shared/tech/" but if that's not possible, it isn't a big
problem, I'll just use "Shared/tech/INCOMING".


You can't deliver to namespaces using 1.0 dovecot tree only 1.1
support it.


Using dovecot's 'deliver' in 1.0, you can't. It's pretty easy using
another MDA/LDA.

e.g. using procmail: DEFAULT=/var/spool/mail/Shared/tech/


Yes, I'm already doing exactly that:
tech-support: "| /usr/bin/procmail DEFAULT=/var/spool/mail/Shared/tech/
UMASK=007"

But the problem is that clients won't see the mails, unless I create an
empty directory "/var/spool/mail/Shared/tech/.INBOX". Once that
directory is in place, clients will show the delivered mails in
"Shared/tech/INBOX". (Even though I delivered them to "../tech/".)


I figured as much; sorry to have been unclear. I was just pointing out 
that Nikolay's concern about 'deliver' was orthogonal to the 
non-SELECT-able namespace-root problem.


Best,
Ben

Re: [Dovecot] Automatic Index Generation

2007-12-09 Thread Benjamin R. Haskell


On Sun, 9 Dec 2007, Timo Sirainen wrote:

On Sun, 2007-12-09 at 16:29 +0100, Maciej Poszywak wrote:

Timo Sirainen wrote:

I guess you mean logging in with POP3? There the slowdown comes from
getting all messages' virtual sizes. So your preindexer could probably
do this by running pop3 for all users. If you use only a single UID for
users, you could do something like:

for user in `cat users`; do
  export MAIL=maildir:/home/$user/Maildir
  echo "quit" | /usr/local/libexec/dovecot/pop3
done



[EMAIL PROTECTED]:~$ env | grep MAIL
MAIL=maildir:/var/mail/testuser
[EMAIL PROTECTED]:~$ echo "quit" | /usr/lib/dovecot/pop3
pop3(vmu1): Fatal: pop3_uidl_format setting is missing from config file

I have pop3_uidl_format correctly defined in the config file. I've also
tried to strace pop3, to find where it does look for it, but with no
success.


It gets it from environment:

POP3_UIDL_FORMAT=... pop3

In general all settings are passed in environment using uppercased
names.


In other words, you (Maciej) probably don't want to run 'pop3' directly. I 
suspect you'd rather do:


/path/to/dovecot --exec-mail pop3

This will set up the environment for the 'pop3' executable the same way 
dovecot normally does it.


Best,
Ben

Re: [Dovecot] Automatic Index Generation

2007-12-09 Thread Benjamin R. Haskell


On Sun, 9 Dec 2007, Timo Sirainen wrote:

On Sun, 2007-12-09 at 13:48 -0500, Benjamin R. Haskell wrote:

[EMAIL PROTECTED]:~$ echo "quit" | /usr/lib/dovecot/pop3
pop3(vmu1): Fatal: pop3_uidl_format setting is missing from config file

I have pop3_uidl_format correctly defined in the config file. I've also
tried to strace pop3, to find where it does look for it, but with no
success.


It gets it from environment:

POP3_UIDL_FORMAT=... pop3

In general all settings are passed in environment using uppercased
names.


In other words, you (Maciej) probably don't want to run 'pop3' directly. I
suspect you'd rather do:

/path/to/dovecot --exec-mail pop3

This will set up the environment for the 'pop3' executable the same way
dovecot normally does it.


Yes, I was going to mention that but I wasn't sure how well it'd work
when you want to run it for multiple users. At least you can't then
override MAIL environment directly, but rather you need to override USER
and/or HOME.



Maybe it'd be easiest with 'su'? Something along the lines of:

su username -l -c /path/to/dovecot --exec-mail pop3

(Though this doesn't seem to be working for me. I've reïnstalled dovecot 
too many times. Something's up with permissions.)



Another way that might be relatively easy:

Set up, in dovecot.conf:

protocol pop3 { # in this section
mail_executable = /path/to/envscript.sh

And, in /path/to/envscript.sh:

#!/bin/sh
env > /path/to/saved-environment
exec /path/to/pop3

That'll give you all the environment variables dovecot would normally set 
up. Then you could filter out the user-specific ones to set up manually, 
and use e.g. envdir (from DJB's daemontools) to handle the common ones:


$ mkdir common-env
$ perl -F= -lanwe 'my $var = shift; open my $f, ">common-env/$var" or die ">$var: $!"; 
print $f join "=", @F' /path/to/saved-environment

Then:

env USER=blah HOME=blah MAIL=blah envdir /path/to/common-env 
/usr/libexec/dovecot/pop3

Best,
Ben

Re: [Dovecot] imap+unix users and pop3+virtual users

2007-12-16 Thread Benjamin R. Haskell


[Reversing the top-posting]

On Sun, 16 Dec 2007, Wendell Turner wrote:


[...]

The trailing '/' means mbox format, correct?




No. The trailing '/' means maildir format. (The '/' makes the path look 
like a directory.)




However, I solved my own problem, but I don't know why.
Enlightenment would be appreciated.

[...]

Q: why did commenting out the mail_location line make pop3
retrieval of the virtual host mailboxes work correctly?


Commenting out the mail_location line made dovecot fall back to the 
default locations. See: http://wiki.dovecot.org/MailLocation


Best,
Ben

Re: [Dovecot] imap+unix users and pop3+virtual users

2007-12-16 Thread Benjamin R. Haskell


On Sun, 16 Dec 2007, Benjamin R. Haskell wrote:


[Reversing the top-posting]

On Sun, 16 Dec 2007, Wendell Turner wrote:


[...]

The trailing '/' means mbox format, correct?




No. The trailing '/' means maildir format. (The '/' makes the path look like 
a directory.)




Forgot to add: specifying the 'mbox:' explicitly should make that a moot 
point. Dovecot only has to guess (by using "Does the path end in '/'?") if 
you don't specify mbox/dbox/maildir/etc. (I suspect it might also depend 
on whether the file/dir already exists.)






However, I solved my own problem, but I don't know why.
Enlightenment would be appreciated.

[...]

Q: why did commenting out the mail_location line make pop3
retrieval of the virtual host mailboxes work correctly?


Commenting out the mail_location line made dovecot fall back to the default 
locations. See: http://wiki.dovecot.org/MailLocation


Best,
Ben

Re: [Dovecot] imap+unix users and pop3+virtual users

2007-12-20 Thread Benjamin R. Haskell


On Thu, 20 Dec 2007, Timo Sirainen wrote:


On Sun, 2007-12-16 at 21:47 -0500, Benjamin R. Haskell wrote:

[Reversing the top-posting]

On Sun, 16 Dec 2007, Wendell Turner wrote:


[...]

The trailing '/' means mbox format, correct?




No. The trailing '/' means maildir format. (The '/' makes the path look
like a directory.)


Dovecot doesn't assume anything based on '/' suffix. In fact it always
just strips it, so there's no difference whatsoever if it's there or
not.


Not true.

Using either dovecot-1.1_beta11 or dovecot-1.0.0 (from hg).


Using mail_location = ~/test-mail/, it errors out with:
"
Ambiguous mail location setting, don't know what to do with it: 
/home/username/test-mail/ (try prefixing it with mbox: or maildir:)

"

if test-mail is: nonexistent, a file, or a directory without new,tmp,cur. 
But it succeeds when test-mail is a proper maildir.


Using mail_location = ~/test-mail, it also succeeds in the case that 
test-mail is a file.



From the looks of the other error messages, this might be happenstance (or 
just unintentional). The '/' is doubled-up when mail_location = 
~/test-mail/.


E.g.

maildir autodetect: stat(/home/user/test-mail//cur) failed: Not a directory

vs.

maildir autodetect: stat(/home/user/test-mail/cur) failed: Not a directory


Best,
Ben

Re: [Dovecot] Brute Force Blocking?

2007-12-20 Thread Benjamin R. Haskell


On Thu, 20 Dec 2007, Ben Cadieux wrote:


Hi Everyone,

Before I begin, I'd just like to mention: I love dovecot.  Thank you :)

Anyway, today I had 8000 login attempts to my dovecot server in an
hour before blocking the IP with my firewall.

After googling, I didn't see very much discussion on the topic.  There
was some mention of blocksshd which was supposed to support dovecot in
the next release (but doesn't appear to) and also fail2ban.  While a
script that parses logfiles will work, I'm not sure that this is the
best way to go about handling repeated authentication failure.

Would it not be best built into dovecot? [...]



I'd vote "no", with the caveat that I don't use any of these tools.

Parsing logfiles might make it more brittle, but it also allows the tool 
to protect many services in a generic way. I don't want to have to protect 
against DOS or dictionary attacks for Apache, VSFTP, dovecot, sshd, 
PostgreSQL, and whatever else in different config files. It'd be best to 
handle that one layer up. Doing it outside of dovecot even allows 
correlations to be made (e.g. ban sooner if the same IP is trying to 
break both SSH and FTP). Don't know if the tools *do* this, but still.


That's my 2¢,
Ben Haskell

Re: [Dovecot] Brute Force Blocking?

2007-12-20 Thread Benjamin R. Haskell


On Thu, 20 Dec 2007, Peter Hessler wrote:

On 2007 Dec 20 (Thu) at 15:51:02 -0500 (-0500), Benjamin R. Haskell wrote:

On Thu, 20 Dec 2007, Ben Cadieux wrote:


Hi Everyone,

Before I begin, I'd just like to mention: I love dovecot.  Thank you :)

Anyway, today I had 8000 login attempts to my dovecot server in an
hour before blocking the IP with my firewall.

After googling, I didn't see very much discussion on the topic.  There
was some mention of blocksshd which was supposed to support dovecot in
the next release (but doesn't appear to) and also fail2ban.  While a
script that parses logfiles will work, I'm not sure that this is the
best way to go about handling repeated authentication failure.

Would it not be best built into dovecot? [...]



I'd vote "no", with the caveat that I don't use any of these tools.

Parsing logfiles might make it more brittle, but it also allows the tool to
protect many services in a generic way. I don't want to have to protect
against DOS or dictionary attacks for Apache, VSFTP, dovecot, sshd,
PostgreSQL, and whatever else in different config files. It'd be best to
handle that one layer up. Doing it outside of dovecot even allows
correlations to be made (e.g. ban sooner if the same IP is trying to break
both SSH and FTP). Don't know if the tools *do* this, but still.

That's my 2??,
Ben Haskell



Except for the part where they stay connected forever, and keep
retrying logins.  One tcp connection, so nothing for the network level
to look for.


I thought you had me, there. But, it's not at the "network" level, per se, 
"one level up" conceptually, not necessarily up in the standard 7 layers.


The tools parse logfiles. dovecot and (I think) the others I mentioned log 
an auth error after each failed attempt.


Best,
Ben

Re: [Dovecot] Permanent roadmap page on web

2007-12-30 Thread Benjamin R. Haskell


On Sun, 30 Dec 2007, Richard Laager wrote:


On Sun, 2007-12-30 at 07:41 +0200, Timo Sirainen wrote:

Most replies to that mail ignored the 3) part, which is
the main reason there's no issue tracker yet.


Regarding your three issues:

1. Yes, they all suck in different ways. You have to pick one with the
least suck for you. ;)

2. If you need hosting with PHP and MySQL, contact me off-list and I
might (but no promises just yet) be able to help.



If Timo's not using PHP or MySQL for anything other than bug-tracking, 
those just become two more things to have to configure and maintain. 
Where/how they're hosted just changes how much setup and maintenance need 
to be done. It can't be eliminated fully.




3. What if you setup bug mails to come to this list?



Isn't that what [EMAIL PROTECTED] does? Or was the original 
suggestion never implemented?


Best,
Ben

Re: [Dovecot] Delay on failed pw attempts

2008-01-01 Thread Benjamin R. Haskell


On Tue, 1 Jan 2008, Timo Sirainen wrote:


On Tue, 2008-01-01 at 15:59 -0500, Dean Brooks wrote:

Hi,

Is there a way, or can a way be added, to add an "auth_failed_delay=10s"
style option that would put in an artificial delay after a failed
password attempt?

As it stands now, Dovecot seems highly vulnerable to widescale
brute-force password dictionary scans.

Even if it's not configurable, can a delay be hardcoded to something
like, say, 10 or 15 seconds?


Failed auth requests are put to a queue that's flushed every 2 seconds.
So there is already a delay. I don't think it's a good idea to increase
it up from 2 seconds, it just gets annoying when you type the wrong
password accidentally.



I'd think the increase in effort required for a dictionary attack would 
outweigh the infrequent inconvenience to valid users.




Although I suppose I could change the code so that it always waits 2
seconds instead of flushing all of them.



Any reason that '2 seconds' couldn't be configurable (with a default of 
2)? In my situation, I'm the only user of my system, and I use reasonably 
secure passwords, so brute-force doesn't really scare me. As a sysadmin at 
an ISP or company with (too-)lenient password requirements, on the other 
hand, it'd be nice to slow an attack by a larger factor.


Best,
Ben

Re: [Dovecot] Delay on failed pw attempts

2008-01-02 Thread Benjamin R. Haskell


On Tue, 1 Jan 2008, Asheesh Laroia wrote:


On Tue, 1 Jan 2008, Dean Brooks wrote:


Hi,

Is there a way, or can a way be added, to add an "auth_failed_delay=10s"
style option that would put in an artificial delay after a failed
password attempt?

As it stands now, Dovecot seems highly vulnerable to widescale
brute-force password dictionary scans.


But not if you secure access to Dovecot using e.g. fail2ban.  Why is adding 
complexity to Dovecot better than using a dedicated tool?




I fell in the 'use another tool' (fail2ban or similar) camp the last time, 
but this thread made me wonder:


Does fail2ban allow you to tarpit, rather than outright-ban, IP's? I've 
always thought tarpitting the better option of the two. Seems sneakier 
(Fight back without the attacker necessarily knowing you're fighting).


Best,
Ben

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] Maildir handling

2008-01-14 Thread Benjamin R. Haskell


On Mon, 14 Jan 2008, Sascha Holzleiter wrote:


Hi,

we just setup a new mailserver for our company with some sieve filtering
in place. Everything works as expected but there is one flaw.
We setup the per user sieve filters in files within the users mailbox
maildir as follows:

lrwxrwxrwx   1 mail mail  21 Jan 13 17:20 .dovecot.sieve ->
sieve/phpscript.sieve

This link is actually picked up by dovecot and being announced as an
IMAP folder which gives an error in certain MUAs as they try to access
it.

Is there a way to let dovecot check if the link is really a maildir, so
lets say a directory with a maildirfolder file within it? Or just to
hide this link from dovecot so its not advertised as an IMAP folder?



In Maildir++ [1], if it doesn't start with a '.' it shouldn't be seen as a 
folder. I seem to recall some discussion of adding an option that would 
affect that in the 1.1 series.


[1] http://wiki.dovecot.org/MailboxFormat/Maildir

Best,
Ben

Re: [Dovecot] Shared mailboxes

2008-01-26 Thread Benjamin R. Haskell


On Fri, 25 Jan 2008, Wouter Amsterdam wrote:


L.S.

It is not clear to me why I should use namespaces or symlinks to share a
single maildir mailbox with multiple users. Why not configure multiple mail
clients with the same account information?


Assuming your users also have non-shared email accounts and folders, it's 
generally easier from their point of view to have the shared folder(s) 
accessible using their own, normal account information.


It's also the case that not all mail clients play nice with IMAP accounts 
that get accessed "behind their back" (due to unexpected changes). But, I 
don't think there's anything problematic on the server side.


Best,
Ben

Re: [Dovecot] Multiple copies of a message

2008-01-29 Thread Benjamin R. Haskell


On Tue, 29 Jan 2008, Anne Wilson wrote:


I have a problem and I don't know which part of the mail chain could be
causing it, although dovecot does seem to be the most logical source.

I get multiple copies of messages to my Inbox.  I have just deleted 24 copies
of a newsletter from Computer Shopper.  The worst example I have seen of this
had more than 90 copies.  This doesn't happen to any subfolder of Inbox, just
Inbox itself.

The problem started about 10-14 days ago, on the old mail server (running
Mandriva 2007.1).  The new server runs CentOS and exhibits the same problem.

I'd be interested in any comments, as my efforts to track it down have got
nowhere.



Are you using Dovecot's 'deliver' as your LDA (local delivery agent)? 
Otherwise I'd suspect the problem lies in whatever you're using for your 
local deliveries, creating some kind of mail loop. Check your 
.forward/.qmail/.procmail/whatever files. I haven't heard of/seen dovecot 
duplicating messages unless there are actually multiple copies in your 
mailbox.


If your LDA isn't already doing so, add a 'Delivered-To' or 'X-Mail-Loop' 
header at each stage, so you can more easily tell if this is what's 
happening. And then (I assume you've done this, but it should be said) 
look at the headers of the duplicated messages to see if they're 1) 
actually distinct messages [external problem] 2) being delivered multiple 
times


Best,
Ben

Re: [Dovecot] More efficient Deleting of a whole folder (or Purging Trash)


On Wed, 30 Jan 2008, Ed W wrote:





I misunderstood the cause of the slowness then, if it is really true that 
updating the index is not an important factor.  I don't remember seeing 
profiling, but since I don't have any myself I'll take your word for it.




It always frustrates me to see people speculate on stuff instead of getting 
their stop watch out and trying it


Just get a small shell script to run `touch ${rand_file}` 35,000 times and 
time it.  Then drop into your shell and do rm -rf on the folder (for bonus 
marks you could purge the disk cache before doing this).  This gives you a 
benchmark on your hardware separately to what dovecot offers.  Take that 
number and lets work from there...  Shouldn't take too long to do something 
like this?




Since the problem is supposedly file-system specific, you're assuming 
Asheesh uses the XFS file system. And seeing as how he's not the one with 
the original problem, it's also assuming he cares enough to run a test 
like that. Since it was put forth already in the thread that the file 
system is the problem, there's not much incentive to test that hypothesis 
if it involves non-trivial work.


I know I've definitely wasted a lot of time testing out some of the 
various problems that have come up on this list by setting up weird 
dovecot installations. But, not everyone wants to do that for every single 
case.


Plus, in this case, you can just google: xfs delete.

The first result[1] points out the importance of tuning, but the third[2] 
shows exactly what was said on the list: XFS shows very poor delete 
performance on directories full of small files. (Deleting a directory with 
~8000 small files, times in seconds: JFS 3, reiser 1, XFS 30, ext3 2)


[1] http://everything2.com/index.pl?node_id=1479435
[2] http://sidux.com/PNphpBB2-viewtopic-t-5275.html

Best,
Ben

P.S. Rereading this it sounds more confrontational than I'd meant to be. 
No offense intended - just a general: running your own benchmarks isn't 
always worthwhile or necessary, especially when it's not your problem.

Re: [Dovecot] Multiple copies of a message


Apologies.  It seems that I forgot to switch on list management in kmail.
I've re-sent the message, this time to the list.  It should arrive along with
this.



In kmail, are you using disconnected IMAP? A snippet from an email I sent 
to the Alpine (email client) list: (the last two links are the most 
interesting)


I've never seen kmail mentioned in a positive context. Its maildir 
support is broken (doesn't follow the same naming rules as most 
MTAs/MDAs for subfolders. Not a "real" standard, but it is a de facto 
standard), and it eats IMAP mail. At the least, warn your correspondent 
to stay away from kmail's "disconnected IMAP" feature:


[1] http://lists.kde.org/?l=kdepim-users&m=113877863022834&w=2
[2] https://bugs.launchpad.net/kdepim/+bug/61155
[3] https://bugs.kde.org/show_bug.cgi?id=134292
[4] https://bugs.kde.org/show_bug.cgi?id=104956

Re: [Dovecot] Multiple copies of a message


On Wed, 30 Jan 2008, Anne Wilson wrote:

On Tuesday 29 Jan 2008, Asheesh Laroia wrote:

On Tue, 29 Jan 2008, Anne Wilson wrote:

I have a problem and I don't know which part of the mail chain could be
causing it, although dovecot does seem to be the most logical source.

I get multiple copies of messages to my Inbox.  I have just deleted 24
copies of a newsletter from Computer Shopper.  The worst example I have
seen of this had more than 90 copies.  This doesn't happen to any
subfolder of Inbox, just Inbox itself.


Does your SMTP server's logs indicate receiving it multiple times?


I don't have one of the big ones still on my disk, but I have a couple where I
have allowed two copies to remain.  /var/log/maillog shows just one copy of
each of them.


Me, I use a procmail recipe that removes duplicates, so I don't see
duplicate messages if they have the same Message ID.  Also, what do the
headers of these "duplicates" suggest - are they fully identical?.


They are identical until the last lines, which read

X-UID: 2039
X-KMail-Filtered: 65014
Status: RO
X-Status: OC

and

X-UID: 2040
X-KMail-Filtered: 65015
Status: RO
X-Status: OC

Similarly,

X-UID: 2041
X-KMail-Filtered: 65016
Status: RO
X-Status: OAC

and

X-UID: 2042
X-KMail-Filtered: 65017
Status: RO
X-Status: OAC



Have you changed anything recently with your kmail filters? Are you 
running more than one mailserver? Dovecot doesn't add the X-UID field, so 
I suspect it wouldn't be changing it, either.


Best,
Ben

Re: [Dovecot] More efficient Deleting of a whole folder (or Purging Trash)


On Wed, 30 Jan 2008, Gabriel Millerd wrote:


On 1/30/08, Ed W <[EMAIL PROTECTED]> wrote:



Just get a small shell script to run `touch ${rand_file}` 35,000 times
and  time it.  Then drop into your shell and do rm -rf on the folder
(for bonus marks you could purge the disk cache before doing this).
This gives you a benchmark on your hardware separately to what dovecot
offers.  Take that number and lets work from there...  Shouldn't take
too long to do something like this?



Plus indexing work (or quota ... ewww), I wouldn't know if Dovecot
updates and index after every action or what have you. I think Unix
picks up most of the resource juggle here

Off topic, in the end Dovecot is insanely fast, especially with the
LDA to write to indexes on the delivery side and using the custom file
name hints for pop3 and what have you. If the index is not known and
imap is out of the blue told to Examine() and Delete(...) and
Expunge() there might be a significant difference.

Making a perl script to insert 35k emails using dovecot deliver
doesn't impact my under resourced machines and I work with
spam/(false|ham|queue) system with mail::imapclient automation and the
script flies through thousands of messages on the hour without notice.



Did you then delete those 35K messages in one fell swoop? I wouldn't be 
surprised if XFS's performance were significantly different between 
these exaggerrated extremes:


repeat 35000 times: { create a file, delete a file }

and

create 35000 files, delete 35000 files

Best,
Ben

Re: [Dovecot] More efficient Deleting of a whole folder (or Purging Trash)


On Wed, 30 Jan 2008, Benjamin R. Haskell wrote:


On Wed, 30 Jan 2008, Gabriel Millerd wrote:


Making a perl script to insert 35k emails using dovecot deliver
doesn't impact my under resourced machines and I work with
spam/(false|ham|queue) system with mail::imapclient automation and the
script flies through thousands of messages on the hour without notice.



Did you then delete those 35K messages in one fell swoop? I wouldn't be 
surprised if XFS's performance were significantly different between these 
exaggerrated extremes:


repeat 35000 times: { create a file, delete a file }

and

create 35000 files, delete 35000 files

Best,
Ben



Forgot to ask: Are you using XFS?

Re: [Dovecot] Predicament

2008-02-05 Thread Benjamin R. Haskell


On Tue, 5 Feb 2008, Evaggelos Balaskas wrote:


use sieve Action redirect

http://www.ietf.org/rfc/rfc3028.txt
Paragraph : 4.3



More directly: http://tools.ietf.org/html/rfc3028#section-4.3

Plus it lets you know in the header that it's been "obsoleted by RFC 
5228". The relevant section of the new RFC:


http://tools.ietf.org/html/rfc5228#section-4.2

Best,
Ben


Fred Newtz wrote:
| I have a little problem on my hands.  I followed the following how to and
| made plenty of changes.
|
|
http://www.howtoforge.com/postfix_mysql_dovecot_dspam_clamav_postgrey_rbl_de
| bian_etch
|
| However my basic setup is this:
|
| Mail comes in via Postfix incoming mail server only.  Sends it to a DSPAM
| machine who checks the mail for spam and the uses Dovecot to deliver the
| email.
|
| My problem is this:
|
| I have users setup with forwards in my MySQL database.  So dovecot
tries to
| deliver mail (such as to my blackberry) and it fails.  What is the proper
| way for me to forward this mail outside of the local mailbox?
|
| Should I use .forward files in the mailboxes themselves instead?
|
| Thanks,
|
| Fred

Evaggelos Balaskas - http://ebalaskas.gr
Unix System Engineer
Informatics Engineer Technological Education
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqKhQWIK+Pe9twhoRAhhoAJwNfH+GvLA97pw+rRb7qS3p3VMwEgCeOM8r
Ie7v3eol+7moiprUwIpuEM8=
=CDGX
-END PGP SIGNATURE-

Re: [Dovecot] replacement for IMAP_EMPTYTRASH=Trash:7

2008-02-08 Thread Benjamin R. Haskell


On Fri, 8 Feb 2008, Ed W wrote:


Hi

Therefore, i wrote a script that dives into the user's directories and 
their maildirs. It looks like this


Just for reference I actually read the find manual one evening and figured 
out the syntax (wahey!), then 10 mins later had forgotten it all again...


However, in the intervening mins I wrote this little script (watch out for 
line breaks, find command should all be on one line).  The -ls just means 
that I can see it working and for debugging it means that at least you can 
spot if it's gone off the rails... Remove the -ls and stick it in cron when 
you are happy (obviously fix the start dir in this script though)


#!/bin/bash
find .  \( -wholename "*/.Spam/cur/*" -type f -mtime +7 -delete -ls \) , \( 
-wholename "*/.Spam/new/*" -type f -mtime +7 -delete -ls \) , \( -wholename 
"*/.Trash/cur/*" -type f -delete -ls \) , \( -wholename "*/.Trash/new/*" 
-type f -delete -ls \)


I think the issue with mtime is that it gets reset when users open a folder 
and mail moves from /new to /cur ?


Incidently here is a recipe to clean up large Sent Items folders... Use with 
caution...  It demonstrates finding files based on size, date and also 
excluding one folder from being pruned...


find . \( -wholename "*/.Sent\ Items/cur/*" \! -wholename 
"*/exclude_this_user/*" -type f -mtime +30 -size +5M  -ls -delete \) , \( 
-wholename "*/.Sent\ Items/new/*" \! -wholename "*/exclude_this_user/*" -type 
f -mtime +30 -size +5M  -ls -delete \)




For what it's worth, here's the cron script I run nightly: (No capital 
'o's, they're zeros. That's to deal with spaces in filenames.)


# go through all users' Maildirs and delete deleted messages
#   (*:?,*T*) - T is for Trash (Maildir flag)
# that are at least 30 days old

getent passwd | cut -d: -f6 | sort | uniq \
| perl -l0nwe '$_.="/Maildir"; print if -d' \
| xargs -0 -iI find I -type d -name cur -print0 \
| xargs -0 -iI find I -type f -name '*:?,*T*' -mtime +30 -delete

# delete all messages in Spam/Junk folders that are at least 14 days old
# (Note: doesn't look in '/new' -- procmail drops things directly to '/cur')

getent passwd | cut -d: -f6 | sort | uniq \
| perl -l0nwe '$_.="/Maildir"; print if -d' \
| xargs -0 -iI find I -type d \( -name '.Spam*' -o -name '.Junk*' \) -print0 \
| xargs -0 -iI find I -type d -name cur -print0 \
| xargs -0 -iI find I -type f -mtime +14 -delete


Best,
Ben

Re: [Dovecot] Expected size of index-files?

2008-02-08 Thread Benjamin R. Haskell


Tobias Balle-Petersen schreef:

Hello...

Im considering moving my index-files to a RAID1. How big do these
files get? What should I plan for?

Thanks,
Tobias


since 1 july 2007 i store all mails to this list in 1 folder
(Maildir-format)

the size of this (and the indexes) is:
31M cur
80K dovecot.index
6.8Mdovecot.index.cache
44K dovecot.index.log
136Kdovecot.index.log.2
4.0Kdovecot-keywords
164Kdovecot-uidlist
4.0Knew
4.0Ktmp

so, on average maybe 20%-30%  of the size of your messages ?




On Fri, 8 Feb 2008, Jan van den Berg wrote:


That's actually quite a lot.
Consider you run 100k+ mailboxes (1GB each) and you would move to
Dovecot this will be a huge chunk out of your storage.
Is using dovecot index files really that much faster than running
":INDEX=MEMORY" ? Where could I find some benchmarks about this?

Cheers,

Jan



I think a lot would depend on your average message size. Here's another 
data point. At my old company's server:


43,438 messages
2,350,260,769 bytes
per-message ~ 54K

~3,000 folders:
486 dovecot-keywords
   2675 dovecot-uidlist
   2967 dovecot.index
   2456 dovecot.index.cache
   2967 dovecot.index.log
183 dovecot.index.log.2
251 maildirfolder
 26 subscriptions

total non-message file sizes:
 93,010,227 bytes
/ 2,350,260,769 bytes
=~ 3.9 percent


And, taking into account what Timo wrote about it being client-dependent, 
most of the users there are using Outlook.


Best,
Ben

Re: [Dovecot] mailbox not acceced

2008-02-11 Thread Benjamin R. Haskell


On Mon, 11 Feb 2008, Osvaldo Alvarez Pozo wrote:


Hi
did another test if I run from the console
mysql postfix -e "update mailbox set last_log = now() WHERE username
= '[EMAIL PROTECTED]'"
the field last_log gets updated.
but no way to make it work from /etc/dovecot.dovecot.conf



Sounds like a permissions problem. Put something like the following in a 
file readable only by root, which is what the PostLogin script runs as 
unless you've configured it to drop privileges before it runs:


$ cat foo.mysql
# MySQL connection data
[client]
user=someone
password=whatever

Then, change the line to:

mysql --defaults-file=foo.mysql postfix -e "update ..."



I also think that $USER is the variable you want, not $UID. UID = user ID, 
which is usually numeric. But, dovecot sets USER to something useful 
(IIRC, it depends on what variables you use elsewhere in your config as to 
whether it includes the domain.).


Best,
Ben

Re: [Dovecot] mailbox not acceced

2008-02-11 Thread Benjamin R. Haskell


On Mon, 11 Feb 2008, Osvaldo Alvarez Pozo wrote:


i changed permissions, but  no results


Are you sure the connection is opened correctly? If I were debugging this 
on my machine I'd:


1) Add something to check that the MySQL connection is fine:

mysql postfix -e "select now()" > /root/dovecot-debug

2) and that USER contains what you think it contains:

echo $USER >> /root/dovecot-debug

[ 3) or more generally: ]

env | sort >> /root/dovecot-debug



[... cron jobs ...]

This solution is far from being efficient.The precition is 24 hours
wich is ok for know. I would really love doing this from dovecot. I am
disapointed for not being able to make it work from dovecot.
I use debian Etch & dovecot was compiled by hand, is that important?



It shouldn't be, no. This still seems more like a MySQL problem than 
something specific to Dovecot.


Best,
Ben

Re: [Dovecot] mailbox not acceced

2008-02-11 Thread Benjamin R. Haskell


On Mon, 11 Feb 2008, Hugo Monteiro wrote:


Osvaldo Alvarez Pozo wrote:

Hi
I wonder how can I know if a mailbox is not beeing consulted. I mean I
have severals mailboxs but I know some account are not used. I like to
know how to determine wich mail accounts are not beeing used. Is there
any way in dovecot to know the las  time a user loged in to dovecot?

Thanks




I'm using dovecot's ability to use "pre execution" scripts.

Basically i have in my imap protocol definition in dovecot.conf an alternate 
mail_executable


protocol imap {
...
mail_executable = /usr/local/bin/imap-wrapper.sh
...
}

And that executable has the following:

 snip 
#!/bin/sh

# Filesystem based timestamp in user's home directory and protocol used
echo imap > /var/spool/lastlogin/$UID

# Finally execute the imap/pop3 binary. If you use both, you'll need two 
scripts.

exec /usr/lib/dovecot/imap
 snip 


I echo the protocol into the file because i have both pop and imap available 
to my users and this way i can keep track when was the last time they 
accessed their mailbox (ls -l /var/spool/lastlogin/username) and which 
protocol they used in that access (cat /var/spool/lastlogin/username).



There are inumerous possibilities of course.



For a summary of recent-past emails about this, see: 
http://dovecot.org/list/dovecot/2007-November/027148.html


To make the script in this email work for both POP3 and IMAP:

$ cat /root/dovecot-login.sh
#!/bin/sh
PROTO=`basename $0`
echo $PROTO > /var/spool/lastlogin/$UID
exec /usr/libexec/dovecot/$PROTO

$ ln -s /root/dovecot-login.sh /root/imap
$ ln -s /root/dovecot-login.sh /root/pop3

In dovecot.conf:

protocol imap {
...
mail_executable = /root/imap
...
}

protocol pop3 {
...
mail_executable = /root/pop3
...
}


Best,
Ben

Re: [Dovecot] Deleting messages from MailDir

2008-02-12 Thread Benjamin R. Haskell


On Tue, 12 Feb 2008, Rody wrote:



Funny, I asked a few days ago a similar question with the subject:
[Dovecot] replacement for IMAP_EMPTYTRASH=Trash:7
You may want to look for the responses to that question as it's essentially
the same.


For reference:
http://dovecot.org/list/dovecot/2008-February/028626.html

Best,
Ben

Re: [Dovecot] Deleting messages from MailDir

2008-02-12 Thread Benjamin R. Haskell


On Wed, 13 Feb 2008, Rody wrote:

Op woensdag 13 februari 2008 00:43, schreef Bill Cole:

Yes, but you may also care that ctime is reset when a client has
Dovecot move a message from one subfolder to another within a
Maildir. I'm not sure why Dovecot does it, but a look at the messages
in the non-INBOX parts of my Maildir reveals that the ctime is always
later than the mtime, and the contents (Received headers) makes it
clear that Dovecot sets the mtime of messages to the original mtime
(i.e. original delivery time) when copying them.



I think the answer to "why Dovecot does it" is actually that Dovecot 
doesn't do anything with ctime. Under most *nix filesystems, ctime is the 
last time the inode underlying the file/dir was changed ('c' for 
"changed", not "created" -- [usually]). The inode gets changed when the 
file's moved from one directory to another.




Hopefully Timo will speak up on this, but I have a vague recollection
of him saying that Dovecot never modifies message contents as a
matter of principle, and it seems to me that the design of Maildir
assumes that the mailstore server follows that principle rigorously.
That should make mtime quite static for an individual file, and it
looks to me like Dovecot even makes an effort to preserve the
delivery time of a message by replicating the mtime from the original
file to the new one when copying a message between subfolders.


The delivery time can also be determined by the first part of the Maildir 
filename of the message:


e.g. ls -l 1202878863.24522_1.myhost:2,
--rw--- 1 user group 551 2008-02-13 00:00 1202878863.24522_1.myhost:2,

The 1202878863 part is the Unix timestamp corresponding to midnight, Feb 
13, 2008 EST. So, it's not really a requirement of Maildir's design to 
keep the mtime updated. It's just easier+quicker than parsing the number 
out of the filename (where it *is* a requirement).



[...] It looks like the use of ctime or mtime depends on wether you want 
the message removed x days after it was moved to say the trash folder 
(ctime) or will be removed x days after it originally arrived in the 
inbox (mtime). My personal opinion is currently that i would like it 
removed x days after it was placed in a certain folder, hence i use 
ctime.


Depends on the context for me. If it's in a spam folder, I'd rather not 
keep it around any longer than it'd take for someone to say "Hey, didn't 
you get that?". So -mtime +13 (2 weeks from receipt). (Thanks for the 
heads-up on +13 vs. +14, btw).


Trash on the other hand, seems like you'd want X to be "about a month" in: 
"Oh, no! I accidentally deleted that thing X ago!", since messages tend to 
stick around for a while in the INBOX. (Note the difference: "Oh, no! I 
accidentally deleted that thing that *arrived* X ago!".) So, -ctime +30 
(trashed more than a month ago).


Another consideration for ctime is that changing a message's flags 
(/keywords) alters its ctime (since the underlying operation is a rename, 
which alters the inode). (Not sure where that might come into play in the 
spam/trash examples, but it might be good to know.)


Best,
Ben

Re: [Dovecot] convert-tool, exit code wrong?

2008-02-12 Thread Benjamin R. Haskell


On Tue, 12 Feb 2008, Ingo Rogalsky wrote:


I use convert-tool regularly for converting mbox based mail accounts to
maildir based mail accounts. Today I tuned my convert script around
convert-tool. I'm irritated about the exit codes. It seems, they should
be inverted or am I wrong?



Yes. They're inverted. In program return codes, 0 = true/no-error, 
anything else = false/error.


Best,
Ben

Re: [Dovecot] Deleting messages from MailDir

2008-02-13 Thread Benjamin R. Haskell


On Wed, 13 Feb 2008, mouss wrote:


Bill Cole wrote:
At 12:21 AM -0500 2/13/08, Benjamin R. Haskell  imposed structure on a 
stream of electrons, yielding:


[...] Under most *nix filesystems, ctime is the last time the inode 
underlying the file/dir was changed ('c' for "changed", not "created" 
-- [usually]). The inode gets changed when the file's moved from one 
directory to another.




Not on all filesystems. Note what HFS+ (MacOS) does:

~ $ ls -lc foo
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foo
~ $ mkdir foodir
~ $ mv foo foodir
~ $ ls -lc foodir/foo
-rwxr-xr-x   1 wkc  wkc  332 Jan 29 03:32 foodir/foo
~ $ date
Wed Feb 13 08:39:24 EST 2008



The question is whether this is because of an fs limitation or is it for 
compatibility with some old tools.


Posix says:

Upon successful completion, /rename/() shall mark for update the /st_ctime/ 
and /st_mtime/ fields of the parent directory of each file.




We haven't seen the ctime or mtime of the parent directory. Just of the 
file.



and ctime is the last status change time. AFAICT, an mv is certainly a status 
change.



but maybe I disgress:)

Re: [Dovecot] Deleting messages from MailDir

2008-02-13 Thread Benjamin R. Haskell


On Wed, 13 Feb 2008, Bill Cole wrote:


At 12:21 AM -0500 2/13/08, Benjamin R. Haskell  imposed structure on a stream 
of electrons, yielding:

On Wed, 13 Feb 2008, Rody wrote:

Op woensdag 13 februari 2008 00:43, schreef Bill Cole:

Yes, but you may also care that ctime is reset when a client has
Dovecot move a message from one subfolder to another within a
Maildir. I'm not sure why Dovecot does it, but a look at the messages
in the non-INBOX parts of my Maildir reveals that the ctime is always
later than the mtime, and the contents (Received headers) makes it
clear that Dovecot sets the mtime of messages to the original mtime
(i.e. original delivery time) when copying them.



I think the answer to "why Dovecot does it" is actually that Dovecot 
doesn't do anything with ctime. Under most *nix filesystems, ctime is 
the last time the inode underlying the file/dir was changed ('c' for 
"changed", not "created" -- [usually]). The inode gets changed when the 
file's moved from one directory to another.


Not on all filesystems. Note what HFS+ (MacOS) does:

[example of ctime not being updated]


Hence my qualifying it as "Under most *nix filesystems". But, good to know 
there's a commonly-used exception.




Hopefully Timo will speak up on this, but I have a vague recollection
of him saying that Dovecot never modifies message contents as a
matter of principle, and it seems to me that the design of Maildir
assumes that the mailstore server follows that principle rigorously.
That should make mtime quite static for an individual file, and it
looks to me like Dovecot even makes an effort to preserve the
delivery time of a message by replicating the mtime from the original
file to the new one when copying a message between subfolders.


The delivery time can also be determined by the first part of the 
Maildir filename of the message:


e.g. ls -l 1202878863.24522_1.myhost:2,
--rw--- 1 user group 551 2008-02-13 00:00 1202878863.24522_1.myhost:2,

The 1202878863 part is the Unix timestamp corresponding to midnight, 
Feb 13, 2008 EST. So, it's not really a requirement of Maildir's design 
to keep the mtime updated. It's just easier+quicker than parsing the 
number out of the filename (where it *is* a requirement).


Maildir DOES NOT require a timestamp in the filename, it's just common.



DJB's Maildir spec isn't RFC-esque (so it's not a MUST, in that sense). As 
far as I've seen, everything does what's described below. But, like you 
say, not a requirement. I think I skipped over the second and third 
sentences from this excerpt from http://cr.yp.to/proto/maildir.html 
(because of the first sentence) :


[""
Unless you're writing messages to a maildir, the format of a unique name 
is none of your business. A unique name can be anything that doesn't 
contain a colon (or slash) and doesn't start with a dot. Do not try to 
extract information from unique names.


Okay, so you're writing messages. A unique name has three pieces, 
separated by dots. On the left is the result of time() or the second 
counter from gettimeofday().

""]

Also note that that snippet expressly warns against doing what I said 
could be done (parsing the timestamp out of the filename).


I'm curious: do you have examples of mail software that doesn't use the 
timestamp? (I could see some run-once script not doing it, but I'd be 
surprised if widely-used software didn't.)





On my system, the timestamps in the filenames match the ctime, NOT the
mtime:

~/Maildir/.Tagged/cur $ ls -lcrt |tail -1
-rw---   1 wkc  staff13293 Feb 12 23:45 
1202877918.P26840Q0M183345.toaster.scconsult.com:2,S
~/Maildir/.Tagged/cur $ ls -l 
1202877918.P26840Q0M183345.toaster.scconsult.com\:2\,S
-rw---   1 wkc  staff  13293 Feb 12 23:43 
1202877918.P26840Q0M183345.toaster.scconsult.com:2,S
~/Maildir/.Tagged/cur wkc$ uepoch 1202877918
1202877918 is Tue Feb 12 23:45:18 2008

The earlier mtime matches the delivery time.



I think it'd generally be the case that the filename timestamp will match 
the *initial* ctime (before any possible ctime changes), since that should 
be synonymous with creation time. And, mtime could vary, because Dovecot 
syncs the mtime to the delivery time.


But, I still don't quite follow your example. Call the mailfile X (so I 
don't have to type it):


ls -lc X shows 23:45 - so, ctime = 23:45
ls -l X shows 23:43 - so, mtime = 23:43
And, the filename timestamp == ctime.

But, you say the mtime matches the delivery time. So, the filename 
timestamp is two minutes *after* the delivery time? Did it take your LDA 
two minutes (or at least 1 min 19sec) to get the message from the MTA to 
the Maildir?


Also, I think (but, maybe not on HFS+) there'd be a ctime change on 
renaming the file from X to X,S (adding the 'Seen' flag).

Re: [Dovecot] stat failed: Not a directory

2008-02-17 Thread Benjamin R. Haskell


On Sun, 17 Feb 2008, Andrea wrote:


I have recently installed dovecot on a FreeBSD mailserver running postfix.
But when I try to login with imap/pop3, I always get an error "stat failed:
Not a directory".
I guess it is something wrong with the mail format postfix uses to store the
message, but I don't seem to find the correct solution.



Take a look at http://wiki.dovecot.org/MailboxFormat

The error you're getting is usually caused by treating an mbox (or similar 
format) file as a Maildir.


So, something in the path:

/usr/local/virtual/internal.domain.com/andrea

is not a directory. (Probably the whole thing -- andrea is probably a 
file.) So, when stat adds '/cur' to that path (which it needs to do if 
andrea is a Maildir), you get the 'not a directory' error.


I don't recall whether Postfix supports Maildir natively (Maildir is 
generally a better format than mbox -- by most accounts). On the server 
where I used it, we just delivered via Procmail (which does support 
Maildir).


Best,
Ben

Re: [Dovecot] Scheduled folder purging

2008-02-18 Thread Benjamin R. Haskell


On Mon, 18 Feb 2008, Charles Marcus wrote:


Marc Perkel, on 2/18/2008 11:28 AM, said the following:
I'm looking for a way to empty user's trash folder. Can message 
deletion or folder purging be scheduled?


It would be a nice feature in Dovecot to have it be able to remove 
messages older than say 3 days from Trash automatically.


V 1.1 already can (see Expire plug-in), but I'm not sure if this only 
happens at use3r log in or not...


http://wiki.dovecot.org/Plugins/Expire



Said I: (in the thread "Deleting messages from MailDir")

Does the expunge plugin work without the user logging in, though?


Timo responded:
Yes. That's exactly what it does. It keeps user/mailbox <-> oldest_msg 
mapping in a Berkeley DB. In a nightly (or whatever) run it then uses 
the database to open only those mailboxes that have messages to be 
expunged.


Best,
Ben

Re: [Dovecot] Duplicate Messages, Different X-UIDs?

2008-02-18 Thread Benjamin R. Haskell


On Mon, 18 Feb 2008, Joe Allesi -X (joallesi - Coyote Creek Consulting at 
Cisco) wrote:



We're running into an issue where sendmail is only receiving one e-mail, 
but after a client accesses the message via IMAP and moves it to another 
IMAP folder, the message duplicates but each message has different X-UID 
headers. Has anyone ever seen this type of anomaly before? Is it a bad 
IMAP client, or a known bug?


Running 1.0.7

Thanks!



I've seen that happen with Kmail. Tell the client to run far away from 
Kmail if that's the case. (Or at least stay away from dIMAP = disconnected 
IMAP.) Otherwise, don't know. Do you know what client it is?


Best,
Ben

Re: [Dovecot] sieve filtert nicht (off-topic)

2008-02-21 Thread Benjamin R. Haskell


On Thu, 21 Feb 2008, Steffen Kaiser wrote:


On Tue, 19 Feb 2008, Carsten Henkel wrote:


and you need to understand what i´m wrote *gg


Why should Patrick bother to understand _your_ request of support, do 
you pay him?!




Not really pertinent to dovecot, but for future reference:

Doesn't the '*gg' indicate joking? I took it to mean "grinning" (but 
maybe I'm pulling that out of nothing).


Best,
Ben

Re: [Dovecot] shared mailbox - namespace

2008-02-22 Thread Benjamin R. Haskell


On Fri, 22 Feb 2008, c-schettner wrote:


Hi all,
this is my last try to get help before giving up. I red the dovecot-wiki 
several times, but it doesn´t work. I don´t know what´s wrong. If I open 
thunderbird I see the folder "public" but I cannot subscribe it. I have 
dovecot 1.0.10. Yes it´s a little bit old but it is the latest version 
under debian packages. Please see my configuration below.


You cannot subscribe to the root folder of a namespace. I'm not entirely 
sure *why* this is the case (it seems to be generally desired, and it's a 
common source of confusion), but it's the way Dovecot's set up (Someone 
correct me if that's wrong in the 1.1 series).


You should be able to subscribe to any subfolders, though. e.g. based on 
the permissions in your example:


mkdir -p /home/vmail/public/.folder/{new,tmp,cur}
touch /home/vmail/public/.folder/dovecot-shared
chown -R vmail:vmail /home/vmail/public/.folder
find /home/vmail/public/.folder -type d -exec chmod 700 '{}' \;
chmod 644 /home/vmail/public/.folder/dovecot-shared

Then you should be able to subscribe to public/folder

I'm not sure how ACL's play into this. The lack of hierarchical ACL's 
prevented them from being useful for my situation, but I had the benefit 
of system users (so I could put them in groups and control access that 
way).


Best,
Ben



here the content of: /etc/dovecot-acl/public

[EMAIL PROTECTED] rwl


here my /home/vmail
--
mail:/home/vmail# ls -l
insgesamt 32
drwx-- 6 vmail vmail 4096 2008-02-22 09:43 domain1.de
drwx-- 4 vmail vmail 4096 2008-02-15 16:56 domain2.de
-rw--- 1 vmail vmail 7762 2008-02-22 13:37 dovecot-deliver.log
-rw-r--r-- 1 root root 160 2008-02-22 09:40 globalsieverc
-rw--- 1 vmail vmail 204 2008-02-22 09:40 globalsievercc
drwx-- 5 vmail vmail 4096 2008-02-22 13:16 public
drwx-- 3 vmail vmail 4096 2008-02-18 09:08 web.de
---


here a part of my dovecot.conf:

-
mail_location = maildir:/home/vmail/%d/%n

namespace public {
separator = /
prefix = public/
location = maildir:/home/vmail/public
hidden = no
}

namespace private {
separator = /
prefix =
inbox = yes
}

mail_extra_groups = mail
#umask = 0077

protocol imap {

mail_plugins = acl
}

plugin {
#quota = maildir
acl = vfile:/etc/dovecot-acls
#trash = /etc/dovecot-trash.conf
}


here the shared folder:


mail:/home/vmail/public# ls -l
insgesamt 12
drwx-- 2 vmail vmail 4096 2008-02-22 12:14 cur
-rw-r--r-- 1 vmail vmail 0 2008-02-22 13:16 dovecot-shared
drwx-- 2 vmail vmail 4096 2008-02-22 12:14 new
drwx-- 2 vmail vmail 4096 2008-02-22 12:14 tmp
mail:/home/vmail/public#
-


Thanks,
Christian.

Re: [Dovecot] mbox to maildir conversion does not work

2008-02-22 Thread Benjamin R. Haskell


On Fri, 22 Feb 2008, Scott Bruce wrote:


Hello,

I'm try to use the convert plugin, but I cannot seem to get it working 
properly. Is there any setting that I'm missing.


In what way is it not working? Based on the timestamps in your log, it 
looks like you're getting disconnected as soon as you log in. But, does 
Dovecot work for you without the convert plugin?


It also seems a little odd that you're using the plugin under POP3, rather 
than IMAP (it's not listed in mail_plugins(imap)), given POP3's limited 
concept of "mailboxes"/directories/etc. But, I don't know that that's 
problematic.


Best,
Ben




dovecot -n
# 1.0.10: dovecot.conf
log_path: /var/log/dovecot
protocols: imap imaps pop3 pop3s
listen(default): 127.0.0.1:143
listen(imap): 127.0.0.1:143
listen(pop3): *:110
ssl_listen(default): *:993
ssl_listen(imap): *:993
ssl_listen(pop3): *:995
login_dir: /opt/csw/var/run/dovecot/login
login_executable(default): /opt/csw/libexec/dovecot/imap-login
login_executable(imap): /opt/csw/libexec/dovecot/imap-login
login_executable(pop3): /opt/csw/libexec/dovecot/pop3-login
mail_location: maildir:/var/imap/%u/.imap
mail_debug: yes
maildir_copy_with_hardlinks: yes
mail_executable(default): /opt/csw/libexec/dovecot/imap
mail_executable(imap): /opt/csw/libexec/dovecot/imap
mail_executable(pop3): /opt/csw/libexec/dovecot/pop3
mail_plugins(default):
mail_plugins(imap):
mail_plugins(pop3): convert
mail_plugin_dir(default): /opt/csw/lib/dovecot/imap
mail_plugin_dir(imap): /opt/csw/lib/dovecot/imap
mail_plugin_dir(pop3): /opt/csw/lib/dovecot/pop3
pop3_reuse_xuidl(default): no
pop3_reuse_xuidl(imap): no
pop3_reuse_xuidl(pop3): yes
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xu%08Xv
auth default:
 passdb:
   driver: pam
 userdb:
   driver: passwd
plugin:
 convert_skip_broken_mailboxes: no
 convert_mail: mbox:INBOX=/var/mail/%u

Dovecot log

dovecot: Feb 22 14:13:28 Info: pop3-login: Login: user=, method=PLAIN, 
rip=134.117.43.54, lip=134.117.9.47, TLS
dovecot: Feb 22 14:13:28 Info: POP3(scott): Loading modules from directory: 
/opt/csw/lib/dovecot/pop3
dovecot: Feb 22 14:13:28 Info: POP3(scott): Module loaded: 
/opt/csw/lib/dovecot/pop3/lib20_convert_plugin.so

dovecot: Feb 22 14:13:28 Info: POP3(scott): Effective uid=xxx, gid=xx
dovecot: Feb 22 14:13:28 Info: POP3(scott): mbox: data=INBOX=/var/mail/scott
dovecot: Feb 22 14:13:28 Info: POP3(scott): maildir: 
data=/var/imap/scott/.imap
dovecot: Feb 22 14:13:28 Info: POP3(scott): maildir: 
root=/var/imap/scott/.imap, index=/var/imap/scott/.imap, control=, inbox=
dovecot: Feb 22 14:13:28 Info: POP3(scott): Disconnected: Logged out top=0/0, 
retr=0/0, del=0/0, size=0

bash-3.00# du -sh /var/imap/sbruce/.imap/

And I can use mb2md to do the conversion, but I was hoping to do it on the 
fly.


Thank You for your time,
Scott


--
dovecot --version
1.0.10

Re: [Dovecot] Sorting a folder (by THREAD) takes a long time

2008-03-06 Thread Benjamin R. Haskell


On Thu, 6 Mar 2008, Asheesh Laroia wrote:

My email workflow with Dovecot is that mail gets delivered to INBOX, 
where I handle it and then move it into a folder called archive.


I have alpine set to use the Default sort of "THREAD" of a folder. 
After moving a (few) mail(s) from INBOX to archive, archive takes a long 
time (10-50s) to load while alpine tells me:


[Sorting "archive"  ... ]

(I can do the IMAP traces, but I figure alpine's terminology is going to 
be so similar to IMAP terminology that it should be straightforward 
enough for Timo to know what I'm talking about.)


I'd do the traces if I were you. Maybe it's something to do with "Thread 
Sorts By Arrival" or similar Alpine threading quirks. There was also 
traffic a couple months ago about threading scaling non-linearly in Alpine 
depending on that setting. I assume you're running a recent snapshot, but 
I don't recall whether that issue was resolved.


Best,
Ben

Re: [Dovecot] Help! OT: Blackberry IMAP client suggestions/experience needed

2008-03-13 Thread Benjamin R. Haskell


Stewart Dean wrote:

BB, of course, has their half-baked sorta-IMAP-compliant client (and we do NOT
want the BB Enterprise Server) that persistently keeps grabbing the mailbox and
breaking the mailbox lock, causing no end of grief for the secretaries (plural,
more than one) would also work with the mailbox.


Any particular reason you're tied to mbox other than having migrated from 
UW-IMAP? I suspect maildir, though not as lock-free as advertised, would 
have a much better time of things. (i.e. it's far better suited for 
multiple-client access.)



Knute Johnson wrote:

My wife has a Blackberry Curve, 8310 (ATT version).  I'm running my
mailserver on Fedora 8 and the Dovecot is version dovecot-1.0.10-
4.fc8.  She is using the built-in IMAP client with SSL and it works
just fine.


Guessing you're not using mbox, for starters. But, it also sounds like 
she's the only one accessing the mailbox?


Best,
Ben

Re: [Dovecot] Help! OT: Blackberry IMAP client suggestions/experience needed

2008-03-13 Thread Benjamin R. Haskell


On Thu, 13 Mar 2008, Stewart Dean wrote:

Plus I have to wonder what the realities of moving from 1) mbox with one 
monster file to 2) maildir with inodes beyond measure and its effect on 
backup.


With reasonable average email usage patterns (averaging >=4K/message -- 
not hard to do with the occasional 5-10MB message), you'll run out of disk 
space long before running out of inodes on any reasonable filesystem. And, 
I'd think many tiny files would scale better for backup software. 
(Depending on how 'dumb' the software doing it is, I'd think "minor change 
to one huge file" would be less-efficiently stored than "new tiny file" or 
"deleted tiny file".)




[...]
Remember: when you (the sysadmin) do things really, really right, nobody 
knows you've done anything.  Sounds like a 0 to negative sum game..


Amen to that. Especially when it comes to something like email, where even 
the slightest interruption is intolerable.


But, by the same token, it sounds like your experience with BB+mbox is 
already moving you toward the negative (secretaries already noticed 
something wrong). Might be worth the effort to try it out with the BB 
users.


Best,
Ben

Re: [Dovecot] virtual mbox case sensitive?

2008-05-01 Thread Benjamin R. Haskell


On Thu, 1 May 2008, Anil wrote:


This is on dovecot 1.1.rc4.

I have this mail_location:

mail_location = maildir:/apps/mail/%d/%n/Maildir


When I receve mail to a virtual mailbox, its putting it in different
Maildir's depending on what the sender used for the caseness of the
recipient's email address:

I have these Maildirs:

JasonK  JuliaM  infojasonk  juliam

JasonK and jasonk should be the same maildir. So should JuliaM and juliam.


See the "Modifiers" in the wiki page for Variables.

http://wiki.dovecot.org/Variables#line-41

Sounds like you want to change %n to %Ln. Some MTA's fold case, some 
don't.




Now the 2nd question is, how do I "move" the mail from JasonK back to jasonk?


I'd just 'mv' them:

cd /apps/mail/
for l in cur new tmp ; do
mv domain/JasonK/$l/* domain/jasonk/$l/
done



Thanks, this is very odd!

Re: [Dovecot] FAQ: setting thunderbird to talk to dovecot

2008-05-03 Thread Benjamin R. Haskell


On Sun, 4 May 2008, Timo Sirainen wrote:

On Fri, 2008-05-02 at 17:27 -0400, Mauricio Tavares wrote:

On Fri, May 2, 2008 at 10:46 AM, Ed W <[EMAIL PROTECTED]> wrote:


How would I do the same under thunderbird from a machine in the same 
lan (taz.thespider.com)? It seems to keep trying to login as 
[EMAIL PROTECTED], which will not fly.


 Thunderbird logs in using whatever *string* you type in the username 
box. It doesn't even have to be in the format of an email address...


 It does seem it is appending whatever string I type in the 
username box to the front of the name of the mail server.  So, if I 
have the username as [EMAIL PROTECTED], it will try to login as 
[EMAIL PROTECTED]@mail.thespider.com


How do you determine that it uses such login? From Dovecot's logs? If 
this really is happening, there's something weird going on in your 
Thunderbird. It shouldn't be appending the server name to your login 
name.


Timo and Ed are right. Thunderbird should be using the string exactly as 
you type it in the username field. It looks like a user-interface issue. I 
just setup an account at localhost with the username:


[EMAIL PROTECTED]

When logging in, the dialog box pops up asking for the password for:

[EMAIL PROTECTED]@localhost
(extra @localhost)

but the auth plain string (with password boobar) is:

AGJoYXNrZWxsQGZsaWJiZXJkeWdpYmJldC5leGFtcGxlLmNvbQBib29iYXI=
i.e.: [EMAIL PROTECTED]
(no @localhost)

This is with a relatively old Linux Thunderbird, but still, It's probably 
not actually using the extra domain when logging in.


Best,
Ben

Re: [Dovecot] [Q] IMAP update message header?

2008-05-07 Thread Benjamin R. Haskell


On Wed, 7 May 2008, Roderick A. Anderson wrote:


Charles Marcus wrote:

On 5/7/2008, Roderick A. Anderson ([EMAIL PROTECTED]) wrote:
Is there a method as a client from a remote system to make changes to a 
message then save it back?  What is the IMAP verb, command, etc. to do 
this?


Man, if you could, that would be really, really bad...


Does make sense in the bigger picture but for my needs is would only be 
kind-of bad.  :-)



So hopefully the answer is no, not, never...


Well Timo's answer indicates so.  So now I'm trying to figure out a way to 
get the same effect as marking a message as seen/unseen while honoring 
seen/unseen.


Looks like it will probably be a case of making a copy of the message adding 
the X-Header then copying/savinging it back as a new message and deleting the 
old.


Is there any reason you couldn't just add a flag?

IMAP-wise it's:

label STORE message-id +FLAGS (FlagName)

and

label FETCH message-id FLAGS


e.g. [trimmed a little]

* OK Dovecot ready.
A LOGIN user pass
A OK Logged in.
B SELECT INBOX
* FLAGS (\Answered \Seen [.etc.])
* OK [PERMANENTFLAGS (\Answered \Seen ... \*)] Flags permitted.
* 30129 EXISTS
* 0 RECENT
* OK [UNSEEN 408] First unseen.
* OK [UIDVALIDITY 1202523566] UIDs valid
* OK [UIDNEXT 153176] Predicted next UID
B OK [READ-WRITE] Select completed.
C FETCH 30029 FLAGS
* 30029 FETCH (FLAGS (\Seen))
C OK Fetch completed.
D STORE 30029 +FLAGS (SeenByProcess)
* FLAGS (\Answered \Seen [.etc.] SeenByProcess)
* OK [PERMANENTFLAGS (\Answered \Seen ... SeenByProcess \*)] Flags permitted.
* 30029 FETCH (FLAGS (\Seen SeenByProcess))
D OK Store completed.

Re: [Dovecot] inetd & corrupt environment

2008-05-25 Thread Benjamin R. Haskell


On Sun, 25 May 2008, Gelu G. Lupas wrote:

Hello. I'm having the following problem with dovecot 1.0.12 and above, on a 
FreeBSD 7.0 system - I'm trying to run pop3-login from inetd and I keep 
getting this error after authentication:


May 25 09:46:19 charlie dovecot: POP3(gelu): /libexec/ld-elf.so.1: 
environment corrupt; missing value for no-nuls oe-ns-eoh


The problem persists if I uncomment the lines with no-nuls oe-ns-eoh in 
dovecot.conf. I've also tried running pop3-login from tcpserver/ucspi-tcp and 
I still get the same error.  Version 1.0.1 works fine on a similar setup. 
Please reply if you have any idea regarding a fix for this error. I need to 
run dovecot under a tcp wrapper of some kind (preferably inetd) as the 
standalone daemon doesn't allow any method to restrict access by IP. The 
allow_nets extra field doesn't help much as I'm using PAM and do not want to 
maintain yet another passdb. Restricting access via firewall rules is not an 
option. Until I find a way to restrict access by IP address, dovecot will 
only listen on the private IP address (192.168.100.1).


Dovecot does quite a bit of setup for child processes via environment 
variables. Maybe you could use the standalone server to run a test login, 
see what environment variables get set through a script, and set up an 
envdir (part of daemontools). Then turn off the standalone server.


e.g. (partially tested)

in /root/testing.pl (chmod +x)

#!/usr/bin/perl
$dir = "/root/dovecot-env";
mkdir $dir unless -d $dir;
while (my ($k, $v) = each %ENV) {
open my $f, '>', "$dir/$k" or next;
$v =~ tr/\n/\0/;
print $f "$v\n";
}
exec "/usr/libexec/dovecot/pop3-login";

and, in dovecot.conf:

protocol pop3 {
#...
login_executable=/root/testing.pl


Then, attempt to login.

then, via ucspi-tcp:

instead of tcpserver [options] pop3-login
usetcpserver [options] envdir /root/dovecot-env pop3-login

I don't use inetd, but I'm sure a similar change could be made.


Alternatively, and far easier, would be to do something with a static db 
in dovecot that only has allow_nets={whatever you want}. I'm pretty sure 
you can have portions of user info returned via different mechanisms. (So, 
you'd also specify an auth db of 'PAM'.) If you don't need different 
allow_nets for different users, that'd be pretty simple. [I don't recall 
specifics on how to do this, though, so I might be off base.]


Best,
Ben

Re: [Dovecot] Auto creating client folders on the IMAP server after installing client.

2008-06-09 Thread Benjamin R. Haskell


On Sun, 8 Jun 2008, Radio Tron wrote:


as well. Have you tested whether you can MANUALLY create new folders?


Yup, just tried that out using telnet. It works.


I'm guessing Charles meant manually via TBird. But, the fact that it works 
via telnet probably also points toward it being a TBird configuration 
issue.



[...] I am using port 143 in TBird, but this is a SASL/TLS link? 
Shouldn't the port be 993?


If you have it set to use TLS, it will likely use the STARTTLS command on 
port 143 and then proceed on 993. (Not sure on all the details, but that's 
the gist.)



sync GMail, Dovecot and a multitude-of-stupid-clients in some 
mysterious way so any advice in advance is more than welcome.


Fetchmail?


Well, fetchmail doesn't do a perfect IMAP sync as in, GMail folder/label 
details are lost (I'm researching GetMail/Mutt+Expect). Essentially, the 
client is using GMail-Google-Apps to send and receive emails. He wants a 
copy of all mails sent and received via GMail to be stored elsewhere (so 
that he can verify as to who, among his employees, sent what and 
received what). He isn't using his own mail server because of SPAM and 
because of downtime (I suggested a secondary MX, but it got shot down) 
So I have to keep the GMail passwds on Linux and use that to sync 
between Linux and GMail and then run Dovecot and feed the mail to TBirds 
and implement SSL/TLS everywhere (*sigh* and I'm just a noob at this - 
was hoping they'd let me do some C/Perl)


Just a word of warning, there's a bit of an "impedance mismatch" between 
GMail and IMAP, especially in the area of labels. A message labeled as 
"Foo" and "Bar" via GMail will show up in the [Gmail]/Foo and [Gmail]/Bar 
folders via IMAP. I don't think there's a way for IMAP to mark two 
messages in distinct folders as being identical. So, I'd guess that 'sync' 
software might have trouble. (Especially since GMail users can add/remove 
those labels at will.)


This may have changed, as GMail's IMAP support is a work in progress, but 
just wanted to warn you. (for more, google: gmail buggy IMAP)



Since you didn't post any details of your system or config, all anyone 
could do is guess.


[...]

mail> dovecot --version
1.0.rc15


(To pre-empt Charles:) Upgrade!

Recent threads have mentioned that distro's have kind of "stuck" with 
1.0.rc15, which may be a buggier release than most. Check out atrpms.net 
for a more recent version. It's worth the upgrade.


Best,
Ben

Re: [Dovecot] Auto creating client folders on the IMAP server after installing client.

2008-06-09 Thread Benjamin R. Haskell


On Mon, 9 Jun 2008, Benjamin R. Haskell wrote:

Just a word of warning, there's a bit of an "impedance mismatch" between 
GMail and IMAP, especially in the area of labels. A message labeled as 
"Foo" and "Bar" via GMail will show up in the [Gmail]/Foo and 
[Gmail]/Bar folders via IMAP. I don't think there's a way for IMAP to 
mark two messages in distinct folders as being identical. So, I'd guess 
that 'sync' software might have trouble. (Especially since GMail users 
can add/remove those labels at will.)


This may have changed, as GMail's IMAP support is a work in progress, 
but just wanted to warn you. (for more, google: gmail buggy IMAP)


Another thought: After rereading a bit, I think you might be able to avoid 
this particular problem by only considering the "[Gmail]/All Mail" folder. 
But, there are also oddities around GMail's handling of message deletion.


-- Ben

Re: [Dovecot] Auto creating client folders on the IMAP server after installing client.

2008-06-09 Thread Benjamin R. Haskell


On Mon, 9 Jun 2008, Charles Marcus wrote:


On 6/9/2008, Radio Tron ([EMAIL PROTECTED]) wrote:

I got to sleep see you guys in 10 hours time (if i
survive not killing someone :p)


Why are you messing with editing the config file? You're really making 
this way harder than it needs to be.


I agree with Charles. In particular, I wonder why you're explicitly 
setting all of these subscription-related settings. I've never had to 
touch subscriptions in Thunderbird, which seems to "just work", in stark 
contrast to the way Outlook deals with IMAP folders. (Though, admittedly, 
it may be a function of my not understanding why you'd need subscriptions 
in a typical, per-user mail setup -- I only see their utility if you have 
access to a large, shared hierarchy.)


Best,
Ben

Re: [Dovecot] Need a quick, safe method to empty /home/user/Maildir/{.Junk, .Trash}

2008-06-12 Thread Benjamin R. Haskell


On Thu, 12 Jun 2008, Kyle Wheeler wrote:


On Thursday, June 12 at 01:02 PM, quoth Jeff Kowalczyk:

On Thu, 12 Jun 2008 10:19:48 -0500, Kyle Wheeler wrote:
If you have a *TON* of messages in those folders (i.e. several thousand), 
your shell may complain that there are too many arguments to the rm 
command. If that happens, these may be better commands to delete them:


find /home/user/Maildir/.Junk/cur -type f -delete find 
/home/user/Maildir/.Trash/cur -type f -delete


Thanks, I'm going to do that. And per dmeissler, I'm going to consider 
xargs.


 xargs is good for other things, but if all you're doing is 
deleting files, find can do it itself without involving other 
applications. But whatever makes you comfortable.


Not all 'find's are created equal. I think '-delete' is a GNU extension 
(or a relatively new option). It's not in Solaris 8 (Yeah, I know, it's 
old.), for example.



Any thoughts on a variant using find -name that could safely iterate over 
/home/*/Maildir for all users? Otherwise I would script it in python.


find /home/ -path '*/Maildir/.Junk/cur/*' -type f -delete

~Kyle

Re: [Dovecot] SSL + compression?

2008-06-20 Thread Benjamin R. Haskell


On Fri, 20 Jun 2008, Johannes Berg wrote:



I don't think it does be default. The only what I know is to establish 
a compressed SSH tunnel to your server and then access the server over 
the tunnel. It will compress and give you an extra layer of encryption.


Umm, no. It will not compress. Think about it, encrypted data is 
fundamentally not compressible, that's the whole point.


x = length(compress(encrypt(data)))
y = length(encrypt(compress(data)))
z = length(encrypt(data))

Then, usually, x > y and z > y, but x is approximately the same as z. 
(That's speaking very generally; there may be optimizations in some case 
or another given your data.)


That is: encrypted data is less compressible than the original data, but 
if you compress first, then encrypt, it should be a win.


If I recall correctly, a "compressed SSH tunnel" would do 'y' (compress 
then encrypt). i.e., dovecot would see a non-SSL connection which gets 
compressed-then-encrypted, or decrypted-then-uncompressed by the endpoints 
of the tunnel.


Best,
Ben

Re: [Dovecot] SSL + compression?

2008-06-20 Thread Benjamin R. Haskell


On Fri, 20 Jun 2008, Johannes Berg wrote:




I don't think it does be default. The only what I know is to establish
a compressed SSH tunnel to your server and then access the server over
the tunnel. It will compress and give you an extra layer of encryption.


Umm, no. It will not compress. Think about it, encrypted data is
fundamentally not compressible, that's the whole point.


[...me...]


Well, as far as I understood Marc, since he was saying "an extra layer 
of encryption" I understood him to mean that he wanted to


encrypt(compress(encrypt(imap stream)))

by building an ssh-tunnelled imaps (or imap/tls) connection. IOW, 
dovecot would see an SSL connection too.


Hmm, yes. I took it to mean that the 'encrypt' of

encrypt(compress(imap stream))

was the "extra layer". But, I think your interpretation is more easily 
arrived at, and if it's what Mark meant, you're absolutely right that the 
tunnel won't help.


A compressed SSH tunnel to regular, non-SSL IMAP should work to reduce 
traffic, though.


Best,
Ben

Re: [Dovecot] litte problems upgrade from 1.0.x to 1.1.1

2008-07-03 Thread Benjamin R. Haskell


On Thu, 3 Jul 2008, Andre Huebner wrote:



Hi,


These are created by the University of Washington's implementation of
an IMAP server. Notice the date is nearly 2 years ago. At some point,
it seems your site was running imap-uw.

--
Fred




It's not UW-IMAP (the server). It's PINE or Alpine (the client). Those are 
usually found in on-disk mbox files that have been created by PINE/Alpine. 
The message is ignored by PINE/Alpine (obviously), but when you switch to 
a different mailer, it doesn't know to ignore it (and shouldn't be 
expected to). AFAIK, the only solution is to delete the messages.


Best,
Ben

[Dovecot] Shared folder hierarchies, multiple groups

2007-08-02 Thread Benjamin R. Haskell


Hi,

I'm trying to set up two shared folder hierarchies on my Dovecot 
installation for two groups of employees, all of whom should only have 
access to their own hierarchy. Any employee should be able to create 
sub-folders and generally have full access to the hierarchy.


My initial setup was to create two public namespaces, Shared-One and 
Shared-Two. Each is a Maildir under /var/mail.


The actual shared folders seem to be working fine in terms of adding and 
accessing folders and messages, and there are no problems at all for the 
'admin' user, who belongs to both the shared1 and shared2 Unix groups.


The problem is for other users, where trying to (IMAP-) LIST folders 
fails.


(sanitized) IMAP session log: ('user2' is in group shared2)
* OK Dovecot ready.
A LOGIN user2 pass
A OK Logged in.
B LIST "" "%"
* LIST (\Noselect \HasChildren) "/" "Shared-One"
B NO Internal error occurred. Refer to server log for more information. 
[2007-08-02 09:01:23]

In the mail logs I find:
dovecot: IMAP(user2): stat(/var/mail/Shared-One/cur) failed: Permission denied

Relevant permissions:
2770/drwxrws--- shared1 shared1 /var/mail/Shared-One
2770/drwxrws--- shared1 shared1 /var/mail/Shared-One/cur
0660/-rw-rw shared1 shared1 /var/mail/Shared-One/dovecot-shared

And similarly for Shared-Two. (replace shared1 with shared2 everywhere)

Among other things, I've read:
http://wiki.dovecot.org/SharedMailboxes
http://wiki.dovecot.org/ACL
http://wiki.dovecot.org/MainConfig
http://wiki.dovecot.org/Namespaces

I don't want to use vfile ACL's (I think) because I want users to be 
able to create subfolders at will, and I don't want to have to add a 
dovecot-acl file per-folder. (Is there a way to set global defaults on a 
global basis? [not per-folder]) I also think there would be a problem with 
the hierarchies being similar. (e.g. both have a 'Projects' sub-folder, 
but there's a pretty clear WARNING on the wiki about mailbox name 
conflicts.)


I can't use symlinked Maildirs, because new subfolders get created under 
~user/Maildir/. (Want them under /var/mail/Shared-X/)


I can't use hidden namespaces, because employees use Outlook (uggh), and 
I couldn't figure out how to "find" the namespace when it was hidden. 
(That seemed like the closest thing to a solution - it solved the LIST 
problem.)


Ideally, Shared-Two wouldn't even be visible to members of Shared-One, and 
vice versa. But, that's at least an acceptable "problem" I could live 
with.


Any suggestions?

Thanks,
Ben

[Dovecot] vfile ACL's

2007-08-03 Thread Benjamin R. Haskell

(Sorry for the impatience. This was one of several questions in my email 
from yesterday. I thought I might have better luck being more direct.)


Is there a way to set ACL's, using the vfile backend, on a truly global 
basis? or hierarchically (i.e. .Maildir.Sub inherits from .Maildir)?


The wiki page says:
"The default ACLs for mailboxes is to give owner all permissions and other 
users none. Mailboxes in public namespaces don't have owners, so by 
default no-one can access them."


Is this configurable?

Thanks,
Ben

Re: [Dovecot] vfile ACL's

2007-08-07 Thread Benjamin R. Haskell


On Sun, 5 Aug 2007, Timo Sirainen wrote:


On Fri, 2007-08-03 at 09:34 -0400, Benjamin R. Haskell wrote:
(Sorry for the impatience. This was one of several questions in my email 
from yesterday. I thought I might have better luck being more direct.)


Is there a way to set ACL's, using the vfile backend, on a truly global 
basis? or hierarchically (i.e. .Maildir.Sub inherits from .Maildir)?


I thought there was something like that, but looks like not. I don't 
remember if this is because there was a problem with adding support for 
them or if I simply haven't gotten around to implementing them yet.




Thanks for the response.

I worked around the actual problem (in "[Dovecot] Shared folder 
hierarchies, multiple groups") with the following patch:


http://benizi.com/dovecot-1.0.1-namespace-hack.patch


It's probably not the "correct" thing to do. (Hence "-hack".) But, it did 
seem to be the minimal set of changes required to accomplish what I wanted 
(shared folders implemented via namespaces with permissions controlled by 
the namespace INBOX's group).


It changes the following:

1. src/imap/cmd-list.c - list_namespace_init
In the IMAP LIST command, when checking namespace INBOX'es, if the INBOX 
folder's path exists and is not readable, it doesn't list it.


2. src/lib-storage/index/maildir/maildir-list.c - maildir_fill_readdir
If it fails to open the directory because permission was denied, it sets 
an open_flag, but doesn't set_critial, and returns false.


3. src/lib-storage/index/maildir/maildir-list.c - maildir_mailbox_list_init
If maildir_fill_readdir fails, and the HIDEYHACK flag is set, it returns 
in the same place as a failure would, but doesn't set .failed on the 
context.


4. src/lib-storage/index/maildir/maildir-storage.c - verify_inbox
Checks permissions on the directory path. If the folder exists, but is 
unreadable, it returns 0 (= verifies OK), but logs an error to assist in 
actual-error debugging.


If there's anything *glaringly* wrong with this approach, please let me 
know.


Best,
Ben

Re: [Dovecot] Inbox re-initialized

2007-08-12 Thread Benjamin R. Haskell


On Mon, 13 Aug 2007, Joshua, C.S. Chen wrote:


This seems to be important to my problem. But I have no idea what it
means by 'migrating the message uid'. Could soneone give me a hint and
how to do that? I am using mbox format both in uw-imap and the current
dovecot.

Cheers
Joshua



From the /etc/dovecot/dovecot.conf comments on my machine:


  # POP3 UIDL (unique mail identifier) format to use. You can use
  # following variables:
  #
  #  %v - Mailbox's IMAP UIDVALIDITY
  #  %u - Mail's IMAP UID
  #  %m - MD5 sum of the mailbox headers in hex (mbox only)
  #  %f - filename (maildir only)
  #
  # If you want UIDL compatibility with other POP3 servers, use:
  #  UW's ipop3d : %08Xv%08Xu
  #
  # [... snipped ...]

# So, you'd want to add to your dovecot.conf:
#
pop3_uidl_format = %08Xv%08Xu



Best,
Ben

Re: [Dovecot] What is your dovecot setup?

2007-09-17 Thread Benjamin R. Haskell

On Tue, 18 Sep 2007, Timothy Murphy wrote:

On Mon 17 Sep 2007, Gunter Ohrner wrote:

A concrete example of an actual mail setup
and how this is seen by an IMAP client
would have been much more useful, in my view.

There is an example of the Maildir++ directory layout on this page.

Er, which page?

You snipped one level of replies too many:

On Mon, 17 Sep 2007, Gunter Ohrner wrote:

Am Montag, 17. September 2007 schrieb Timothy Murphy:

> > http://wiki.dovecot.org/MailboxFormat/Maildir describes the way
> > dovecot implements the Maildir++ quasi-standard.
> A concrete example of an actual mail setup
> and how this is seen by an IMAP client
> would have been much more useful, in my view.

There is an example of the Maildir++ directory layout on this page.

“this page” is then:
http://wiki.dovecot.org/MailboxFormat/Maildir

Specifically, I think you'd want the section titled “Directory Structure”:
http://wiki.dovecot.org/MailboxFormat/Maildir#line-74

Re: [Dovecot] What is your dovecot setup?

2007-09-17 Thread Benjamin R. Haskell


On Tue, 18 Sep 2007, Timothy Murphy wrote:


On Tue 18 Sep 2007, Bill Cole wrote:


A concrete example of an actual mail setup
and how this is seen by an IMAP client
would have been much more useful, in my view.


Aside from creating the top-level Maildir directory and telling
whatever your delivery agent is where to find it (and perhaps telling
Dovecot, if it is a strange place...), you don't need to set any of
the Maildir structure up or go digging into it on the filesystem
level. Dovecot presents an Inbox to IMAP clients, and IMAP clients
can tell Dovecot to create whatever logical directory structures the
user wants.


Surely it would take far less time to give your actual setup
than it would to explain (at length) how easy it is to set it up ...


I'm inferring, since I'm not the original respondent, but it seems to me 
Bill is simply warning you about mucking about in the Maildir. And, if you 
weren't apparently having trouble with procmail delivery, it would be a 
valid point (Roughly, “Stay out of dovecot and your MDA's business, or 
you risk breaking things.”).





Here is my server directory setup:
~/Maildir/[cur,new,tmp], ~/Maildir/.Family/[cur,new,tmp], etc.

My dovecot.conf sets
mail_location = maildir:~/Maildir/

My .procmailrc sets
MAILDIR=/var/spool/mail
DEFAULT=$HOME/Maildir/

I cannot see the Family folder from my IMAPS client.


Are you saying it differs from IMAP to IMAPS or merely stating that 
you're using an IMAPS client?




Also it complains of the lack of .INBOX.directory
("Could Not Determine Resource Status").


“it” = your IMAPS client or procmail?



For what it's worth, my setup:

# Note the lack of a trailing slash.
# Pretty sure it shouldn't make a difference, since you've qualified it as 
# Maildir already with the ‘maildir:’ prefix, but...


mail_location = maildir:~/Maildir

namespace public {
 separator = /
 prefix = Shared/
 location = 
maildir:/var/mail/Shared:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public
}
namespace private {
 separator = /
 prefix =
 inbox = yes
}

Thus, my folders are also:
~/Maildir/{cur,tmp,new}
~/Maildir/.Junk E-mail/{cur,tmp,new}
... etc. ...

Plus:
/var/mail/Shared/{cur,tmp,new}
/var/mail/Shared/.subfolder/{cur,tmp,new}
... etc. ...
# For more info on the shared folders:
# http://wiki.dovecot.org/SharedMailboxes#line-49



I could be wrong, but your .procmailrc MAILDIR setting doesn't look right 
to me. I know it's unrelated to Maildir-the-format, but is there some 
reason you're starting in the mail spool directory? Part of the point (in 
my eyes) of using Maildir-the-format is that it avoids having a 
world-writable vsm directory.

( See second bullet point at: http://cr.yp.to/qmail/vsm.txt )

For more info on procmail and MAILDIR:
See Step 4 below this: (closest anchor; should scroll down a bit)
http://www.ii.com/internet/robots/procmail/qs/#rcDOTtesting

Specifically:
“Make sure you replace  MAILDIR=$HOME/Msgs  with the directory where your 
personal (non-system-spool) mailboxes are stored and that this directory 
exists and is writable by your LOGNAME. The MAILDIR variable specifies 
Procmail's working directory and all relative paths are relative to this 
directory.”


The error message you quoted makes me think you used a relative path 
somewhere and that you can't create the .INBOX.directory{,/{cur,new,tmp}} 
folders underneath /var/spool/mail.



Part of my own .procmailrc:
# Note that I don't explicitly set MAILDIR...
# ...but I also never use an unqualified path (I always prepend $DEFAULT)

DEFAULT=$HOME/Maildir/

# an example rule:
:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
$DEFAULT.Junk\ E-mail/


Best,
Ben

Re: [Dovecot] What is your dovecot setup?

2007-09-17 Thread Benjamin R. Haskell


On Tue, 18 Sep 2007, Bill Cole wrote:

At 2:10 AM +0100 9/18/07, Timothy Murphy  imposed structure on a stream of 
electrons, yielding:



I cannot see the Family folder from my IMAPS client.
Also it complains of the lack of .INBOX.directory
("Could Not Determine Resource Status").


A concrete problem description, at last.

1. Is .Family a proper Maildir++ directory? i.e. does it have a maildirfolder 
file in it?  Missing that would cause Dovecot to not use it.


That's not true (in dovecot-1.0.3, at least). I have no problems accessing 
any of the subfolders under my ~/Maildir/, but:


$ find ~/Maildir -name cur | wc -l
18
$ find ~/Maildir -name maildirfolder | wc -l
5

i.e. Only 5 of 18 subfolders have that file. I think the dovecot-created 
folders have it, whereas the procmail-created folders do not. And, as a 
test:


$ find ~/Maildir -name maildirfolder -exec rm '{}' \;

had no ill effect on the visibility of my folders. That said, I also don't 
use quotas of any kind, so I can't speak as to its effects on the '++' of 
Maildir++.


Best,
Ben

Re: [Dovecot] quota reporting and mail.app

2007-09-19 Thread Benjamin R. Haskell


On Wed, 19 Sep 2007, Mike Horwath wrote:


On Wed, Sep 19, 2007 at 02:59:18PM -0700, Rich at Whidbey Telecom wrote:

If I remember right, this is a known issue, where Mail.app won't
report the quota when QUOTAROOT is "".  We've found no fix for it
here as it seems to be a Mail.app issue.


That's my guess as well, but after checking another IMAP server
(Communigate Pro), it returns a filled in string as well (#Account).

I don't have any UW-imap servers to touch, though :(

So, Courier-IMAP and Communigate Pro both return a filled in string
(though values are different), and Dovecot does not.




What's to hunt?

http://tools.ietf.org/html/rfc2087#section-4.3

RFC 2087 is the IMAP4 QUOTA extension. Section 4.3 has a pretty clear 
example of a GETQUOTAROOT command and its response. Dovecot's response is 
nearly verbatim.


As Rich mentioned, it appears to be a Mail.app issue with the empty-string 
QUOTAROOT name.


There's a FIXME in the dovecot source regarding this:

root = quota_root_init(setups[0], ""); /* FIXME: name? */

See attached patch (against 1.0.3, but from hg.dovecot.org, seems to still 
be valid) for a workaround. It causes dovecot to use a default QUOTAROOT 
name of "DEFAULT". [ I left the /*FIXME*/, since I'm not Timo. :-) ]


Best,
Bendiff -ur dovecot-1.0.3-orig/src/plugins/quota/quota.c 
dovecot-1.0.3-patched/src/plugins/quota/quota.c
--- dovecot-1.0.3-orig/src/plugins/quota/quota.c2007-07-30 
02:14:41.0 -0400
+++ dovecot-1.0.3-patched/src/plugins/quota/quota.c 2007-09-19 
18:42:38.0 -0400
@@ -180,7 +180,7 @@
/* create a new quota root for the storage */
struct quota_root *root;
 
-   root = quota_root_init(setups[0], ""); /* FIXME: name? */
+   root = quota_root_init(setups[0], "DEFAULT"); /* FIXME: name? */
found = quota_mail_storage_add_root(storage, root);
i_assert(found);
}

Re: [Dovecot] kmail + IMAPS

2007-09-23 Thread Benjamin R. Haskell


On Sun, 23 Sep 2007, Timothy Murphy wrote:


(1) I suspect the problem lies with authentication.
But how can I test this?


From past experience (but also came up as #1 when googling "testing 

IMAPS" w/o quotes) you should use:

openssl s_client -connect servername:993

If your dovecot does TLS negotiation [not sure if it's the default], you 
may also want to use/try:


openssl s_client -starttls imap -connect servername:143
(Caveat: -starttls only supported "smtp" and "pop3" on my system 
[OpenSSL 0.9.8d on Gentoo]. Don't know what the defaults are.)


993/143 can be replaced by imaps/imaps or whatever your ports are.

openssl s_client is a generally-useful tool for SSL/TLS testing 
(SMTPS/HTTPS/IMAPS/etc.).




(2) [ skipping kmail question ]

(3) I guess I don't understand exactly how TLS authentication works.
Does installing openssl set up the correct certificates
on server and client?


I had a really hard time with this myself, and I felt like I knew what I 
was doing. There are HOWTO's to setup the server-side self-signed 
certificates, but for the client-side setup, I went through much of:


Pine+OpenSSL HOWTO - http://www.madboa.com/geek/pine-ssl/

Some(/many?) of the sections are specific to Pine, the email client. But, 
any of the sections with openssl commands are generally useful (and, I 
think, well-explained).




Is there any documentation on this?


For the server-side:
http://wiki.dovecot.org/SSL
http://wiki.dovecot.org/SSL/CertificateCreation
http://wiki.dovecot.org/SSL/DovecotConfiguration

The Apache SSL/TLS documentation linked-to from that page [/SSL] looks 
good:

http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html


Best,
Ben

Re: [Dovecot] shared mailboxes question

2007-09-27 Thread Benjamin R. Haskell


On Thu, 27 Sep 2007, Cory Coager wrote:

I'm using a virtual mailbox setup.  Lets say my users have mailboxes in 
/home/vmail/domain/%u.  What I'm trying to do is setup one namespace that 
points to /home/vmail/domain and contains everyones mailboxes that I can 
subscribe to.  Is this possible?


Seems kind of an odd workaround, but I just tried setting up:
mail_location = maildir:/var/mail/.%u
namespace public {
 separator = /
 prefix = users/
 location = maildir:/var/mail
}
namespace private {
 separator = /
 prefix =
 inbox = yes
}

It makes listing all user mailboxes possible. (Each test user I logged in 
with made another mailbox appear in LIST "" "users/%" )


For me, there are definite permissions problems, that I might be able to 
work around with one or more of: login scripts, ACL's, or the 
dovecot-shared file described in SharedMailboxes:

http://wiki.dovecot.org/PostLoginScripting
http://wiki.dovecot.org/ACL
http://wiki.dovecot.org/SharedMailboxes#line-12

You, with virtual users, might want to use a single UID. (if you aren't 
already)


Best,
Ben

Re: [Dovecot] shared mailboxes question

2007-09-27 Thread Benjamin R. Haskell


On Thu, 27 Sep 2007, Cory Coager wrote:

Hmm, this didn't work for me.  The namespace is empty, nothing to subscribe 
to.


Not sure if this is the problem, but it can't hurt to be more explicit:

It makes listing all user mailboxes possible. (Each test user I logged in 
with made another mailbox appear in LIST "" "users/%" )


I didn't mention that the namespace was initially empty. But, each time a 
user logged in, their maildir was created. With virtual users maybe the 
same auto-creation doesn't take place.


I also didn't explicitly mention that each user's maildir is then at:
/var/mail/.username/{cur,new,tmp}

( Rather than: /var/mail/username/{cur,new,tmp} )

So, if you've already set up directories/folders for users, they'd need to 
be converted to the new names (==moved) before they show up.




Also, in case something else is affecting things:
( This is my “toy” dovecot installation, so it's pretty bare-bones. Just 
the gentoo settings. )


# dovecot -n
# 1.0.3: /etc/dovecot/dovecot.conf
listen: [::]
ssl_cert_file: /etc/ssl/dovecot/server.pem
ssl_key_file: /etc/ssl/dovecot/server.key
login_dir: /var/run/dovecot/login
login_executable: /usr/libexec/dovecot/imap-login
mail_extra_groups: mail
mail_location: maildir:/var/mail/.%u:INDEX=/var/mail/.%u/dovecot
mail_debug: yes
mail_executable: /root/dovecot-login.sh
namespace:
  type: public
  separator: /
  prefix: users/
  location: 
maildir:/var/mail/:CONTROL=/var/mail/.%u/control/users:INDEX=/var/mail/.%u/index/users

namespace:
  type: private
  separator: /
  inbox: yes
auth default:
  passdb:
driver: pam
args: *
  userdb:
driver: passwd
plugin:
  acl: vfile:/etc/dovecot/acls

Re: [Dovecot] shared mailboxes question

2007-10-01 Thread Benjamin R. Haskell


On Mon, 1 Oct 2007, Cory Coager wrote:


Timo Sirainen wrote:


Benjamin's setup should make it possible, but that works only for the
other users' INBOXes, and you do need that kludgy setup where users'
maildirs begin with ".".

I was originally planning on making this easily possible for v1.1, but
it got delayed. v1.2 maybe will support this setup, but for now only
ugly kludges are possible.

With v1.1 you could perhaps implement this more easily if you
use :LAYOUT=fs instead of Maildir++ layout..



I can't get this to work at all, nothing to subscribe to.  I'm using
version 1.0.3 though, could this be why?



Unless you're referring to ':LAYOUT=fs', it shouldn't be the issue. 1.0.3 
is the version I used to test the kludgy method. Before, I tested directly 
(telnet localhost 143 and LIST "" "users/%" commands). And just now I 
confirmed that you can subscribe to users/(username) through Thunderbird. 
(But it still doesn't do much, since the permissions problems remain.)


Best,
Ben

Re: [Dovecot] shared mailboxes question

2007-10-01 Thread Benjamin R. Haskell


On Mon, 1 Oct 2007, Charles Marcus wrote:


I'm using gentoo also so we must have the same exact version.  Something
strange though, my configuration file uses a different syntax than
yours.  Instead of using colons for variables it expects equals.  So
when I copied and pasted your config I got this error:

Error: Error in configuration file /etc/dovecot/dovecot.conf line 1:
Expecting '='
Fatal: Invalid configuration in /etc/dovecot/dovecot.conf

Why is this happening?


The colons are produced from the output of 'dovecot -n'... you can't just 
copy-n-paste that output to a config file...


I brought this up some time ago, right after Timo added the dovecot -n 
feature, that it should be formatted the same as the config file itself...


I second that suggestion. The namespace config is particularly different 
(the "type: public/private" part):


namespace:
  type: public
  separator: /
  prefix: users/
  location: 
maildir:/var/mail:CONTROL=/var/mail/.%u/control/users:INDEX=/var/mail/.%u/index/users
namespace:
  type: private
  separator: /
  inbox: yes

translates to:

namespace public {
 separator = /
 prefix = users/
 location = 
maildir:/var/mail:CONTROL=/var/mail/.%u/control/users:INDEX=/var/mail/.%u/index/users
}
namespace private {
 separator = /
 inbox = yes
}

Along with:

mail_location = maildir:/var/mail/.%u:INDEX=/var/mail/.%u/dovecot

I think those are the relevant changes (from the base Gentoo config) to my 
dovecot.conf.


Best,
Ben

Re: [Dovecot] Namespace "hidden" option not working?

2007-10-03 Thread Benjamin R. Haskell


On Wed, 3 Oct 2007, Ed W wrote:

I either misunderstand the namespace hidden option, or else perhaps it's not 
working correctly in 1.0.5?



dovecot.conf

# default namespace
namespace private {
separator = /
prefix =
inbox = yes
hidden = yes
}

# for backwards compatibility:
namespace private {
separator = .
prefix = INBOX.
inbox = yes
}



You shouldn't have inbox = yes on more than one namespace. From the 
comments in my dovecot.conf:


   # There can be only one INBOX, and this setting defines which namespace
   # has it.
   #inbox = yes

I think you're also hiding the wrong namespace. You don't want to 
advertise the backwards-compatibility namespace to clients. If they're 
already using the old one, they can still use it, but you don't want new 
clients to start using it. Namespace-aware clients will adapt (in 
theory?).


Best,
Ben

Re: [Dovecot] Namespace "hidden" option not working?


List a mailbox if the requested pattern matches "(prefix)(mailbox)".


should be:

Only list a hidden mailbox if it matches the pattern, and the pattern 
explicitly starts with "(prefix)"


(...and everything starts with "")

Re: [Dovecot] Namespace "hidden" option not working?


On Wed, 3 Oct 2007, Ed W wrote:


Hi

You shouldn't have inbox = yes on more than one namespace. From the 
comments in my dovecot.conf:


   # There can be only one INBOX, and this setting defines which namespace
   # has it.
   #inbox = yes


Sure.  However, if only one has the INBOX, then doesn't this rather break the 
whole point of having the backwards compatible access to the INBOX?  Am I 
missing the point?




The namespace provides backwards compatible access to the folders under 
"INBOX.". It doesn't have anything to do with the actual INBOX (an IMAP 
"special" name), which is still specified (for dovecot) by mail_location.


I suspect that inbox=yes just tells dovecot what separator to return in:
* LIST (\HasChildren) "(separator)" "INBOX"
by associating INBOX with a separator= setting.


I think you're also hiding the wrong namespace. You don't want to advertise 
the backwards-compatibility namespace to clients. If they're already using 
the old one, they can still use it, but you don't want new clients to start 
using it. Namespace-aware clients will adapt (in theory?).


Possibly.

Actually I decided that personally I prefer to have everything under 
"INBOX.", because all the clients I commonly use then nest the folders under 
INBOX (which I quite like).  However, OE and Outlook are too dumb to figure 
this out and it's pointless telling all our customers to set the folder 
prefix when we could just support it working without needing to change 
anything...



Anyway, the original question still stands!  How come all my folders from 
both namespaces are being listed??



My guess is that you can't hide a namespace with an empty prefix. I 
haven't checked the source, but I suspect the logic of the LIST'ing 
process is along the lines of:


List a mailbox if the requested pattern matches "(prefix)(mailbox)".

Then, "*" can be seen as "(empty-prefix)*", so "(mailbox)" matches.

It seems logical. I don't see another way Dovecot could infer that the 
empty-prefix namespace was being requested.


Best,
Ben

Re: [Dovecot] Dovceot user pop3 last connect info?


On Thu, 4 Oct 2007, Tim Tyler wrote:


  Dovecot experts,
 I am a newbie to Dovecot.  I am in the process of replacing qpopper with 
dovecot to support pop 3 clients.  I have installed the latest version of 
Dovecot on Fedora Core 6.  Everything seems to be working fine using ldap, 
etc.
 However, with qpopper, I used to have .pop.username files which would give 
me a time stamp of the last time a user established a pop3 connection.  I 
know that Dovecot has logs of connection in the /var/log/maillog files, but 
these files rotate out over a relatively short period of time.  Is there a 
method by which one can keep track of the last time a pop3 connection was 
established for each user when using Dovecot?


You can do this (and many other things) through Post-Login Scripting:
http://wiki.dovecot.org/PostLoginScripting

See in particular “Last-login tracking”:
http://wiki.dovecot.org/PostLoginScripting#line-20


A simple example for your specific request:

In /etc/dovecot/dovecot.conf:

protocol pop3 {
# [etc.]
mail_executable = /full/path/to/custom-pop3.sh


Then, in custom-pop3.sh: (which needs to be chmod +x)

#!/bin/sh
touch /var/mail/.pop.$USER
exec /usr/libexec/dovecot/pop3

Best,
Ben

Re: [Dovecot] UIDL and IMAP


[I didn't see a response to this on-list. Sorry if I'm repeating someone.]

On Mon, 1 Oct 2007, Kenneth Porter wrote:


[...] I forgot to change the pop3_uidl_format setting [...]
So he was seeing repeated downloads of all his mail (about 300 MBytes) every 
time he connected. [...]


Does this setting in fact get used by IMAP? It's in the POP3 section, so I'm 
wondering if it takes effect when one is using IMAP from the client.



No, it doesn't. IMAP unique identifiers are always 32-bit 
(unsigned) integers, expressed in base 10. (64 bits when combined with the 
32-bit UIDVALIDITY)


cf. RFC 3501 - IMAP 4rev1
discussion: http://tools.ietf.org/html/rfc3501#section-2.3.1.1
syntax: uniqueid - http://tools.ietf.org/html/rfc3501#page-91

POP3 UID's have significantly more variation (hence the dovecot setting):

[ from RFC 1937 - POP 3 - http://tools.ietf.org/html/rfc1939#page-12 ]
“The unique-id of a message is an arbitrary server-determined string, 
consisting of one to 70 characters in the range 0x21 to 0x7E, which 
uniquely identifies a message within a maildrop and which persists across 
sessions.”


Best,
Ben

Re: [Dovecot] trying to enable features

2007-10-13 Thread Benjamin R. Haskell


On Sat, 13 Oct 2007, Ray wrote:


Please correct me where I'm wrong.
according to my understanding: When the server receives an email, dovecot pop
server makes connection with the outside world, [cut]


Dovecot's POP3 server waits for a user to connect to it to retrieve mails 
that are already stored somewhere. In your case, probably by Postfix 
receiving the mail via SMTP, then delivering it via Procmail (not sure on 
that last part). You could optionally use Dovecot's 'deliver' to do that 
last step, but Dovecot still doesn't make any connection for incoming 
mail. That part's handled by Postfix (in your case).


There's plenty of documentation in the wiki about all this.

 This should clear up the roles of dovecot/etc. 
http://wiki.dovecot.org/MailServerOverview

In particular, try this highlighting, and note the two highlights:
http://wiki.dovecot.org/MailServerOverview?highlight=%28not+responsible%29

Dovecot's 'deliver':
http://wiki.dovecot.org/LDA
http://wiki.dovecot.org/LDA/Postfix

Best,
Ben

Re: [Dovecot] Converting Outlook .PST's (was: Suggested IMAP Directory Size..)

2007-10-15 Thread Benjamin R. Haskell


On Mon, 15 Oct 2007, Ilo Lorusso wrote:


[...]
I know the users also have large OUT LOOK pst files 4.5GIGs and wondering if
I could also intergrate that into IMAP?


It can be done, but it is a nightmare. For post-2003(?) Outlook .PST's, 
the only sensible, non-commercial path I could find was through 
Thunderbird's import. Uploading directly to the server (Even if you ran a 
local server!) was horrendously, painstakingly slow, and rendered the 
Outlook user's computer unusable for that time.


(If you're feeling lucky, Google libpst. Maybe your Outlook is old 
enough that it supports the format.)


Via Thunderbird:

1. Open all the .PST's you want to convert in Outlook, and, if possible, 
make sure those were the only .PST's open.


2. Be sure to 'compact'/'compress' each one, to get rid of deleted 
messages (excluding those in 'Deleted Items'. Uggh.).


3. Make sure Outlook is completely closed, and not accessing any .PST's.

4. Open Thunderbird.

5. Import mail from Outlook.

This gets you mbox files with the same hierarchy that you had in Outlook. 
I then wrote some Perl scripts to deal with these. In my case, I was 
combining several users' folders into a single shared hierarchy. Maybe you 
can run some mbox2maildir program and be done with it.


Caveats:

- If possible, change the location of Thunderbird's profile directory to a 
short path name. (e.g. C:\convert) The default path to local folders:

C:\Documents and Settings\%USER%\Application Data\Thunderbird\Profiles\(random 
string)\Mail\Local Folders
means that approximately 100 of your 255-character limit for filenames are 
chewed up.


- Thunderbird will mangle folder names that contain 'odd' characters. I 
never figured out what characters caused trouble, but the following were 
definitely OK: [A-Za-z0-9. ]

(I found the odd foldernames running:
find (dirname) -type d | perl -lnwe 'print if /[\da-f]{8}/'
They always ended in a string of hexadecimal digits.)

- Thunderbird doesn't seem to like non-Latin-1 headers. (I didn't find 
this out until someone noticed it a while after the conversion.) This 
means QP-encoded headers. (In my case, ISO-2022-JP.)


Best of luck. I don't envy your task. :-)

-- Ben

Re: [Dovecot] Converting Outlook .PST's

2007-10-15 Thread Benjamin R. Haskell


On Mon, 15 Oct 2007, Denis Cardon wrote:


Hi Benjamin,



[...]
I know the users also have large OUT LOOK pst files 4.5GIGs and wondering 
if 
I could also intergrate that into IMAP?
It can be done, but it is a nightmare. For post-2003(?) Outlook .PST's, the 
only sensible, non-commercial path I could find was through Thunderbird's 
import. Uploading directly to the server (Even if you ran a local server!) 
was horrendously, painstakingly slow, and rendered the Outlook user's 
computer unusable for that time.
It is possible to connect outlook directly to an imap server (if it was 
previously connected to an exchange, you first have to switch it pop/imap 
mode. I don't remember where you select that). Then you can create a imap 
connection in addition to the local folders and drag'n drop the mail folders 
to the new imap connexion. The major issue with this process is when you have 
a very large amount of folder...


This was the "uploading directly to the server" option I mentioned.

The .PST's we "converted" (using the process I described) were each about 
3 or 4 GB (containing 10-20K messages each). Plus there was an extensive 
folder hierarchy involved (3 top-level folders with about 100 subfolders 
each, and each of those having an average of 3 subfolders -- basically 
/TOP/client-name/job-number).


Our first approach had been to just drag and drop a folder or two (with 
their sub-folders) at a time (totalling ~100MB) at the end of the day, so 
that they'd finish by the next morning. But, there were lots of arbitrary 
errors, making it difficult to both complete the process and to resume 
from errors. (Since the folders were created on the server side, trying to 
resume resulted in "Folder already exists"-type errors.)


In testing, our external server, which we accessed via ADSL at a pretty 
consistent 300Kbps, had about the same transfer rate and characteristics 
as a server I set up on the local (wired, very fast) LAN. Even on the LAN, 
Outlook was taking horribly long amounts of time to transfer. At one 
point, a back-of-the-envelope calculation put the estimate at about two 
weeks (based on what had made it over to the server). And that was for a 
single .PST on a decently fast network (total transfer time for that .PST 
file itself would've been around 8 hours).


I suspect the culprit is Microsoft's less-than-stellar IMAP support, and 
recommend you avoid it. The Thunderbird route has just as many hurdles 
(It's done through SimpleMAPI, which is a subset of Exchange's MAPI that 
runs locally to a machine), but at least it's computationally tractable 
(in some sense).


Best,
Ben

Re: [Dovecot] Migrating from UW IMAP - pine - Thunderbird - squirrelmail

2007-10-22 Thread Benjamin R. Haskell

On Mon, 22 Oct 2007, Israel Bravo wrote:

Hello!
I saw your post to the mailing list
(http://www.dovecot.org/list/dovecot/2006-January/010968.html) where you
write "A description for pine with imap acces without entering any
password is also discussed.", but I didn't find such description in
this post.

Would you be so kind to point me to some source where it is
explained - currently users have to insert the password twice - when
they open the shell window and when they start Pine.

The passwordless access set up by that configuration is only applicable if
you have Dovecot on the same server as Pine/Alpine (hereafter, *pine).

The relevant bits are:

rsh-open-timeout=3
rsh-path=
rsh-command=/usr/sbin/dovecot --exec-mail imap

This subverts the 'rsh' mail access route to access localhost's dovecot
installation directly. When *pine goes to connect via rsh, it will instead
run dovecot, dropping into an IMAP connection without having to enter a
password (since you're running locally -- PREAUTH).

I write "subverts", since I think this prevents a real 'rsh' connection
from working properly. Plus, I'm not 100% sure this will always work
properly. Dovecot running as a daemon has (at some point) root privileges.
With my post-login script owned by root, I get:

Fatal: execv(/root/dovecot-login.sh) failed: Permission denied

Commenting my "mail_executable = /root/dovecot-login.sh" line fixes that,
but it seems hack-ish that that's necessary.

Another question - may be you can help me: Currently we use Pine
with IMAP (dovecot); both INBOX and folder collection are saved on the
Linux server. But how to save the "saved-messages" and "sent-mail"
folders in the user's home directory on the server?

This should happen fairly automatically, I think. I'm pretty sure *pine
stores those in the first folder collection unless you override them.

inbox-path={cyrus.example.com/tls/user=username}INBOX
folder-collections="Cyrus Server" {cyrus.example.com/tls/user=username}INBOX.[],
... etc. ...

No special setup for saved-messages, as far as I can see. [set: using default "saved-messages">], though my default FCC is INBOX. I
don't use sent-mail.

Best,
Ben

Re: [Dovecot] Listening only on localhost

2007-11-02 Thread Benjamin R. Haskell


On Fri, 2 Nov 2007, Timo Sirainen wrote:


On Mon, 2007-10-29 at 21:54 +0100, [EMAIL PROTECTED] wrote:

I've got dovecot 1.0.rc15.

..

dovecot -n correctly reports:
listen: 127.0.0.1:143
ssl_listen: *:10993

But I can still do a 'telnet MY_HOST 143' from the outside,
and 'netstat -pltn | grep dovecot' reports: [ip changed ;)]
tcp  0  0  77.my.ip.253:10993  0.0.0.0:*  LISTEN  4847/dovecot
tcp  0  0  77.my.ip.253:1430.0.0.0:*  LISTEN  4847/dovecot


Am I doing something wrong? Or is there a bug?


Could be a bug. Works fine in v1.0.7.



I had a similar problem at some point. I fixed it by removing an idiotic 
alias in my /etc/hosts file. Some dingbat had aliased the server's FQDN 
to localhost. Maybe it's the other way 'round in your case.


Not optimistic, just the first thing that sprang to mind. (Pessimistic 
because I'd expect aliasing localhost to something other than 127.0.0.1 
would break a lot more than just dovecot.)


Best,
Ben

Re: [Dovecot] IMAP outlook express error

2007-11-08 Thread Benjamin R. Haskell


On Thu, 8 Nov 2007, Hannibal Ndlovu wrote:


[...]

The issue is when i try and get my mail using the IMAP protocol outlook
gives and error "cannot find Inbox on 192.0.0.1"


Didn't really look at the rest of your settings, and it's probably a typo, 
but 192.0.0.1 is an odd address to be using. Are you sure you don't want 
192.168.0.1?


(192.0.0.1 doesn't appear to be valid outside of IANA. 192.168.0.0/16 is 
the range that's blocked off for "Private Use". cf. RFC's 3330 and 1918)


Best,
Ben

Re: [Dovecot] IMAP outlook express error

2007-11-08 Thread Benjamin R. Haskell


On Thu, 8 Nov 2007, Hannibal Ndlovu wrote:


Hi

Am running debian etch + exim4 + dovecot 1.0.rc15-2etch with both an IMAP
and a POP3 server

The issue is when i try and get my mail using the IMAP protocol outlook
gives and error "cannot find Inbox on 192.0.0.1"

its happens with thunderbird and with Kmail -

I assume i have misconfigured it some how and my mail is set to "mail_spool"
in Exim4

[dovecot -n output trimmed]



Sorry for the noise about the obfuscated IP address.

It sounds like you have exim set to deliver mail to /var/mail/(username). 
Then you should set in your dovecot.conf:


mail_location = mbox:/var/mail/%u

Or, if you want other mbox folders to appear in ~/mail:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

For full details, see: http://wiki.dovecot.org/MailLocation

Best,
Ben

Re: [Dovecot] dovecot.index mtime

2007-11-10 Thread Benjamin R. Haskell


On Sat, 10 Nov 2007, Matt wrote:


Is there anyway I can get Dovecot to update mtime on dovecot.index
everytime a user successfully checks there email?  Or perhaps there is
a better way to do what I want here.

I am working on a script that I want to check when the last time a
user checked there email account.  If a user has not checked it in say
6 months I want to automatically suspend the account through the MTA.
If they start checking it again I also want to automatically reinstate
it.  What I thought was a good way was to look at the mtime on
dovecot.index but a user can be checking there email daily but if they
do not receive a new message in say 6 months the mtime will date back
to 6 months still.  Ran into this with an email address used by a fax
machine.

So is there a better way with dovecot to determine this?  I am using
dovecot-1.0.rc29 right now.



[From an email I wrote in October]

You can do this (and many other things) through Post-Login Scripting:
http://wiki.dovecot.org/PostLoginScripting

See in particular “Last-login tracking”:
http://wiki.dovecot.org/PostLoginScripting#line-20


[...and for your situation:]

I think I'd avoid actually disabling the account through the MTA, 
especially if it's for security considerations and your accounts have 
shell access. But it wouldn't be that hard:



In dovecot.conf, set your IMAP login script as follows:

protocol imap {
# ...
mail_executable = /full/path/to/loginscript.sh


Then, use the attached loginscript.sh. (and chmod +x it)

Tested with 1.0.5 under Gentoo. The 'stat' and 'date' commands might need 
alteration depending on your particular flavor of O/S.


(I also realized after writing it that you probably meant to disable mail 
delivery, not IMAP access. But, it was a fun exercise.)


In that case, all you need in loginscript.sh is:

#!/bin/sh
touch $HOME/.dovecot-lastlogin
exec /usr/libexec/dovecot/imap

Then run a cron job to disable delivery through your MTA of choice.

Best,
Ben

dovecot-login.sh
Description: Bourne shell script

Re: [Dovecot] dovecot.index mtime

2007-11-11 Thread Benjamin R. Haskell


On Sun, 11 Nov 2007, Matt wrote:


Is there anyway I can get Dovecot to update mtime on dovecot.index
everytime a user successfully checks there email?


Postlogin scripting would work like Benjamin said. Another possibility
would be to check atime if you haven't disabled atime updates.


atime is updated everytime I do a backup which is once a week.


protocol imap {
# ...
mail_executable = /full/path/to/loginscript.sh


I imagine I would need to put this in pop3 section as well?


Yes. I would do it via symlinks, then have loginscript.sh exec the 
appropriate dovecot process based on how it was called.


e.g.:

protocol imap {
mail_executable = /full/path/to/imap
...
protocol pop3 {
mail_executable = /full/path/to/pop3


with imap and pop3 each a symlink to loginscript.sh. Then, replace the 
exec in loginscript.sh with:

exec /usr/libexec/dovecot/`basename $0`



#!/bin/sh
touch $HOME/.dovecot-lastlogin
exec /usr/libexec/dovecot/imap


Can I just touch the dovecot.index instead?


Maybe. Not sure what environment variable holds its location, though. And 
I'm not 100% sure it always exists or whether you'd have to special-case 
the first-time login. (Will 'touch' creating a zero-length index cause 
trouble for dovecot? I suspect not.) It might also be nice to just have it 
as a separate file with an obvious name, rather than relying on nothing 
else changing dovecot.index. (I think, for example, you can have dovecot's 
deliver update dovecot.index... or maybe that was just on someone's 
wishlist.)




Also, I am bit confused.  Why must the script exec imap?


mail_executable tells dovecot what to run after a successful login. 
Usually that's 'imap'. So, when you replace imap with loginscript.sh, you 
need to be sure that it eventually turns into 'imap', which handles the 
actual IMAP connection after your script makes its tweaks.




I imagine
$HOME will contain the path to the home directory of the pop3/imap
user that just successfully logged in?


Yes.


Best,
Ben

Re: [Dovecot] dovecot.index mtime

2007-11-12 Thread Benjamin R. Haskell

On Mon, 12 Nov 2007, pod wrote:

"BH" == Benjamin R Haskell <[EMAIL PROTECTED]> writes:

   >>  Can I just touch the dovecot.index instead?

   BH> Maybe. Not sure what environment variable holds its location,
   BH> though. And I'm not 100% sure it always exists or whether you'd
   BH> have to special-case the first-time login. (Will 'touch' creating
   BH> a zero-length index cause trouble for dovecot? I suspect not.)

Also be aware that the script is not being run with the uid of the user -
it is /usr/libexec/dovecot/imap that drops privs - so touching the index
file if it does not already exist may cause problems later when the user
process wants to update the index file.

Thanks for pointing that out. I'd been testing by running:
dovecot --exec-mail imap
which runs as the current user. (Didn't realize that.)

You could also use mail_drop_priv_before_exec in dovecot.conf (with the 
caveats in the comments):

# Drop all privileges before exec()ing the mail process. This is mostly
# meant for debugging, otherwise you don't get core dumps. It could be a small
# security risk if you use single UID for multiple users, as the users could
# ptrace() each others processes then.
mail_drop_priv_before_exec = yes

Or, probably better, you could put the last login information in a common 
directory, rather than the user's home directory (which would also make 
the cron job easier, I suspect).

If you have sessreg from the X11 distribution you could also try:

#!/bin/sh
if test -z "$DUMP_CAPABILITY"; then
 /usr/bin/sessreg -a -L /var/log/lastlog -u none -w none -l imap -h "$IP" 
"$USER"
fi
exec /usr/libexec/dovecot/imap

to put an entry into /var/log/lastlog (though note you need two scripts
for both IMAP and POP logins).

Since you're not doing anything protocol-specific (like echo "* OK [ALERT] 
Blah"), you could use the symlink trick to only require one script:

ln -s /path/script /path/imap
ln -s /path/script /path/pop3

Then replace the exec with:
exec /usr/libexec/dovecot/`basename $0`

   >> Also, I am bit confused.  Why must the script exec imap?

It doesn't _have_ to.  It's a micro-optimisation.  If the script did not
exec the user imap process then a /bin/sh process would be sitting around
waiting for the user imap process to exit and when it did then the /bin/sh
process would itself just exit.

Ah. In my other email I took the question to mean "Why must the script run 
imap?", but I bet this is what Matt meant.

Best,
Ben

Re: [Dovecot] dovecot.index mtime

[Oops. Sorry for the delay.]

On Sun, 11 Nov 2007, Matt wrote:

I think I'd avoid actually disabling the account through the MTA,
especially if it's for security considerations and your accounts have
shell access. But it wouldn't be that hard:

My actual goal is to reduce load on the server. These are simply
email users and have no shell or any other access. If there not using
the account I do not want Exim wasting resources virus scanning, spam
scanning(spamd) and storing messages for them.

I want to add all email users that have not checked email through pop3
or imap in ~6 months to /etc/virtual/suspended_email. Exim will
reject messages to these accounts with error message: "Account
suspended due to inactivity". I do not want to suspend pop3 or imap
access in fact if they start using the account again I want to
automatically re-enable. Likely will run a script in cron.daily to
check all this.

I think that better explains what I am after.

Yes. And it all sounds pretty reasonable.

I guess the issues I still think are important:

1. You shouldn't use dovecot.index as your marker file.

As mentioned before, dovecot's deliver _might_ update it, and
special-casing its existence might be annoying. Plus, its location is
harder to determine than either the user's home or some chosen central
directory.

e.g. Running env | sort > $HOME/.dovecot-env in the login script, the only
place I see mention of an index file is:

MAIL=maildir:/home/bhaskell/Maildir:INBOX=/var/mail/.bhaskell:INDEX=/var/mail/.bhaskell/dovecot

And even after IMAP'ing in and FETCHing some message headers, there's no
dovecot.index in /var/mail/.bhaskell/dovecot.

[ed. I think it was a problem with permissions actually. I change my
config quite a bit to test various dovecot settings. Even so, the problem
remains. dovecot.index's location can even vary by namespace.]

2. I would use a centralized directory.

I've written cron jobs in the past to do stuff with files in home
directories. e.g.

getent passwd | cut -d: -f6 | sort | uniq | \
xargs -iI find I -maxdepth 1 -name [...etc.]

The alternative is much simpler:

cd /var/lastlogins
for l in *
do [...etc.]

3. I would use the login script to inform users that they'd been disabled.

If they're logging in through IMAP, you can [ALERT] them to the fact, so
they don't wonder about a gap in mail delivery.

Best,
Ben

Re: [Dovecot] Mail.app IDLE support


On Wed, 14 Nov 2007, Jason Fesler wrote:


Any hint on how to use tcpdump to only grab the interesting parts?


tcpdump port 143

or whatever.

My knowledge of tcpdump is very limited and I only seem to be able to get a 
lot of noise out of it.


Look at ngrep - it lets you use both tcpdump expressions, *and* further 
filter by regular expression.  And, it shows ascii output instead of all the 
hex crap - makes it a lot easier to follow ascii based protocols.


Either way, you'll want to disable SSL on the client, so that you can see the 
traffic properly. :-)




Though I've not tried ngrep (Thanks!), I've found Wireshark (formerly 
Ethereal) to be incredibly easy to use for these types of tasks.


In Wireshark, you'd just start a capture and filter it to:

protocol = imap

Best,
Ben

Re: [Dovecot] dovecot.index mtime


On Wed, 14 Nov 2007, Matt wrote:


[...]

I guess the issues I still think are important:

1. You shouldn't use dovecot.index as your marker file.


I gave up trying to use dovecot.index.  Instead I look at each users
./new directory.  If there are any messages over 6 months old I put
there email address in file that tells exim to reject any new
messages.  Run the script in cron.daily so if they start using it
again it will reactivate in 24 hours or less.  Having to look at all
messages in the ./new folders is significantly more CPU and I/O load
though.  Having run the script last night it seems to work fine.
Audited some of email addresses it added to be blocked and none look
out of place.


Glad to hear you've got something that's working for you.

For what it's worth, I'd look at the newest message in the ./cur folder, 
rather than the oldest in the ./new. (You want the last time the user 
looked at a message, not the first time the user got mail after being 
logged in.) The actual difference in times probably isn't an important 
detail when you're talking O(6 months).


But, the benefit is that you can get the timestamp for the last time the 
user read/deleted a message in ./cur simply by checking the change time of 
the ./cur directory. (rather than going through all its files)


e.g.
$ stat -c '%z (=%Z)' ~/Maildir/cur
2007-11-14 15:26:09.0 -0500 (=1195071992)
$ stat -c '%z (=%Z)' ~/Maildir/cur/* | sort | tail -n 1
2007-11-14 15:26:09.0 -0500 (=1195071992)

Should make it fast enough to run in cron.hourly, depending on your number 
of users/mailboxes.


Best,
Ben

Re: [Dovecot] dovecot.index mtime