dovecot.index.pvt view is inconsistent: error messages for public mailbox folder

2017-01-03 Thread Andreas Ntaflos
Hi list,

running Dovecot 2.2.27 on Ubuntu 14.04. A public mailbox
"Public/Spam-Learning" in a public namespace with per-user "Seen" flags
is configured like this:

namespace pub {
  hidden = no
  inbox = no
  list = children
  location = maildir:/var/vmail/public:INDEXPVT=~/Maildir/public
  prefix = Public/
  separator = /
  subscriptions = no
  type = public
  mailbox "Spam-Learning" {
auto = subscribe
  }
}

The log files are full of error messages like these (got about 15000 in
the last three days):

2017-01-03T11:19:28.242386+01:00 mailserver01 dovecot:
imap(foo@example.org): Error:
/var/vmail/example.org/foo.bar/Maildir/public/.Spam-Learning/dovecot.index.pvt
reset, view is now inconsistent
2017-01-03T11:19:28.248524+01:00 mailserver01 dovecot:
imap(foo@example.org): Error:
/var/vmail/example.org/foo.bar/Maildir/public/.Spam-Learning/dovecot.index.pvt
view is inconsistent
2017-01-03T11:23:50.209732+01:00 mailserver01 dovecot:
imap(baz.q...@example.org): Error:
/var/vmail/example.org/baz.quux/Maildir/public/.Spam-Learning/dovecot.index.pvt
reset, view is now inconsistent
2017-01-03T11:23:50.775940+01:00 mailserver01 dovecot:
imap(some.u...@example.org): Error:
/var/vmail/example.org/some.user/Maildir/public/.Spam-Learning/dovecot.index.pvt
reset, view is now inconsistent
2017-01-03T11:25:38.419536+01:00 mailserver01 dovecot:
imap(other.u...@example.org): Error:
/var/vmail/example.org/other.user/Maildir/public/.Spam-Learning/dovecot.index.pvt
reset, view is now inconsistent
2017-01-03T11:34:14.351346+01:00 mailserver01 dovecot:
imap(more.u...@example.org): Error:
/var/vmail/example.org/more.user/Maildir/public/.Spam-Learning/dovecot.index.pvt
reset, view is now inconsistent
2017-01-03T11:41:37.488916+01:00 mailserver01 dovecot:
imap(support.u...@example.org): Error:
/var/vmail/example.org/support.user/Maildir/public/.Spam-Learning/dovecot.index.pvt
reset, view is now inconsistent

This problem did not seem to manifest itself in Dovecot 2.2.25, we see
it only after upgrading to 2.2.27.

I am not sure what the effects are. It seems that messages moved to the
Public/Spam-Learning folder are deleted after a short while (not by the
sa-learn cron job, which runs every morning) but I currently cannot say
if this is because a user deletes them explicitly or because Dovecot
does something it shouldn't. So this observation is possibly not relevant.

It also doesn't seem to matter what kind of IMAP client access the
Spam-Learning folder. Our users use Thunderbird, Apple Mail, Outlook,
Roundcube, Horde and various mobile clients as well.

I have attached the output of doveconf -n for reference.

What could be the issue here? Are we doing something wrong or is this a
bug in Dovecot?

Thanks!

Andreas
# 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.16 (fed8554)
# OS: Linux 4.4.0-57-generic x86_64 Ubuntu 14.04.3 LTS
auth_master_user_separator = *
auth_mechanisms = plain login
auth_socket_path = /var/run/dovecot/auth-master
base_dir = /var/run/dovecot/
default_client_limit = 8192
default_process_limit = 1024
default_vsz_limit = 512 M
lda_mailbox_autocreate = yes
lda_mailbox_autosubscribe = yes
lda_original_recipient_header = X-Original-To
listen = *
mail_access_groups = mail
mail_location = maildir:~/Maildir
mail_plugins = " zlib"
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date ihave imapflags
namespace backup {
  hidden = yes
  inbox = no
  list = no
  location = maildir:~/Maildir-backup
  prefix = Backup/
  separator = /
  type = private
}
namespace inbox {
  hidden = no
  inbox = yes
  list = yes
  location =
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox INBOX/Spam {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix =
  separator = /
  subscriptions = yes
  type = private
}
namespace pub {
  hidden = no
  inbox = no
  list = children
  location = maildir:/var/vmail/public:INDEXPVT=~/Maildir/public
  mailbox Spam-Learning {
auto = subscribe
  }
  prefix = Public/
  separator = /
  subscriptions = no
  type = public
}
passdb {
  args = /etc/dovecot/master.%s
  driver = passwd-file
  master = yes
  name = passwd-file
}
passdb {
  args = /etc/dovecot/dovecot-ldap.conf
  driver = ldap
}
plugin {
  acl = vfile:/etc/dovecot/dovecot-acl
  recipient_delimiter = +
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_before = /etc/dovecot/sieve.d/before/
  sieve_default = /etc/dovecot/sieve.d/default.sieve
  sieve_extensions = +imapflags
  sieve_global = /etc/dovecot/sieve.d/global/
  zlib_save = bz2
  zlib_save_level = 9
}
protocols = imap pop3 lmtp sieve
service auth-worker {
  user 

LDA autocreate/autosubscribe per namespace?

2016-07-07 Thread Andreas Ntaflos
Using Dovecot 2.2.25 and Pigeonhole 0.4.14. I can provide the output of 
doveconf -n if needed.


We use a moderately clever global Sieve script to create a read-only 
(using ACLs) backup/archive of all incoming and outgoing mails. Mail 
messages filtered this way are filed into folders in a namespace called 
"Backup", e.g. Backup/sent-backup/${year}/${month} and 
Backup/received-backup/${year}/${month}. The Sieve script in question 
can be found at the end of this message for reference.


Now obviously we generally want mailboxes to be created automatically, 
so we set


lda_mailbox_autocreate = yes

in dovecot.conf. We also want regular mailboxes, created by our users' 
own Sieve scripts, to be autocreated and autosubscribed, so we also set


lda_mailbox_autosubscribe = yes

in dovecot.conf.

But we *don't* want the Backup mailboxes to be subscribed automatically, 
because our users usually only need access to those when they want to 
restore messages accidentally deleted from their INBOX or other folders. 
So the idea is to keep these Backup mailboxes unsubscribed, which also 
saves lots of space and network traffic on the user side. When a user 
then wants to restore a deleted mail message they subscribe to the right 
Backup folder and copy the message back to their INBOX (and then 
unsubscribe again).


Is there a way to control autocreate/autosubscribe per namespace?

Currently it doesn't look that way, and 
lda_mailbox_autocreate/lda_mailbox_autosubscribe are valid globally.


The "Backup" namespace is configured this way:

namespace backup {
  hidden = no
  list = yes
  inbox = no
  location = maildir:~/Maildir-backup
  prefix = Backup/
  separator = /
  type = private
}

This is the Sieve script in 
/etc/dovecot/sieve.d/before/002-backup-mails.sieve:


require ["subaddress", "fileinto", "copy", "envelope", "imap4flags", 
"variables", "date", "mailbox" ];


if currentdate :matches "year" "*" { set "year" "${1}"; }
if currentdate :matches "month" "*" { set "month" "${1}"; }

# This makes use of sender_bcc_maps in Postfix
if envelope :detail "to" "sent-backup" {
fileinto :flags "\\Seen" "Backup/sent-backup/${year}/${month}";
stop;
}

# We only want to backup incoming mail if it is not marked as spam.
if header :contains "X-Spam-Flag" ["YES"] {
discard;
stop;
} else {
fileinto :copy :flags "\\Seen" 
"Backup/received-backup/${year}/${month}";

}

Thanks,

Andreas


Re: [Dovecot] Thunderbird does not notice new mails arrival in imap folders

2011-04-23 Thread Andreas Ntaflos
On 23/04/11 06:58, Frank Bonnet wrote:
> Hello
> 
> Since I've installed Dovecot 2 I've observed that TB does not
> notice new mails arrival in IMAP folders.
> When I click on a folder new mails count is updated, with
> dovecot 1 it was automatic.
> I wonder if it is due to the new TB version (lastest stable)
> or Dovecot 2 (2.0.11).

I believe this is the default behaviour in Thunderbird 3 and has nothing
to do with Dovecot. To change it so that Thunderbird checks all IMAP
folders for new messages open the config editor and set

mail.check_all_imap_folders_for_new

to "true".

HTH

Andreas



signature.asc
Description: OpenPGP digital signature


Re: [Dovecot] Duplicate suppression

2011-03-14 Thread Andreas Ntaflos
On Monday 14 March 2011 19:06:57 Thiago Henrique wrote:
> Hello,
> 
> In a Dovecot 2.0.6 server I have an account x@domain and an alias
> y@domain -> x@domain.
> 
> When I send an email to x@domain with carbon copy to y@domain, X
> receives two messages on mailbox. Dovecot2 has any feature of
> duplicate suppression ?
> 
> Thanks,
> Thiago Henrique

Robert is very probably right. Misconfiguring Postfix's content filter 
capabilities can lead to message duplication when expanding aliases. 
This is also Postfix problem and unrelated to Dovecot. Have a look at 
this thread:

http://archives.neohapsis.com/archives/postfix/2004-11/0842.html

Also study the Postfix filter readme at 

http://www.postfix.org/FILTER_README.html

to understand why it works they way it does.

Andreas


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


Re: [Dovecot] passdb pam and userdb passwd "Authentication failure" errors

2010-12-04 Thread Andreas Ntaflos
On Saturday 04 December 2010 21:45:34 Mark Alan wrote:
 >   QUESTION 2: the final email arrives with an email header that
>   includes:
> Received: from desk.example.com (unknown [127.0.1.1])
>  (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
>  (No client certificate requested)
>  by mail.example.com (Postfix) with ESMTPSA id F24707FE6D
>  for ; Sat,  4 Dec 2010 18:16:00 +  (WET)
> 
>   Does this mean that I have SSL/TLS properly configured? The "No
> client certificate requested" is supposed to be there?

Can't really help you with your first question, however this second 
question pertains to Postfix and not Dovecot. But yes, from the looks of 
this header it seems TLS is configured correctly, and yes, "no client 
certificate requested" should be here. Unless of course you think you 
have Postfix configured to require client certificate verification. I 
advise you to have a look at the Postfix TLS documentation at 
.

HTH 

Andreas


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


Re: [Dovecot] Static userdb with LDAP passdb but without "allow_all_users=yes"?

2010-12-02 Thread Andreas Ntaflos
On Thursday 02 December 2010 20:10:42 Timo Sirainen wrote:
> On Wed, 2010-12-01 at 02:56 +0100, Andreas Ntaflos wrote:
> > Thanks for the hint! I always forget how useful mail_debug and
> > auth_debug can be. It turns out that the problem was indeed that I
> > had passwd and pam as additional user and password databases. The
> > order in which they are declared in dovecot.conf matters of course
> > and when the PAM passdb is the last entry the problem appears.
> 
> Fixed: http://hg.dovecot.org/dovecot-2.0/rev/627aeadb0955

Excellent, thank you very much.


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


Re: [Dovecot] Static userdb with LDAP passdb but without "allow_all_users=yes"?

2010-11-30 Thread Andreas Ntaflos
On Friday 26 November 2010 17:30:55 Timo Sirainen wrote:
> On Thu, 2010-11-25 at 19:31 +0100, Andreas Ntaflos wrote:
> > Is it possible to have a static user database along with an LDAP
> > password database and *not* be forced to set "allow_all_users=yes"
> > for the userdb?
> 
> Yes.
> 
> > dovecot: auth: Error: static(not-a-u...@test01.example.com): passdb
> > doesn't support lookups, can't verify user's existence
> 
> Set auth_debug=yes and see what it logs. passdb ldap should support
> it, as long as you don't set auth_bind=yes. I just verified that it
> works:

Thanks for the hint! I always forget how useful mail_debug and 
auth_debug can be. It turns out that the problem was indeed that I had 
passwd and pam as additional user and password databases. The order in 
which they are declared in dovecot.conf matters of course and when the 
PAM passdb is the last entry the problem appears.

The workaround is obviously to not set PAM as the last entry. But this 
also means that any user from the LDAP/static user database that tries 
to log in has to go through PAM first and fail. On a busy server with 
lots of LDAP/static users and few system users this would waste quite a 
few resources and clutter up /var/log/auth.log pretty badly. 

Is there a way around that?

Andreas


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


[Dovecot] Static userdb with LDAP passdb but without "allow_all_users=yes"?

2010-11-25 Thread Andreas Ntaflos
Hi, 

Is it possible to have a static user database along with an LDAP 
password database and *not* be forced to set "allow_all_users=yes" for 
the userdb? 

The wiki page on static user database says "Normally static userdb 
handles this by doing a passdb lookup instead." How should the passdb 
behave in order for this to work?

In my tests (on a test server) I am using Dovecot 2.0.7 and Postfix 
2.7.0 on Ubuntu 10.04.1. I use (or am trying to use) LMTP with Dovecot 
and Postfix according to the HOWTO in the wiki [1] as well as dynamic 
address verification with LMTP [2]. Users are virtual, using a static 
userdb and passwords from LDAP. I also serve local system users which is 
why I also have userdb and passdb pam, but this isn't the issue here.

Delivering mail to an existing virtual user works fine as far as I can 
see but when a non-existent user is the recipient Dovecot complains that 
the passdb doesn't support lookups:

postfix/smtpd[26469]: connect from remote-smtp.example.net[10.0.0.10]
postfix/cleanup[26474]: 772A760B25: message-
id=<20101125172409.772a760...@mailtest.example.com>
postfix/qmgr[27672]: 772A760B25: from=, size=276, nrcpt=1 (queue active)
dovecot: lmtp(22109): Connect from local
dovecot: auth: Error: static(not-a-u...@test01.example.com): passdb 
doesn't support lookups, can't verify user's existence
dovecot: lmtp(22109): Error: user not-a-u...@test01.example.com: Auth 
USER lookup failed
dovecot: lmtp(22109): Disconnect from local: Client quit
postfix/lmtp[26475]: 772A760B25: to=, 
relay=mailtest.example.com[private/dovecot-lmtp], delay=0.18, 
delays=0.17/0.01/0/0, dsn=4.3.0, status=undeliverable (host 
mailtest.example.com[private/dovecot-lmtp] said: 451 4.3.0  Internal error occurred. Refer to server log 
for more information. (in reply to RCPT TO command))
postfix/qmgr[27672]: 772A760B25: removed
postfix/smtpd[26469]: NOQUEUE: reject: RCPT from remote-
smtp.example.net[10.0.0.10]: 450 4.1.1 : 
Recipient address rejected: unverified address: ho
st mailtest.example.com[private/dovecot-lmtp] said: 451 4.3.0  Internal error occurred. Refer to server log 
for more information. (in reply to RCPT TO command); 
from= to= 
proto=ESMTP helo=
postfix/smtpd[26469]: disconnect from remote-smtp.example.net[10.0.0.10] 

I've uploaded this log file excerpt for your viewing convenience to  
https://daff.pseudoterminal.org/misc/dovecot/failed_delivery.log 
More relevant information (doveconf -n, dovecot-ldap.conf) is found 
below. I can also provide a log excerpt from a successful delivery to an 
existing virtual user, if needed.

To summarise: I want to use LMTP, dynamic address verification, a static 
user database and an LDAP password database. Can it be done without 
having to rely on the MTA (Postfix) to verify existing users?

Thanks in advance!

Andreas

[1] http://wiki2.dovecot.org/HowTo/PostfixDovecotLMTP
[2] http://wiki2.dovecot.org/LDA/Postfix

dovecot-ldap.conf:
uris = ldap://ldap.example.com:389
tls = yes
tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt
base = ou=virtualDomains,dc=example,dc=com
dn = uid=dovecot,ou=services,dc=example,dc=com
dnpass = xxx

pass_attrs=uid=user, userPassword=password
pass_filter=(&(objectClass=hostedAccount)(uid=%u)(accountEnabled=TRUE))

iterate_attrs = uid=user
iterate_filter = (objectClass=hostedAccount)

doveconf -n:
https://daff.pseudoterminal.org/misc/dovecot/doveconf-n.txt
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Phantom email message

2010-11-10 Thread Andreas Ntaflos
On Wednesday 10 November 2010 20:59:40 Marc Perkel wrote:
> Got sort of a strange problem on one email account. Everything works
> fine with Thunderbird/IMAP showing the correct unread message count.
> But on my DroidX smartphone one of my email accounts always shows
> one unread message, but I can't bring any unread messages up. It's
> like there's something there making it think there's a message when
> there isn't.

This is very long shot but I think I observed something similar some 
time ago with K9 when a message was "starred", i.e. tagged as important. 
Maybe this is confusing things?

Andreas


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


Re: [Dovecot] Migrating existing local Maildir structure to dovecot server Maildir

2009-11-16 Thread Andreas Ntaflos
On Monday 16 November 2009 12:35:35 Halim Issa wrote:
> On 16/11/2009, Andreas Ntaflos  wrote:
> > On Friday 13 November 2009 15:00:09 Halim Issa wrote:
> >> Hello,
> >>
> >> I'm about to migrate a number of existing users who have been
> >> using POP3 with emails stored locally in KMail's Maildir format
> >> into an IMAP solution based on Dovecot.
> >>
> >> Will it be possible to simply move all the KDE Maildir folders
> >> from the local PCs to the Maildir folder on the IMAP server
> >> running Dovecot and then have the emails accessible on the server,
> >> or will this most likely mess up the Dovecot index files?
> >>
> >> If this causes index file trouble, is there any way to force a
> >> re-indexing of all these files, or is there another recommended
> >> way of migrating up to 7 years of email communication from local
> >> hosts to the IMAP server, for later putting them in folders?
> >
> > I don't think the migration of the Maildir structure itself is the
> > problem. Dovecot has no problem reading it, no matter where it came
> > from, as long as it is a proper Maildir structure. Existing indexes
> > should not be affected.
> >
> > The indexes that KMail writes, however, will probably not migrate
> > well or at all. I do not know anything about the index format KMail
> > uses but converting it to something Dovecot understands and accepts
> > seems troublesome and difficult to me.
> >
> > This means that you can copy all existing, local Maildirs over to
> > the server (you can even put them in subfolders in existing
> > accounts) and Dovecot will read them just fine. But it also means
> > that Dovecot will very probably present them to the user as new
> > messages, never seen before.
> >
> > But do yourself a favour and test any procedure you plan on
> > implementing properly and extensively before actually implementing
> > it. Otherwise it could end up messy and irreparable.
>
> Thanks much for your thorough answer! I'll make sure to test
> extensively.
>
> One thing came to mind - would it be possible to use Dovecot and
> Disconnected IMAP itself for the transfer, and perhaps thus keep the
> indexes?
> If I move the messages from the local mailbox to the IMAP mailbox
> from within Kmail it should perhaps keep the status?

Interesting idea, but I don't know how well or even if KMail handles 
moving messages from one account to another. In any case it seems worth 
a try.

> Also - is there any documentation anywhere (or tips on better google
> search terms) on what is stored in these indexes? I suppose apart
> from Read/New status, it also contains whether or not there have been
> replies to the mail and on what date the email was replied to?

If you are talking about the indexes KMail keeps I suppose you should 
try one of the KDE-PIM-related mailing lists. For Dovecot's index files 
you should ask Timo or browse the wiki, maybe there is some 
documentation about it somewhere. I myself don't know anything about 
the format of any of the index files, sorry.

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Migrating existing local Maildir structure to dovecot server Maildir

2009-11-16 Thread Andreas Ntaflos
On Friday 13 November 2009 15:00:09 Halim Issa wrote:
> Hello,
>
> I'm about to migrate a number of existing users who have been using
> POP3 with emails stored locally in KMail's Maildir format into an
> IMAP solution based on Dovecot.
>
> Will it be possible to simply move all the KDE Maildir folders from
> the local PCs to the Maildir folder on the IMAP server running
> Dovecot and then have the emails accessible on the server, or will
> this most likely mess up the Dovecot index files?
>
> If this causes index file trouble, is there any way to force a
> re-indexing of all these files, or is there another recommended way
> of migrating up to 7 years of email communication from local hosts to
> the IMAP server, for later putting them in folders?

I don't think the migration of the Maildir structure itself is the 
problem. Dovecot has no problem reading it, no matter where it came 
from, as long as it is a proper Maildir structure. Existing indexes 
should not be affected.

The indexes that KMail writes, however, will probably not migrate well 
or at all. I do not know anything about the index format KMail uses but 
converting it to something Dovecot understands and accepts seems 
troublesome and difficult to me.

This means that you can copy all existing, local Maildirs over to the 
server (you can even put them in subfolders in existing accounts) and 
Dovecot will read them just fine. But it also means that Dovecot will 
very probably present them to the user as new messages, never seen 
before. 

But do yourself a favour and test any procedure you plan on implementing 
properly and extensively before actually implementing it. Otherwise it 
could end up messy and irreparable.

HTH

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] IMAP goes down from time to time

2009-10-20 Thread Andreas Ntaflos
On Tuesday 20 October 2009 19:15:35 Juan Felipe Estrada wrote:
> Good Afternoon
>
> I´m really new at this and i don´t know if i´m posting at the right
> place.
>
> My problem is that our Dovecot IMAP is stopping from time to time
> with no info in the log, i just realize about this when our support
> person call me saying that the whatsup monitor is showing the IMAP4
> process down. I can figure about this too by trying to get in our
> webmail Horde and i cannot login.
>
> Here i post my Dovecot -n command i´ll appreciate any help.
>
> /# 1.0.7: /etc/dovecot.conf

Preliminary idea: this is a very old version of Dovecot. Before diving 
into debugging sessions maybe you could do yourself a favour and update 
to a more recent version, such as 1.2.6? 

Now, when you realise that some process (is it imap-login or imap?) is 
down can you log into the server and confirm that, using ps or another 
tool? You say the log files don't tell you anything. Can you set 
auth_debug = yes and/or mail_debug = yes? Maybe that can give you a 
clou.

And how about the LDAP server? Being unable to log in could have 
something to do with the authentication backend. How does your 
dovecot-ldap.conf look like? Could it be that the LDAP lookup somehow 
crashes an IMAP-related process?

A newer, better Dovecot version will probably help you a lot with the 
debugging. It may even make the error go away. You should seriously 
consider upgrading.

HTH 

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Need a little shadow to MySQL conversion help

2009-10-20 Thread Andreas Ntaflos
On Tuesday 20 October 2009 18:57:48 Marc Perkel wrote:
> Thank you all for your help on this. I'll probably try it tonight
> when most people will be off line and hopefully it won't be down
> long. Everything already is lower case so that shouldn't be an issue.

Another suggestion, a little off-topic and probably not quite original: 
you should really try to use a test server for experimenting, at least 
if you do any non-trivial hosting or can tell your users to go to hell 
when they complain :) Nothing makes your life more miserable than a 
screwed up mail system you cannot easily recover. 

The test server can even be a small virtual machine as long as it sports 
the same software infrastructure (Dovecot, Postfix, MySQL, Apache and 
whatever else) as the production system. Using a test system goes a 
long way in ensuring that you don't run into nasty surprises and only 
changes you tested and of which you know the consequences are applied 
to the production instance.

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Need a little shadow to MySQL conversion help

2009-10-20 Thread Andreas Ntaflos
On Tuesday 20 October 2009 18:49:16 Jerry wrote:
> On Tue, 20 Oct 2009 17:57:35 +0200
>
> Andreas Ntaflos  wrote:
> > On Tuesday 20 October 2009 17:07:49 Timo Sirainen wrote:
> > > On Oct 20, 2009, at 9:45 AM, Andreas Ntaflos wrote:
> > > > I'd say you need a static userdb. Something like this:
> > >
> > > A couple of small things:
> > > > passdb sql {
> > > > args = /etc/dovecot/dovecot-sql.conf
> > > > }
> > > >
> > > > userdb static {
> > > > args = uid=vmail gid=vmail home=/var/vmail/%Ld/%Ln
> > > > allow_all_users=yes }
> > >
> > > %Ld/%Ln at this point works for now, but maybe not in future. I'd
> > > have passdb already change it lowercase. Also allow_all_users=yes
> > > isn't required (but maybe not harmful) since passdb sql is used.
> >
> > That's good to know, thanks. And you're right of course, the passdb
> > should already return the correct information, Dovecot shouldn't be
> > asked to change anything afterwards.
> >
> > Fortunately I myself don't use MySQL anymore but have migrated
> > everything to PostgreSQL. It does a much better job as a DBMS
> > (remote, secured access to the DB, fine-grained permissions and
> > rules) and also knows about case sensitivity. So foo...@example.com
> > is not the same as foo...@example.com. Which eliminates this
> > problem class altogether.
>
> MySQL, since at least 5.x knows about case. You can Google for the
> information if you want.

Good to know, thanks. Creating tables with a *_cs collation seems to be 
the trick.

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Need a little shadow to MySQL conversion help

2009-10-20 Thread Andreas Ntaflos
On Tuesday 20 October 2009 17:57:35 Andreas Ntaflos wrote:
> On Tuesday 20 October 2009 17:07:49 Timo Sirainen wrote:
> > On Oct 20, 2009, at 9:45 AM, Andreas Ntaflos wrote:
> > > I'd say you need a static userdb. Something like this:
> >
> > A couple of small things:
> > > passdb sql {
> > > args = /etc/dovecot/dovecot-sql.conf
> > > }
> > >
> > > userdb static {
> > > args = uid=vmail gid=vmail home=/var/vmail/%Ld/%Ln
> > > allow_all_users=yes }
> >
> > %Ld/%Ln at this point works for now, but maybe not in future. I'd
> > have passdb already change it lowercase. Also allow_all_users=yes
> > isn't required (but maybe not harmful) since passdb sql is used.
>
> That's good to know, thanks. And you're right of course, the passdb
> should already return the correct information, Dovecot shouldn't be
> asked to change anything afterwards.
>
> Fortunately I myself don't use MySQL anymore but have migrated
> everything to PostgreSQL. It does a much better job as a DBMS
> (remote, secured access to the DB, fine-grained permissions and
> rules) and also knows about case sensitivity. So foo...@example.com
> is not the same as foo...@example.com. Which eliminates this problem
> class altogether.
>
> > > password_query = SELECT password FROM view_users WHERE
> > > email='%u';
> >
> > SELECT password, email AS user FROM ..
> >
> > changes username to same case as it's in the database (so lowercase
> > probably) and there's no need to use %L anymore.

> You mean something like
>
> SELECT password, LOWER(email) as user FROM view_users WHERE
> email='%u'

I probably misunderstood that. 

SELECT password, email AS user FROM ...

is indeed enough to return the correct case, no need to use the LOWER 
function.

This whole case sensitivity thing is only a problem if the passdb query 
returns just the password and no username. Returning the username as 
well is the way to go.

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Need a little shadow to MySQL conversion help

2009-10-20 Thread Andreas Ntaflos
On Tuesday 20 October 2009 17:07:49 Timo Sirainen wrote:
> On Oct 20, 2009, at 9:45 AM, Andreas Ntaflos wrote:
> > I'd say you need a static userdb. Something like this:
>
> A couple of small things:
> > passdb sql {
> > args = /etc/dovecot/dovecot-sql.conf
> > }
> >
> > userdb static {
> > args = uid=vmail gid=vmail home=/var/vmail/%Ld/%Ln
> > allow_all_users=yes }
>
> %Ld/%Ln at this point works for now, but maybe not in future. I'd
> have passdb already change it lowercase. Also allow_all_users=yes
> isn't required (but maybe not harmful) since passdb sql is used.

That's good to know, thanks. And you're right of course, the passdb 
should already return the correct information, Dovecot shouldn't be 
asked to change anything afterwards.

Fortunately I myself don't use MySQL anymore but have migrated 
everything to PostgreSQL. It does a much better job as a DBMS (remote, 
secured access to the DB, fine-grained permissions and rules) and also 
knows about case sensitivity. So foo...@example.com is not the same as 
foo...@example.com. Which eliminates this problem class altogether.

> > password_query = SELECT password FROM view_users WHERE email='%u';
>
> SELECT password, email AS user FROM ..
>
> changes username to same case as it's in the database (so lowercase
> probably) and there's no need to use %L anymore.

You mean something like 

SELECT password, LOWER(email) as user FROM view_users WHERE email='%u'

should do the trick? I shall test this on my test server, just for fun.

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Need a little shadow to MySQL conversion help

2009-10-20 Thread Andreas Ntaflos
On Monday 19 October 2009 19:13:36 Marc Perkel wrote:
> Excuse me for being stupid and confused.
>
> I'm trying to convert my dovecot install from passwd-file to mysql. I
> have a single table called "users" that has 3 fields, user_name,
> domain_name and password. The data came from passwd/shadow files so
> it uses the same password encryption as the shadow files do. The
> directory where the email is stored is calculated elsewhere and not
> stored in the database. The UID and GID are both mail for all virtual
> users. The user logs in passing the full email address and the
> password.
>
> So - what would be the config for using MySQL? Do I even need a
> userdb? If so - what would it be?

I'd say you need a static userdb. Something like this:

passdb sql {
 args = /etc/dovecot/dovecot-sql.conf
}

userdb static {
 args = uid=vmail gid=vmail home=/var/vmail/%Ld/%Ln allow_all_users=yes
}

Since you have a "users" table that does not contain the full e-mail 
address of a given user you should create a view that does so that the 
query in dovecot-sql.conf remains simple. You could also simplify the 
users table to contain the full email address. There are ways aplenty. 

mysql>
CREATE VIEW view_users AS
SELECT CONCAT(users.user_name, '@', users.domain_name) AS email,
users.password
FROM users

Then dovecot-sql.conf could look like this:

driver = mysql
connect = host=127.0.0.1 dbname=mailserver user=mailuser password=foo
default_pass_scheme = CRYPT
password_query = SELECT password FROM view_users WHERE email='%u';

This database setup, however, is not really normalised so if that is a 
concern (it probably will be when you start hosting more than one 
virtual domain) you should look to refine the it.

I can very much recommend the ISPmail tutorials of Christoph Haas, found 
at <http://workaround.org/ispmail>. It explains very well how to do 
virtual mail hosting with a MySQL database backend and other fun stuff. 
Much of what I have written in this message you can find there.

HTH Andreas
-- 
Andreas Ntaflos

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] mail archiving

2009-10-10 Thread Andreas Ntaflos
On Saturday 10 October 2009 14:33:16 Charles Marcus wrote:
> On 10/10/2009 3:14 AM, Nikolai K. Bochev wrote:
> >> What exactly do you mean by archiving?
> >>
> >> We use Postfix and Dovecot to backup any sent and received mail
> >> for our users.
> >
> > Could you show us an example how do you do this ? I'm really
> > interested in such solution.
> 
> Same here... !
> 
> In fact this would be an awesome contribution to the wiki, and I hope
> you will agree and can find the time to write something up, it would
>  be very much appreciated by many I think.

Ok, I'll get on it and create a HOWTO in the Dovecot wiki, based on my 
internal documentation. I will have to organise my thoughts a bit first, 
though :)

Andreas
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] What exactly do you mean by archiving?

2009-10-10 Thread Andreas Ntaflos
On Saturday 10 October 2009 13:34:39 dhottin...@harrisonburg.k12.va.us 
wrote:
> I mean every single email sent and recieved is kept for a period of
> time (3 -5 years) separate from users mail, and emails cant be
> deleted.  Ideally emails would have compression, mailboxes need to be
> searchable easily, and some mechanism whereby attachments sent to
> multiple people only get saved once, and emails sent to multiple
> people only get saved once.  

Well my solution certainly will not fulfil all your requirements as it 
doesn't do compression and saves all mail and all attachments, 
regardless of number of recipients. Obviously you need some disk space, 
but that's really cheap these days. And since ACLs (as mentioned) don't 
work just right yet the archived messages would be deletable if the 
Backup namespace wasn't hidden from the users. 

My setup just does what it promises: saving all sent and received mail 
for every user on the system. This could actually be considered a 
feature, as it were, since it is a true, private, per-user backup where 
restoring messages wouldn't require any action from the administrator. 
However, I'm sure it can be refined (e.g. using ACLs) and I am open for 
suggestions.

> I could do something with procmail that
> copies every email coming in to another directory easily, but that
> doesnt solve the sent email.  

Well, sending mail is handled by the MTA (Sendmail in your case, Postfix 
in ours) so that is where you need to hook into to archive sent mail. 
The sender_bcc_maps parameter in Postfix is such a hook. You might want 
to have a look at [1] for that. 

I haven't found any way for this other than BCC'ing the message back to 
the sender and I don't think there is any. The beauty of it is its 
transparency and simplicity at the (minor) cost of an additional, local 
SMTP connection.

> Ive looked at several commercial
> products, but none seem to work nicely with sendmail.  Thanks for the
> information, I'll look and see if sieve will work better for me than
> procmail.  Im not sure thought that your method will pass the test
> come litigation time (if that every happens).

If it is an option I strongly suggest getting rid of Sendmail and using 
a secure, well-documented, feature-rich and easy to administer MTA like 
Postfix. Your life as administrator will be easier.

Andreas

[1] http://www.postfix.org/ADDRESS_REWRITING_README.html#auto_bcc
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] mail archiving

2009-10-09 Thread Andreas Ntaflos
On Friday 09 October 2009 17:18:53 dhottin...@harrisonburg.k12.va.us 
wrote:
> Im curious if anyone is archiving emails and what they are using.  I
> currently utilize sendmail/procmail/dovecot.

What exactly do you mean by archiving? 

We use Postfix and Dovecot to backup any sent and received mail for our 
users. Postfix, using sender_bcc_maps, resends any mail to the sending 
user via an address extension (i.e. mail sent by f...@example.org gets 
resent to foo+s...@example.org) and Dovecot with Sieve, using the 
sieve_before directive, filters such sent mail into a private namespace 
that is hidden from the user (Backup/sent).

Backing up received mail works very similar (ending up in 
Backup/received) but Postfix is not involved; this is a job for Sieve 
alone, again using the sieve_before directive and an appropriate script. 

So Postfix/Dovecot/Sieve. If ACLs worked a bit better in 1.2.x [1] I 
could even make the Backup namespace visible to its user and just 
ensure, via ACLs, that the user cannot delete any messages in this 
namespace. But this'll have to wait for 2.0 I believe.

Does that answer your question?

Andreas

[1] http://dovecot.org/list/dovecot/2009-September/042783.html
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Expire plugin: wrong mailbox separators in database?

2009-10-01 Thread Andreas Ntaflos
Hate to bump this, but is there nobody who uses the expire plugin and 
can confirm my observations? 

I'd love to use the expire plugin to delete old messages filed in spam 
folders but as it is now I can't get it to work with the wrong mailbox 
separators in the table entries.

Andreas
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Sieve: problems installing in different prefix

2009-09-27 Thread Andreas Ntaflos
Hi list, but mainly Stephan :)

when building and subsequently installing the new Sieve plugin I am 
coming across a small difficulty when it comes to "make install". The 
libraries lib90_sieve_plugin.* always get installed in the directory 
/usr/local/lib/dovecot/lda, no matter what "prefix" argument is supplied 
to "make install". Only the libraries seem affected, not the rest of the 
Sieve plugin distribution (i.e. sieve, sievec, sieve-test, ...).

Background: I like using XStow [1] to manage packages built from source. 
With XStow one can configure and build software like Dovecot and Sieve 
as usual (./configure && make) but then install it under a custom 
directory/prefix, like /usr/local/stow/dovecot-1.2.5. The "prefix" 
argument for "make install" is used for this, i.e.:

make install prefix=/usr/local/stow/dovecot-1.2.5

XStow is then used to create symlinks to the correct places in the file 
system. For example the Dovecot binary gets installed in 

/usr/local/stow/dovecot-1.2.5/sbin/dovecot

and a symbolic link is created by XStow:

/usr/local/sbin/dovecot -> ../stow/dovecot-1.2.5/sbin/dovecot

The advantages are clear: installing a software package is a matter of 
configuring, building and then installing under a custom directory, and 
letting XStow create symlinks. Updating is as easy as installing the new 
version in a parallel custom directory and letting XStow update the 
symlinks. Removing a software package just involves letting XStow remove 
the symlinks and doing an rm -rf on the custom directory. No more 
accidentally orphaned files or the need to keep the compiled source 
distribution around to be able to issue a "make uninstall".

Back to the problem: The Sieve source distribution seems to have some 
hard-coded setting to always install the libraries under 
/usr/local/lib/dovecot/lda and not honouring the "prefix" argument for 
"make install". This is probably a libtool issue, but I am not sure.

I know my way around the Autotools but here I am a bit lost. Looking at 
the generated Makefile in dovecot-1.2-sieve-0.1.12/src I can see the 
following:

moduledir = /usr/local/lib/dovecot/ 

It *should* look like this:

exec_prefix = ${prefix}
...
moduledir = ${exec_prefix}/lib/dovecot/ 

This explains why the install prefix is not honoured here. The 
"moduledir" has already been hardcoded, instead of prefixed. 

For comparison look at the Dovecot source distribution. Here all 
libraries are installed correctly under the specified prefix. An example 
is src/lib-sql. The generated Makefile includes these lines, which are 
correctly honouring the prefix:

exec_prefix = ${prefix}
...
moduledir = ${exec_prefix}/lib/dovecot
...
#sql_moduledir = $(moduledir)/sql
AM_CPPFLAGS = \
-I$(top_srcdir)/src/lib \
-DMODULEDIR=\""$(moduledir)"\" \
$(SQL_CFLAGS)

The last few lines seems to make sure that gcc uses the defined 
moduledir, but as usual generated code is not immediately comprehensible 
for the casual viewer :) 

The top-level generated Makefile also contains a correctly defined 
moduledir:

moduledir = ${exec_prefix}/lib/dovecot

So, which knobs have to be turned to have the Sieve source distribution 
use a correct "moduledir" and not a hardcoded path?

I hope I could explain the problem correctly and haven't drawn any wrong 
conclusions here. I will continue to investigate this and maybe even 
provide a patch if I find a solution but it is probably easier for the 
maintainer and author of the build system to look at this and determine 
what to do.

Anyway, apologies for this lengthy post. I hope it wasn't too long to 
read.

Andreas

[1] http://xstow.sourceforge.net/
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Sieve: redirect and keep action, possible bug (solved, but curious)

2009-09-27 Thread Andreas Ntaflos
On Saturday 26 September 2009 16:21:34 Stephan Bosch wrote:
> Andreas Ntaflos schreef:
> > As explained, in the user's sieve script the "keep" after the
> > redirect action is ignored when the backup mails script uses an
> > explicit "keep" after "fileinto", but not when "fileinto" is used
> > with "copy".
> >
> > Why?
> 
> Because you have tripped a bug that is fixed in the repository, but
>  not in the final release:
> 
> http://www.dovecot.org/list/dovecot/2009-September/042591.html
[...]
> Due to persisting headaches since last week I haven't had the ability
> nor the motivation to make a new release. Now that I am better I
>  should release new Sieve and ManageSieve(s) in the next few days or
>  so.

Hi Stephan, 

thanks for the reply and explanation and confirmation of this bug. Great 
to hear you are feeling better. Looking forward to testing the next 
releases. 

Andreas
-- 
Andreas Ntaflos 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Sieve: redirect and keep action, possible bug (solved, but curious)

2009-09-25 Thread Andreas Ntaflos
On Saturday 26 September 2009 02:40:40 Pascal Volk wrote:
> On 09/26/2009 02:27 AM Andreas Ntaflos wrote:
> > …
> > Funny thing is that it doesn't work here, even when I strip it down
> > to just the two lines:
> >
> > redirect "f...@example.org"
> > keep;
> 
> Hm, sorry no idea what could be the reason for this behavior.
> 
> > What version of Dovecot and Sieve are you using if I may ask?
> 
> Tested with Dovecot v1.2.5 + Patch
> http://hg.dovecot.org/dovecot-1.2/rev/0f04c7da33f1 and Sieve from
> http://www.rename-it.nl/dovecot/1.2/dovecot-1.2-sieve-0.1.12.tar.gz

Thank you for confirming that it should work correctly with the latest 
versions of Dovecot and Sieve. I found the problem in my setup.

I found that one of my "before" scripts (sieve_before = 
/etc/dovecot/sieve/before.d, [1]) had a fileinto action together with an 
explicit "keep". It seems that was a problem for the redirect action 
later in the user's own script.

I modified that "before" script to use 

fileinto :copy "INBOX/foo/bar";

instead of 

fileinto "INBOX/foo/bar"; 
keep;

and now the redirect action works as expected, like you tested and 
posted earlier.

Still, I wonder why this is happening? In both cases there is a keep 
action in effect, otherwise the user's script wouldn't get executed at 
all. Could someone explain what I am missing here? More details follow.

The script in /etc/dovecot/sieve/before.d looks as follows (I use it to 
keep a backup copy of all mail received in an extra, hidden namespace):

001-backup-mails.sieve:

# We only want to backup incoming mail if it is not marked as spam.
if header :contains "X-Spam-Flag" ["YES"] {
discard;
stop;
} else {
# This works
fileinto :copy :flags "\\Seen" "Backup/received-backup";

# This doesn't, as explained above
# fileinto :flags "\\Seen" "Backup/received-backup";
# keep;
}

This user's script is again only two lines:

user.sieve:

redirect "f...@example.org"
keep;

As explained, in the user's sieve script the "keep" after the redirect 
action is ignored when the backup mails script uses an explicit "keep" 
after "fileinto", but not when "fileinto" is used with "copy".

Why?

Thanks,

Andreas

[1] http://wiki.dovecot.org/LDA/Sieve/Dovecot
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Sieve: redirect and keep action, possible bug

2009-09-25 Thread Andreas Ntaflos
On Saturday 26 September 2009 02:17:34 Pascal Volk wrote:
> Your script looks strange for me. I'm simply using:
> 
> # sieve script start
> redirect "u...@example.com";
> keep;
> # sieve script end (no conditions)

Hi, 

thanks for the reply. I know it looks strange but that is how Ingo 
(Horde's filter application) generates it. But essentially it is the 
same as your script (just ignore the "if true" parts).
 
> All emails is forwarded to u...@example.com and will be saved in the
>  inbox.

Funny thing is that it doesn't work here, even when I strip it down to 
just the two lines:

redirect "f...@example.org"
keep;

Only the redirection is executed, the keep action seems to be ignored. 
If I again change it to a 'fileinto "INBOX";' it works as expected. 

What version of Dovecot and Sieve are you using if I may ask?

Thanks,

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Sieve: redirect and keep action, possible bug

2009-09-25 Thread Andreas Ntaflos
Hi,

Using Dovecot 1.2.4 and the new Sieve implementation in version 0.1.12, 
I ran into a problem that could indicate a bug in Sieve.

The following is a simple script (as generated by Horde's Ingo 
application) to redirect incoming mail and also keep a copy of the 
message in the local inbox:

if true {
redirect "f...@example.org";
}

if true {
keep;
stop;
}

Problem is, it doesn't work as expected: no copy of the message is kept 
in the local inbox. However, if I explicitly tell Sieve to "fileinto" it 
works fine:

require ["fileinto"];

if true {
redirect "f...@example.org";
}

if true {
fileinto "INBOX";
stop;
}

Is this a bug in Sieve or am I wrong about how "keep" works? 

Thanks in advance!

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Expire plugin: wrong mailbox separators in database?

2009-09-15 Thread Andreas Ntaflos
eve
  sieve_global_path: /etc/dovecot/sieve/default.sieve
  sieve_global_dir: /etc/dovecot/sieve/global/
  sieve_before: /etc/dovecot/sieve/before/
  autocreate: Trash
  autocreate2: Drafts
  autocreate3: Sent
  autocreate4: INBOX/Spam
  autocreate5: INBOX/Spam/Spam-To-Discard
  autosubscribe: Trash
  autosubscribe2: Drafts
  autosubscribe3: Sent
  autosubscribe4: INBOX/Spam
  autosubscribe5: INBOX/Spam/Spam-To-Discard
  acl: vfile:/etc/dovecot/acl
dict:
  expire: mysql:/etc/dovecot/dovecot-dict-expire.conf

/etc/dovecot/dovecot-dict-expire.conf:
=

connect = host=127.0.0.1 dbname=mailserver user=mailuser password=xxx

map {
  pattern = shared/expire/$user/$mailbox
  table = expires
  value_field = expire_stamp

  fields {
username = $user
mailbox = $mailbox
  }
}

The expires table:

CREATE TABLE expires (
  username varchar(100) not null,
  mailbox varchar(255) not null,
  expire_stamp integer not null,
  primary key (username, mailbox)
);

[1] http://wiki.dovecot.org/Plugins/Expire
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Crash: imap process, Dovecot 1.2.4, related to ACLs (backtrace included)

2009-09-14 Thread Andreas Ntaflos
On Monday 14 September 2009 03:26:45 Andreas Ntaflos wrote:
> On Monday 14 September 2009 03:11:55 Timo Sirainen wrote:
> > On Fri, 2009-08-28 at 02:46 +0200, Andreas Ntaflos wrote:
> > > Aug 28 01:08:01 mailtest0 dovecot:
> > > IMAP(andreas.ntaf...@example1.rise-s.com): Panic: file
> > > acl-backend-vfile.c: line 1124 (acl_backend_vfile_object_update):
> > > assertion failed: (!update->rights.global)
> >
> > Finally had time to look at this. I think the fix should be that
> >  global ACLs simply shouldn't be copied to child mailboxes. Is this
> >  also what you want? i.e. user can't delete mails from "Sent", but
> >  can delete from "Sent/child".
> >
> > http://hg.dovecot.org/dovecot-1.2/rev/6df681067e0a
>
> Thanks for not forgetting this :) I'll try out the patch first thing
> tomorrow.

So after some testing I think I can confirm that this crash is gone on 
my test server. I am in the process of setting up another mail server 
(which will go into production eventually) and will be testing this fix 
again. 

Is this patch in 1.2.5 as well? Didn't see anything mentioned in the 
release notes [1].

Anyway, thanks for taking care of the problem, Timo!

Andreas

[1] http://dovecot.org/list/dovecot-news/2009-September/000137.html
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Crash: imap process, Dovecot 1.2.4, related to ACLs (backtrace included)

2009-09-13 Thread Andreas Ntaflos
On Monday 14 September 2009 03:11:55 Timo Sirainen wrote:
> On Fri, 2009-08-28 at 02:46 +0200, Andreas Ntaflos wrote:
> > Aug 28 01:08:01 mailtest0 dovecot:
> > IMAP(andreas.ntaf...@example1.rise-s.com): Panic: file
> > acl-backend-vfile.c: line 1124 (acl_backend_vfile_object_update):
> > assertion failed: (!update->rights.global)
> 
> Finally had time to look at this. I think the fix should be that
>  global ACLs simply shouldn't be copied to child mailboxes. Is this
>  also what you want? i.e. user can't delete mails from "Sent", but
>  can delete from "Sent/child".
> 
> http://hg.dovecot.org/dovecot-1.2/rev/6df681067e0a 

Thanks for not forgetting this :) I'll try out the patch first thing 
tomorrow.

What I initially wanted to achieve was to have some folders (such as 
Sent, Drafts, Trash and INBOX/Spam) that the user wouldn't be able to 
delete, but creating subfolders would be allowed. The ACL setting of 
"owner lrwstipek" should do that, if I'm not mistaken.

I had more plans of setting ACLs on other folders such as Public/Spam 
and Public/Ham (no deletion, no subfolders), however, I am not sure 
anymore if ACLs are really the way to go. I've had a hard time getting 
them right, as I described in [1] and [2]. But that's unrelated to this 
crash issue.

I'll report back ASAP after applying the patch.

Thanks again, 

Andreas

[1] http://dovecot.org/pipermail/dovecot/2009-September/042551.html
[2] http://dovecot.org/pipermail/dovecot/2009-September/042558.html
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Global ACL configuration problems: mai lboxes not visible , set ACLs not honoured

2009-09-01 Thread Andreas Ntaflos
On Tuesday 01 September 2009 12:11:39 Thomas Leuxner wrote:
> On Tue, Sep 01, 2009 at 11:34:16AM +0200, Andreas Ntaflos wrote:
> > Is there anything more to it? I ask, because I can't seem to get it
> > to work correctly using this approach with global ACLs. Problems
> > include:
> >
> >  - Can't get the mailboxes "Spam" and "Ham" under the "Public"
> > namespace to show up in the mail client (Thunderbird, KMail,
> > Horde/IMP) at all. These have the ACL "authenticated lrwstipk" set
> > so the should be visible to authenticated clients, shouldn't they?
> > All I see is the namespace with no mailboxes beneath it.
>
> Hi Andreas,
>
> did you try with enabling the logging option 'mail_debug = yes'? It
> should then verbosely log ACLs read while accessing the folders. How
> about the files 'dovecot-acl' and 'dovecot-acl-list'? Are they
> present in your public root? The latter should have been
> automatically created once the subdirs have working ACLs.

Hi Thomas, 

thanks for your helpful reply. I hadn't thought of setting mail_debug, 
don't know why :) Now I can see more clearly. 

It seems that ACL files such as "/etc/dovecot/acls/Backup.received" 
or "/etc/dovecot/acls/Backup.sent" are read, but when accessing the 
actual mailbox Dovecot looks for a file "/etc/dovecot/acls/received" or
"/etc/dovecot/acls/sent". I.e. the mailbox names *without* the namespace 
prefix. This can't be the desired behaviour, can it? 

When I create such an ACL file (""/etc/dovecot/acls/sent") the defined 
restrictions seem to be applied. At least KMail doesn't even offer 
to "Delete message" anymore. Thunderbird does and messages can 
apparently be deleted, but they show up again upon reloading the 
folder. This is probably a Thunderbird issue. Horde/IMP is similar in 
this regard.

The Public namespace however doesn't seem to be given any consideration 
at all by Dovecot. I can see the namespace root ("Public") in the 
folder subscription list, but nothing beneath it. Even when I apply 
the "fix" described in the previous paragraphs I still can't see any of 
the public folders. The log file doesn't show anything about this 
either.

There are no "dovecot-acl" files at all, anywhere. I want to avoid 
having to use them, which is why I am trying to get global ACLs to 
work. The "dovecot-acl-list" files are created in every root directory, 
i.e. /var/mail/public/dovecot-acl-list, 
/var/vmail/example.org/username/Maildir/dovecot-acl-list 
and /var/vmail/example.org/username/Maildir-backup/dovecot-acl-list.

All three are empty.

So, the second issue (private namespace ACLs) could be a bug in Dovecot, 
unless I misunderstood how to name ACL files for mailboxes in other 
private namespaces. The first issue (invisibility of public folders) is 
still a mystery to me.

Ideas?

Thanks again for your reply!

Andreas
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Global ACL configuration problems: mailboxes not visible, set ACLs not honoured

2009-09-01 Thread Andreas Ntaflos
mode: 384
  user: vmail
plugin:
  sieve: ~/.dovecot.sieve
  sieve_dir: ~/sieve
  sieve_global_path: /etc/dovecot/sieve/default.sieve
  sieve_global_dir: /etc/dovecot/sieve/global/
  sieve_before: /etc/dovecot/sieve/before/
  autocreate: Trash
  autocreate2: Drafts
  autocreate3: Sent
  autocreate4: INBOX.Spam
  autosubscribe: Trash
  autosubscribe2: Drafts
  autosubscribe3: Sent
  autosubscribe4: INBOX.Spam
  acl: vfile:/etc/dovecot/acl

[1] http://dovecot.org/list/dovecot/2009-August/042467.html
-- 
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Crash: imap process, Dovecot 1.2.4, related to ACLs (backtrace included)

2009-08-28 Thread Andreas Ntaflos
On Friday 28 August 2009 19:42:47 Timo Sirainen wrote:
> On Fri, 2009-08-28 at 02:46 +0200, Andreas Ntaflos wrote:
> > Hi,
> >
> > I started experimenting with ACLs and found I could reliably and
> > reproducibly crash the IMAP process when trying to create a
> > subfolder of a folder that has has ACLs set. The folder is called
> > "Sent" with an ACL of "owner lrwstipke". I wanted to be able to
> > have certain folders the the user cannot delete but where
> > subfolders can be created freely.
>
> ..
>
> >   acl: vfile:/etc/dovecot/acl
>
> You created a global ACL, right? So /etc/dovecot/acl/Sent?

Exactly right. It contains the line "owner lrwstipke".

I just now reproduced the crash again. None of the Maildir folders 
contain anything pertaining to ACLs (no dovecot-acl or dovecot-acl-list 
files) and the Sent folder is the only one with an ACL set. The log file 
again shows

Panic: file acl-backend-vfile.c: line 1124 
(acl_backend_vfile_object_update): assertion failed: (!update-
>rights.global)

Anything else I can provide?

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Crash: imap process, Dovecot 1.2.4, related to ACLs (backtrace included)

2009-08-27 Thread Andreas Ntaflos
Hi, 

I started experimenting with ACLs and found I could reliably and reproducibly 
crash the IMAP process when trying to create a subfolder of a folder that has 
has ACLs set. The folder is called "Sent" with an ACL of "owner lrwstipke". I 
wanted to be able to have certain folders the the user cannot delete but where 
subfolders can be created freely.

Relevant information follows and I hope the backtrace is useful (lots of 
"value optimized out" entries). You can also find everything from below on 
.

Please tell me if I can provide more information.

dovecot -n:
===
# 1.2.4: /usr/local/etc/dovecot.conf
# OS: Linux 2.6.26-2-686 i686 Debian 5.0.2
log_timestamp: %Y-%m-%d %H:%M:%S
protocols: managesieve imap imaps pop3 pop3s
login_dir: /usr/local/var/run/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login
mail_access_groups: mail
mail_privileged_group: mail
mail_location: maildir:~/Maildir
mail_drop_priv_before_exec: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve
mail_plugins(default): autocreate acl
mail_plugins(imap): autocreate acl
mail_plugins(pop3):
mail_plugins(managesieve):
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve
namespace:
  type: public
  separator: .
  prefix: Public.
  location: 
maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public
  list: yes
namespace:
  type: private
  separator: .
  prefix: Backup.
  location: maildir:~/Maildir-backup
  hidden: yes
  list: no
namespace:
  type: private
  separator: .
  inbox: yes
  list: yes
  subscriptions: yes
lda:
  log_path:
  info_log_path:
  auth_socket_path: /var/run/dovecot/auth-master
  postmaster_address: postmas...@mailtest0.rise-s.com
  mail_plugins: sieve acl
auth default:
  mechanisms: plain login
  passdb:
driver: pam
  passdb:
driver: sql
args: /etc/dovecot/dovecot-sql.conf
  userdb:
driver: passwd
  userdb:
driver: static
args: uid=vmail gid=vmail home=/var/vmail/%Ld/%Ln allow_all_users=yes
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
master:
  path: /var/run/dovecot/auth-master
  mode: 384
  user: vmail
plugin:
  sieve: ~/.dovecot.sieve
  sieve_dir: ~/sieve
  sieve_global_path: /etc/dovecot/sieve/default.sieve
  sieve_global_dir: /etc/dovecot/sieve/global/
  sieve_before: /etc/dovecot/sieve/before/
  autocreate: Trash
  autocreate2: Drafts
  autocreate3: Sent
  autocreate4: INBOX.Spam
  autosubscribe: Trash
  autosubscribe2: Drafts
  autosubscribe3: Sent
  autosubscribe4: INBOX.Spam
  acl: vfile:/etc/dovecot/acl

Log entry:
==

Aug 28 01:08:01 mailtest0 dovecot: IMAP(andreas.ntaf...@example1.rise-s.com): 
Panic: file acl-backend-vfile.c: line 1124 (acl_backend_vfile_object_update): 
assertion failed: (!update->rights.global)
Aug 28 01:08:01 mailtest0 dovecot: IMAP(andreas.ntaf...@example1.rise-s.com): 
Raw backtrace: imap [0x80f1ec1] -> imap [0x80f1f42] -> imap [0x80f18c9] -> 
/usr/local/lib/dovecot/imap/lib01_acl_plugin.so [0xb7dddcf6] -> 
/usr/local/lib/dovecot/imap/lib01_acl_plugin.so(acl_object_update+0x18) 
[0xb7ddb1a8] -> /usr/local/lib/dovecot/imap/lib01_acl_plugin.so [0xb7de2ac7] -
> imap(cmd_create+0xf9) [0x80618d9] -> imap [0x80679fc] -> imap [0x8067a99] -> 
imap(client_handle_input+0x2d) [0x8067c0d] -> imap(client_input+0x5f) 
[0x806856f] -> imap(io_loop_handler_run+0xe0) [0x80fac40] -> 
imap(io_loop_run+0x20) [0x80fa0b0] -> imap(main+0x5ea) [0x807104a] -> 
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7e15455] -> imap 
[0x8060291]
Aug 28 01:08:01 mailtest0 dovecot: dovecot: child 1588 (imap) killed with 
signal 6 (core dumped)

Backtrace:
==

#0  0xb7f70424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7e2a640 in raise () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#2  0xb7e2c018 in abort () from /lib/i686/cmov/libc.so.6
No symbol table info available.
#3  0x080f1ed5 in default_fatal_finish (type=, status=0) 
at failures.c:160
backtrace = 0x93e5628 "imap [0x80f1ec1] -> imap [0x80f1f42] -> imap 
[0x80f18c9] -> /usr/local/lib/dovecot/imap/lib01_acl_plugin.so [0xb7dddcf6] -> 
/usr/local/lib/dovecot/imap/lib01_acl_plugin.so(acl_object_update+0x18) 
[0xb"...
#4  0x080f1f42 in i_internal_fatal_handler (type=LOG_TYPE_PANIC, status=0, 
fmt=0xb7de3094 "file %s: 

Re: [Dovecot] How do I get my mail from fetchmail into dovecot?

2009-05-01 Thread Andreas Ntaflos
On Friday 01 May 2009 00:33:49 Michael Steinbeck-Reeves wrote:
> Hi Andreas
>
> I sort of have it working but am still not quite there...
>
> I have created virtual users with homes under their mail folders
> (using mbox), as recommended in the Dovecot Wiki VirtualUsers
> section.

Hi, 

The examples I gave, and the setup I have running, are for system users 
with real accounts. I don't know how this would translate for virtual 
users although it should be doable. Unfortunately I don't have the 
possibility to create a test setup that matches yours at the moment so 
I'm afraid I don't think I can help you much more.

I'd try, however, to correct the errors the log files show you, and 
while you are at it, you might want to ditch mbox for Maildir, if you 
can afford to do so. I also think you should run Getmail as the vmail 
user in order to have an easier time with permissions, especially if 
you have a virtual domain hosting setup that involves Postfix (or any 
MTA, really) as well. 

Finally, you should head over to the Getmail mailing list and ask about 
using Getmail with virtual users there. Charles, the author of Getmail, 
is really helpful if you ask him the right questions the right way :)

Andreas 
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


Re: [Dovecot] How do I get my mail from fetchmail into dovecot?

2009-04-30 Thread Andreas Ntaflos
On Thursday 30 April 2009 12:22:17 Michael Steinbeck-Reeves wrote:
> > Message: 1
> > Date: Thu, 30 Apr 2009 00:27:46 +0200
> > From: Andreas Ntaflos 
> > Subject: Re: [Dovecot] How do I get my mail from fetchmail into
> > dovecot?
> >
> > > I have dovecot (with squirrel mail etc.) running without any
> > > problems but cannot understand how to get e-mail from a pop
> > > server into dovecot. I have fetchmail configured to pick up the
> > > mail from the pop3 server but don't understand how to get it from
> > > there into my dovecot mbox structure.
> >
> > My advice: forget Fetchmail and use Getmail [1] instead. Getmail
> > does everything Fetchmail does, only better. The documentation is
> > excellent, the author (and mailinglist) very responsive should you
> > run into problems you can't seem to solve on your own and I believe
> > there exist a number of HOWTOs on how to setup Getmail with
> > Dovecot. Not that it's very difficult, though.
>
> Thanks, I have changed over and your diagrams made it much more
> obvious what is actually going on.
>
> > I myself have such a "mail hamster" setup running just fine, which
> > I mentioned a few weeks ago on this list [2]. You might find that
> > post helpful.
> >
> > The general idea is to use Getmail to poll the remote mail servers
> > (I poll two POP servers and three IMAP-SSL servers), retrieve
> > messages, optionally scan them for viruses and spam and then hand
> > them over to your local Dovecot server using Dovecot's LDA
> > "deliver". See [3] for a nice picture :) If you skip virus and spam
> > scanning the configuration for a single remote IMAP server boils
> > down to:
> >
> > ~/.getmail/remote_imap_server.rc:
> >
> > [options]
> > verbose = 0
> > read_all = false
> >
> > [retriever]
> > type = SimpleIMAPSSLRetriever
> > server = address_of_remote_imap_server
> > username = username_on_remote_server
> > password = password_on_remote_server
> >
> > [destination]
> > type = MDA_external
> > path = /usr/local/libexec/dovecot/deliver
> >
> > The destination part tells getmail to call the "deliver" program
> > (without any commandline options) with the retrieved message.
> > Dovecot then does the rest.
>
> That seems simple - thanks.
>
> Do I just put a list of retrievers, one after the other with a single
> destination following that and let dovecot sort out the destinations?

Normally you have one RC file per remote server your want to poll, with 
each RC file looking quite like the example I gave. Create a cron job 
for Getmail to run periodically and tell it which RC files to use:

# Run every two minutes and get mail from the specified servers
*/2 * * * * /usr/bin/getmail \ 
--rcfile /home/daff/.getmail/dword.org.rc \
--rcfile /home/daff/.getmail/gmx.at.rc \
[...]

Refer to the Getmail docs for further info.

> The only thing I don't understand and can't find/understand in the
> documentation is how to tell the LDA where to put my e-mails. I have
> mails to several addresses mixed up in several POP3 boxes and need to
> sort them out and deliver them based on the target address. e.g.
> mich...@domain1 and mich...@domain2 go to my box etc. I can't see
> where I identify the addresses and allocate the appropriate storage
> area.

This is where Sieve shines. If you don't use Sieve then the LDA 
(deliver) will just put any messages handed to it by Getmail into your 
top-level INBOX. With Sieve you can specify rules and tell the LDA what 
to do with each message. You should read up on Sieve [1], Sieve in 
Dovecot [2] and Dovecot's LDA [3]. Once you configured the LDA to 
understand Sieve you can create rules like the following:

~/.dovecot.sieve:

# Messages from the Dovecot list end up in the IMAP folder
# INBOX.dword.dovecot-users
if header :contains ["List-Id"] 
["Dovecot Mailing List "] 
{
fileinto "INBOX.dword.dovecot-users";
stop;
}

# All messages addressed directly to me shall end up in
# the IMAP folder INBOX.dword
if header :matches ["to","cc","bcc"]
  ["*d...@dword.org*"]  
{
fileinto "INBOX.dword";
stop;
}

# Another account I have. Put those messages in 
# the IMAP folder INBOX.gmx.
if address :contains ["to","cc","bcc"] 
["my.addr...@gmx.at"] 
{
fileinto "INBOX.gmx";
stop;
}

Dovecot's Sieve support is excellent, thanks to Stephan Bosch. There is 
much more documentation out there than I can possibly provide or link 
to in this post but I think it gets the point across. 

Hope this helps :)

Andreas

[1] http://sieve.info/
[2] http://wiki.dovecot.org/LDA/Sieve
[3] http://wiki.dovecot.org/LDA
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


Re: [Dovecot] How do I get my mail from fetchmail into dovecot?

2009-04-29 Thread Andreas Ntaflos
On Wednesday 29 April 2009 15:46:05 Michael Steinbeck-Reeves wrote:
> I have dovecot (with squirrel mail etc.) running without any problems
> but cannot understand how to get e-mail from a pop server into
> dovecot. I have fetchmail configured to pick up the mail from the
> pop3 server but don't understand how to get it from there into my
> dovecot mbox structure.

My advice: forget Fetchmail and use Getmail [1] instead. Getmail does 
everything Fetchmail does, only better. The documentation is excellent, 
the author (and mailinglist) very responsive should you run into 
problems you can't seem to solve on your own and I believe there exist 
a number of HOWTOs on how to setup Getmail with Dovecot. Not that it's 
very difficult, though.

I myself have such a "mail hamster" setup running just fine, which I 
mentioned a few weeks ago on this list [2]. You might find that post 
helpful.

The general idea is to use Getmail to poll the remote mail servers (I 
poll two POP servers and three IMAP-SSL servers), retrieve messages, 
optionally scan them for viruses and spam and then hand them over to 
your local Dovecot server using Dovecot's LDA "deliver". See [3] for a 
nice picture :) If you skip virus and spam scanning the configuration 
for a single remote IMAP server boils down to:

~/.getmail/remote_imap_server.rc:

[options]
verbose = 0
read_all = false

[retriever]
type = SimpleIMAPSSLRetriever
server = address_of_remote_imap_server
username = username_on_remote_server
password = password_on_remote_server

[destination]
type = MDA_external
path = /usr/local/libexec/dovecot/deliver

The destination part tells getmail to call the "deliver" program 
(without any commandline options) with the retrieved message. Dovecot 
then does the rest.

HTH

Andreas

[1] http://pyropus.ca/software/getmail/
[2] http://dovecot.org/pipermail/dovecot/2009-March/038074.html
[3] http://img394.imageshack.us/img394/6148/mailhamster.png
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


Re: [Dovecot] General approach question - am I doing this the right way?

2009-03-13 Thread Andreas Ntaflos

Quoting Alan Bates :


Sure - I looked at sieve, but as i understood it, i'm bypassing any LDA
stage, using getmail to deliver direct to the maildir.

i suppose i could use getmail to deliver to a holding maildir, then use an
LDA to filter and deliver that mail...


Way too complicated. Or is there a reason you don't want to use  
Dovecot's LDA directly?


I use getmail, Dovecot's LDA and Sieve in a setup very much like the  
one you described and it couldn't work better. Have a look at the  
relevant section of a typical rc-file for getmail:


[destination]
type = MDA_external
path = /usr/local/libexec/dovecot/deliver

That's all that's needed. You especially don't need any command-line  
arguments when you deliver for local users. Also see my .dovecot.sieve:


if anyof (
header :contains ["Subject"] ["***Spam***"],
header :contains ["X-Spam-Flag"] ["YES"]
) {
# I discard spam immediately
discard;
stop;
}

if header :contains ["Subject"] ["[SPAM?]"] {
# File into spam when unsure
fileinto "INBOX.Spam";
stop;
}

This way getmail hands retrieved mail to Dovecot's LDA (deliver) which  
looks at the Sieve rules you have defined (if any) and puts the mail  
in the correct location in your Maildir. Simple and elegant.


This of course assumes that the LDA protocol is configured correctly  
in dovecot.conf and knows where to deliver the mail (basically set a  
correct mail_location). And you have to have support for Sieve  
compiled in and set up correctly, which I assume is the case for  
Ubuntu. Read up on LDA and Sieve on the Dovecot wiki pages for more  
information.


Hope I didn't forget anything. I find using getmail with Dovecot  
enjoyably easy. I generally find using Dovecot enjoyably easy but I  
don't think anyone would argue that point :)


HTH Andreas
--
Andreas Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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

2008-07-04 Thread Andreas Ntaflos
On Wednesday 02 July 2008 08:52:41 Andre Hübner wrote:
> Sometime it happens that 1 user out of x (more than 100) got this
> standardmessage  for ~1 or ~2 thousend times in his mailbox (mbox)
>
> for example:
> >From MAILER_DAEMON  Mon Sep 18 16:16:14 2006
>
> Date: Mon, 18 Sep 2006 16:16:14 +0200
> From: Mail System Internal Data <[EMAIL PROTECTED]>
> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
> Message-ID: [EMAIL PROTECTED]
> X-IMAP: 1158588973 001177
> Status: RO
>
> This text is part of the internal format of your mail folder, and is not
> a real message.  It is created automatically by the mail system software.
> If deleted, important folder data will be lost, and it will be re-created
> with the data reset to initial values.

I've seen messages such as these when using (older versions of) Horde IMP on a 
Cyrus server in conjunction with Thunderbird and POP3. Not sure how exactly 
they are created, but I think it had to do with logging in via the IMP web 
interface, then using Thunderbird, and after that logging in via web 
interface again.

Dovecot does not use mail messages to store folder meta-data as far as I know 
so I highly doubt this message was created by Dovecot (does Dovecot even send 
out messages except when going over quota?). Also notice the date of 
2006-09-18, which is almost two years in the past. The message was probably 
created by some client and was somehow (willingly) ignored or flagged as 
deleted. Could be that upgrading Dovecot to 1.1 made the message visible 
again for whatever reason. 

Anyway, this is most certainly not a Dovecot-internal message.

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


smime.p7s
Description: S/MIME cryptographic signature


Re: [Dovecot] How to deal with mail to unknown virtual recipients?

2008-04-18 Thread Andreas Ntaflos
On Friday 18 April 2008 18:56:08 Charles Marcus wrote:
> On 4/18/2008, Andreas Ntaflos ([EMAIL PROTECTED]) wrote:
> > Is there anything Dovecot itself can do to reject or handle mail to
> > invalid virtual users?
>
> Not directly - the solution, as you surmised, earlier, is to use the
> same db backend for your users.
>
> > Or does this situation *have* to be dealt with
> > earlier, by the MTA?
>
> Yes, it *must* be done at the MTA, otherwise you accept-then-bounce,
> which makes you a backscatter source, and will quickly get you
> blacklisted...

Charles, Ed, 

thank you very much for your insightful replies.

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] How to deal with mail to unknown virtual recipients?

2008-04-18 Thread Andreas Ntaflos
On Thursday 17 April 2008 23:50:40 mouss wrote:
> > But today I received spam mail (which was correctly identified as such by
> > amavisd-new) for "[EMAIL PROTECTED]" and "[EMAIL PROTECTED]", two
> > recipient addresses that do not exist. According to [1] "it's left up to
> > the non-Postfix delivery agent to reject non-existent recipients from
> > local submission or from local alias expansion."
>
> note that this is about local submission and local alias expansion. it
> is not about mail received from outside.
>
> > How to deal with such a situation?
>
> this is postfix issue. postfix will reject mail to invalid local and
> virtual users unless you rebak recipient validation. a common error is
> to use wildcard virtual aliases or wildcard canonical mapping.

Thank you for your reply! Reading through it and re-reading the Postfix 
documentation gave me the clue I needed. 

Unfortunately I forgot to mention that I didn't have a virtual_mailbox_maps 
directive defined in Postfix's main.cf, so Postfix couldn't know anything 
about which virtual recipients were valid and which weren't. Since that 
particular map was optional and everything worked fine during my tests (which 
didn't include sending mail to an invalid virtual recipient, shame on me) I 
quickly forgot about it.

Naturally that was the root of problem I was facing.

Defining a virtual_mailbox_maps file with all valid virtual users solves the 
problem in principle, however now I need to maintain two files with valid 
virtual users for valid virtual domains: the passwd-file for Dovecot 
(/etc/dovecot/passwd) plus the vmailbox file for Postfix 
(hash:/etc/postfix/vmailbox).

I suppose this is unavoidable when using flat files and would be better solved 
using a real database backend, but it makes me wonder if there really isn't 
anything Dovecot could do about this?

Seeing as Dovecot recognises when a virtual recipient is invalid, couldn't it 
somehow put the to-be-rejected mail back to Postfix (or whichever MTA)? Or 
should it just drop it? I don't know what the SMTP (whichevery protocol is to 
be followed here) says about this, so I pose the question again: 

Is there anything Dovecot itself can do to reject or handle mail to invalid 
virtual users? Or does this situation *have* to be dealt with earlier, by the 
MTA?

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] How to deal with mail to unknown virtual recipients?

2008-04-17 Thread Andreas Ntaflos
Hello list, 

I am not quite sure whether this is a questions for Dovecot or Postfix. I have 
set up, virtual hosting for one domain (for test purposes) using a 
passwd-file as passdb and a static userdb (see dovecot -n at the end) along 
with Postfix in a manner described in [1], i.e. a non-Postfix mail store. 
Other than that I also do hosting for the canonical domain which is for users 
with a regular Unix account on the system (looked up via PAM)

The virtual domain shall be "example.org", with two users "[EMAIL PROTECTED]" 
and "[EMAIL PROTECTED]". 

But today I received spam mail (which was correctly identified as such by 
amavisd-new) for "[EMAIL PROTECTED]" and "[EMAIL PROTECTED]", two recipient 
addresses that do not exist. According to [1] "it's left up to the 
non-Postfix delivery agent to reject non-existent recipients from local 
submission or from local alias expansion." 

How to deal with such a situation? 

The sender address was clearly forged so returning a failed delivery message 
is pointless. The messages are now hanging around in the queue with a status 
of "deferred: temporary failure". 

The logs show:

dovecot: auth(default): passwd([EMAIL PROTECTED]): unknown user
dovecot: auth(default): passwd-file([EMAIL PROTECTED]): unknown user
dovecot: auth(default): static([EMAIL PROTECTED]): passdb doesn't support 
lookups, can't verify user's existence

postfix/pipe[25328]: C7EA18BC0B5: to=<[EMAIL PROTECTED]>, relay=dovecot, 
delay=1.4, delays=0.07/0.02/0/1.3, dsn=4.3.0, status=deferred (temporary 
failure)

The dovecot relay is defined in /etc/postfix/master.cf:

dovecot unix - n n - - pipe
  flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f 
${sender} -d ${recipient}

The question, once again, is: what to do in such a situation? A catch-all 
address could be set up, but to what end? It would just catch a lot of spam 
over time. What is the correct way to deal with this? 

More importantly: is there even anything Dovecot could (or should) do? 

Thanks in advance, 

Andreas

[1] http://www.postfix.org/VIRTUAL_README.html#in_virtual_other

# 1.0.10: /usr/local/etc/dovecot.conf
base_dir: /var/run/dovecot/
protocols: imap imaps pop3 pop3s managesieve
listen(default): *
listen(imap): *
listen(pop3): *
listen(managesieve): *:2000
ssl_cert_file: /path/to/ssl_cert
ssl_key_file: /path/to/private_key
login_dir: /var/run/dovecot//login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login
mail_extra_groups: mail
mail_location: maildir:~/Maildir
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve
imap_client_workarounds(default): outlook-idle delay-newmail 
tb-extra-mailbox-sep
imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep
imap_client_workarounds(pop3): outlook-idle
imap_client_workarounds(managesieve): outlook-idle
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xu%08Xv
pop3_uidl_format(managesieve):
sieve_storage(default):
sieve_storage(imap):
sieve_storage(pop3):
sieve_storage(managesieve): ~/sieve
sieve(default):
sieve(imap):
sieve(pop3):
sieve(managesieve): ~/.dovecot.sieve
namespace:
  type: public
  separator: /
  prefix: Public/
  location: 
maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public
namespace:
  type: private
  separator: /
  inbox: yes
auth default:
  mechanisms: plain login
  verbose: yes
  passdb:
driver: passwd-file
args: /etc/dovecot/passwd
  passdb:
driver: pam
  userdb:
driver: passwd
  userdb:
driver: static
args: uid=vmail gid=vmail home=/home/vmail/%d/%u
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
master:
  path: /var/run/dovecot/auth-master
  mode: 432
  user: vmail
  group: vmail
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] dnotify inotify

2008-02-28 Thread Andreas Ntaflos
On Thursday 28 February 2008 14:20:14 Osvaldo Alvarez Pozo wrote:
> Hi, I am compiling dovecot and I found dnotify & inotify. What does
> dnotify or inotify  do ? do i need it.
> Thanks

Why not have a look at the Wikipedia articles on the topic and search onward 
from there if you want to know more?

http://en.wikipedia.org/wiki/Inotify
http://en.wikipedia.org/wiki/Dnotify (a stub)

HTH
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Put existing mails (in Maildir) through sieve filter?

2008-02-21 Thread Andreas Ntaflos
On Thursday 21 February 2008 17:23:04 Raphael Bittencourt S. Costa wrote:
> You can write a shell script to do this for you.
>
> cd ~/Maildir/cur
>
> for i in *; do /usr/local/libexec/dovecot/deliver  -d user < $i; rm -f
> $i; echo "Message $i"; done

Thanks for the reply! I had no idea it could be so easy :)

Much appreciated.

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Put existing mails (in Maildir) through sieve filter?

2008-02-21 Thread Andreas Ntaflos
Hello list, 

the scenario: A user has about 30k mails in his Maildir (all in INBOX) and 
needs to apply filtering. Provided he writes a working .dovecot.sieve script, 
is there a way to put all those already delivered mails through Dovecot's LDA 
and thus have the sieve filter rules applied? Or is there any other way to 
apply sieve rules to already delivered mails?

TIA

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Strange signal 11 crashes

2008-01-29 Thread Andreas Ntaflos
On Tuesday 29 January 2008 16:24:24 Mrten wrote:
> signal 11-s are often a sign of faulty hardware...
>
> have you tried compiling the linux kernel a few times with make -j4?

Off topic, but I have almost never been able to induce any errors by compiling 
the Linux kernel, no matter how faulty the hardware (RAM). Not using -j4 
though.

I found that compiling the zeroc-ice package (on Debian-based distros), which 
is huge, very reliably results in random crashes and aborts when relevant 
hardware is dying.

# apt-get source zeroc-ice
# cd zeroc-ice-?.?.?
# make
*blam*

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Create IMAP folders on first login?

2008-01-22 Thread Andreas Ntaflos
On Tuesday 22 January 2008 23:24:59 Andreas Schneider wrote:
> Andreas Ntaflos wrote:
> > On trying things out with different newly created virtual users I
> > wondered if it was possible for Dovecot to create certain IMAP folders on
> > the first login of the user? So that folders such "Drafts", "Sent" and
> > "Trash" are created automatically for each new user (upon login).
> >
> > Or is this a job for the mail client, or for the admin who creates the
> > new users?
>
> Hi,
>
> use the autocreate plugin Timo wrote. Search the archive if you don't find
> the source.

Thanks a lot, found it!

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Create IMAP folders on first login?

2008-01-22 Thread Andreas Ntaflos
Hello list, 

I am currently playing around with a virtual domain/virtual user setup and 
thanks to the documentation on both the Dovecot and the Postfix websites 
things are going swimmingly (apart from an oddity I will post separately 
about). 

On trying things out with different newly created virtual users I wondered if 
it was possible for Dovecot to create certain IMAP folders on the first login 
of the user? So that folders such "Drafts", "Sent" and "Trash" are created 
automatically for each new user (upon login).

Or is this a job for the mail client, or for the admin who creates the new 
users?

TIA!

Andreas
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Using deliver from Getmail [solved]

2008-01-20 Thread Andreas Ntaflos
On Monday 14 January 2008 16:23:03 Andreas Ntaflos wrote:
> Hello list,
>
> a quick question: can I use Dovecot's LDA "deliver" as a destination in
> Getmail? I.e.:
>
> [destination]
> type = MDA_external
> path = /usr/local/libexec/dovecot/deliver
> arguments = ("-d", "username",)

Hello list, 

as a followup, (with an additional question which I probably should post as a 
separate message) I think I have found the solution.

But to clarify: I am /not/ using a virtual user/virtual domain setup, all 
users have shell accounts and home directories. The server only hosts two 
domains (set in $mydestination in Postfix) and I use Dovecot with a 
simple "userdb passwd" setup, as seen in dovecot -n at the end.

Postfix uses Dovecot's LDA deliver to deliver incoming messages for the two 
hosted domains, as described in [1], via 

mailbox_command = /usr/local/libexec/dovecot/deliver

This seems to be the same as unsetting mailbox_command and instead creating a 
~/.forward file in each home directory, with the contents

| "/usr/local/libexec/dovecot/deliver"

so deliver gets called by the user itself (thus no permission problems). 
Either method seems to work, producing the same results.

To have Getmail use Dovecot's deliver I simply had to set the [destination] 
section in the rc-file to:

[destination]
type = MDA_external
path = /usr/local/libexec/dovecot/deliver

which seems to do the trick. No arguments required. Mail fetched by Getmail 
gets handed to deliver which then puts it in the users inbox. I just had to 
rewrite some of my ~/.dovecot.sieve, but that's specific to my setup/site.

So thanks for all the input and help in this and the other [2] thread! Really 
appreciated!

Andreas

[1] http://wiki.dovecot.org/LDA/Postfix
[2] http://thread.gmane.org/gmane.mail.imap.dovecot/27076
-- 
Andreas Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] deliver can't connect to auth server a t */usr/local*/var/run/dovecot/auth-master

2008-01-15 Thread Andreas Ntaflos
On Tuesday 15 January 2008 03:00:50 Charles Marcus wrote:
> On 1/14/2008 Andreas Ntaflos wrote:
> > Notice how it says "/usr/local/var/run/dovecot"! How and why does
> > dovecot
> > ^^
> > think that anything of any importance can be found under
> > /usr/local/var/... ?
>
> I'm confused as to why *you're* confused...
>
> Look at the output again...
>
> ALL of your binaries paths are set to:
>
> /usr/local/var/...

Thanks for your reply!

But I think you misread that, not a single parameter is set to /usr/local/var. 
The installation prefix (configure --prefix) is set to /usr/local but the 
local state directory, which is supposed to be /var is really set to /var 
(this is also the default when running configure). The configuration also 
specified that Dovecot run out of /var/run/dovecot (base_dir).

So naturally I had no idea where Dovecot would take that /usr/local prefix to 
the /var directory, and I really still don't.

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master

2008-01-15 Thread Andreas Ntaflos
On Tuesday 15 January 2008 03:56:28 Jerry Yeager wrote:
> > while fiddling around with the configuration so Dovecot's LDA
> > "deliver" can be
> > used by multiple users by means of Getmail (you can read about that
> > in [1]) I
> > always end up running into the error message posted in the subject
> > line:
> >
> > Jan 15 00:00:02 HOSTNAME deliver(USERID): Can't connect to auth server
> > at /usr/local/var/run/dovecot/auth-master: Permission denied
> >
> > Notice how it says "/usr/local/var/run/dovecot"! How and why does
> > dovecot
> >^^
> > think that anything of any importance can be found under /usr/local/
> > var/... ?
> > Please see dovecot -n at the end of this message, but as far as I
> > can tell I
> >
> >master:
> >  path: /var/run/dovecot/auth-master
> >  mode: 432
> >  user: root
> >  group: dovecot
>
> For the quick answer to your immediate problem / question, try:
>
> cd /path/to/dovecot's/deliver (probably   
> /usr/local/libexec/dovecot/  )
>
> chmod u+s deliver
>
> (enable the setuid bit for the deliver app). Your Getmail app may not
> be truly running as root and thus does not really have permission to
> do what you want.
>
> you may need to do the same for the group as well

Thank you as well for the reply! :)

Chmod'ing deliver really was a step forward in the right direction, although, 
as I mentioned elsewhere in this thread, I did not quite get the 
configuration right so a few messages from this and other mailing lists 
bounced because deliver wasn't called correctly. Still trying to figure that 
out. 

> Unix permissions are weird sometimes, like a $100 television tube that
> protects a 50 cent fuse by blowing first.

Really great analogy :) I never had a problem with understanding Unix 
permissions, but things seem to get complicated when you try to make 
different parts of a mail system running smoothly together.

> It does look like (from your use of /usr/local/*) you built
> dovecot to run out of /usr/local.

No, I really didn't (as far as I can tell). The installation prefix 
is /usr/local, yes, but Dovecot runs out of /var/run/dovecot. But apparently 
the auth_socket_path for protocol lda defaults to /usr/local/var/run/dovecot, 
a parameter I'm still not sure what I need it for.

> One last thing, as a security idea, try something like
>
>   master {
> path = /usr/local/var/run/dovecot/auth-master
> mode = 0600
> user = dovecot_user
> group = dovecot_group
>   }
>
> and set your postfix line that calls deliver to match:
>
>   dovecot unix - n n - - pipe flags=DRhu
> user=dovecot_user:dovecot_group argv=/usr/local/libexec/dovecot/
> deliver -f ${sender} -d ${recipient}

Thanks for this suggestion! But that would imply that I have a virtual user 
setup, wouldn't it? Because I don't, all my users are regular Unix users with 
shell accounts. That's why my Postfix main.cf contains just

home_mailbox = Maildir/
mailbox_command = /usr/local/libexec/dovecot/deliver

which is also what the LDA/Postfix wiki page says on wiki.dovecot.org. No 
Dovecot entry in master.cf at all.

And, as also mentioned elsewhere in this thread, until yesterday I didn't even 
have the master { ... } section uncommented, and no auth-master socket seems 
to have been configured. But then again I only delivered through Postfix and 
didn't need to have deliver called by a regular user.

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] deliver can't connect to auth server at * /usr/local*/var/run/dovecot/auth-master

2008-01-15 Thread Andreas Ntaflos
On Tuesday 15 January 2008 05:24:58 Timo Sirainen wrote:
> On Tue, 2008-01-15 at 00:21 +0100, Andreas Ntaflos wrote:
> > Notice how it says "/usr/local/var/run/dovecot"! How and why does dovecot
>
> ..
>
> > master:
> >   path: /var/run/dovecot/auth-master
>
> If you're not using the default built-in path, set:
>
> protocol lda {
>   auth_socket_path = /var/run/dovecot/auth-master
> }

Thanks for your reply, too!

So does this mean that auth_socket_path is by default set 
to /usr/local/var/run/dovecot/auth-master? And I have to set that parameter 
explicitly to /var/run/dovecot/auth-master?

I am a little confused. Why are there two places to set the path to the 
authentication master socket? Do I need to set both? Until yesterday, when I 
started experimenting, I hadn't even uncommented the "master { ... }" section 
under "socket listen { ... }", I just used the client so Postfix could do 
SMTP authentication lookups, as you can see from dovecot -n.

Andreas

P.S.: As you could probably tell some messages from this list bounced from my 
mailserver when I tried to get the configuration right (which I didn't :)). I 
apologise for that.
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Using deliver from Getmail?

2008-01-14 Thread Andreas Ntaflos
On Monday 14 January 2008 22:15:48 mouss wrote:
> Andreas Ntaflos wrote:
> > On Monday 14 January 2008 18:47:27 Evaggelos Balaskas wrote:
> >> This is part of my getmailrc
> >>
> >> [destination]
> >> type = MDA_external
> >> path = /usr/local/libexec/dovecot/deliver
> >> user = ebal
> >> group = mail
> >> arguments = ( '-d', 'ebal' )
> >>
> >> i use getmail + dovecot + sieve + spamassassin [filter getmail]
> >> at all of my accounts.
> >
> > I can't seem to be too far off with my configuration, but it's just not
> > working yet. Your user "ebal" is part of the group "mail", I gather?
>
> I don't think this matters. he runs deliver as the user who owns the
> mailbox (see -d argument).

Does that mean that one, and only one, user may be running deliver manually 
(or from Getmail) to get his mail? This would make it quite impossible for a 
server with multiple real system users to use Getmail and deliver mail via 
Dovecot's LDA, wouldn't it?

Or am I not seeing the obvious solution to this problem?

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] deliver can't connect to auth server at */usr/local*/var/run/dovecot/auth-master

2008-01-14 Thread Andreas Ntaflos
Hello list, 

while fiddling around with the configuration so Dovecot's LDA "deliver" can be 
used by multiple users by means of Getmail (you can read about that in [1]) I 
always end up running into the error message posted in the subject line:

Jan 15 00:00:02 HOSTNAME deliver(USERID): Can't connect to auth server 
at /usr/local/var/run/dovecot/auth-master: Permission denied

Notice how it says "/usr/local/var/run/dovecot"! How and why does dovecot 
^^
think that anything of any importance can be found under /usr/local/var/... ? 
Please see dovecot -n at the end of this message, but as far as I can tell I 
never ever specified that the /var directory (configure --localstatedir) 
should end up under the prefix /usr/local.

Now I am quite sure that my configuration for auth-master is not yet quite 
correct but I can't go any further without asking what this error message 
could mean and how to resolve the problem.

Anybody have any ideas? I am currently running 1.0.10 (previously, until this 
afternoon 1.0.5, same problem) with the latest MANAGESIEVE patch (v9) applied 
and the dovecot-sieve plugin.

TIA for any hints! I am at a loss here.

Andreas

[1] http://thread.gmane.org/gmane.mail.imap.dovecot/27062

# 1.0.10: /usr/local/etc/dovecot.conf
base_dir: /var/run/dovecot/
protocols: imap imaps pop3 pop3s managesieve
listen(default): *
listen(imap): *
listen(pop3): *
listen(managesieve): *:2000
ssl_cert_file: /etc/ssl/certs/DOMAINNAME.crt
ssl_key_file: /etc/ssl/private/DOMAINNAME.key
login_dir: /var/run/dovecot//login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login
mail_extra_groups: mail
mail_location: maildir:~/Maildir
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve
imap_client_workarounds(default): outlook-idle delay-newmail 
tb-extra-mailbox-sep
imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep
imap_client_workarounds(pop3): outlook-idle
imap_client_workarounds(managesieve): outlook-idle
pop3_uidl_format(default):
pop3_uidl_format(imap):
pop3_uidl_format(pop3): %08Xu%08Xv
pop3_uidl_format(managesieve):
namespace:
  type: public
  separator: /
  prefix: Public/
  location: 
maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public
namespace:
  type: private
  separator: /
  inbox: yes
auth default:
  mechanisms: login plain
  verbose: yes
  passdb:
driver: pam
  userdb:
driver: passwd
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
master:
  path: /var/run/dovecot/auth-master
  mode: 432
  user: root
  group: dovecot
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Using deliver from Getmail?

2008-01-14 Thread Andreas Ntaflos
On Monday 14 January 2008 19:10:10 Andreas Ntaflos wrote:
> On Monday 14 January 2008 18:47:27 Evaggelos Balaskas wrote:
> > This is part of my getmailrc
> >
> > [destination]
> > type = MDA_external
> > path = /usr/local/libexec/dovecot/deliver
> > user = ebal
> > group = mail
> > arguments = ( '-d', 'ebal' )
> >
> > i use getmail + dovecot + sieve + spamassassin [filter getmail]
> > at all of my accounts.

Follow-up: How did you configure Dovecot's authentication facilities and which 
permissions are set for the deliver binary?

I think that is the problem I am having. I do not want to mess too much with 
the default permissions but since you have it running fine maybe you could 
share some insight?

Thanks in advance!

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Using deliver from Getmail?

2008-01-14 Thread Andreas Ntaflos
On Monday 14 January 2008 18:47:27 Evaggelos Balaskas wrote:
> This is part of my getmailrc
>
> [destination]
> type = MDA_external
> path = /usr/local/libexec/dovecot/deliver
> user = ebal
> group = mail
> arguments = ( '-d', 'ebal' )
>
> i use getmail + dovecot + sieve + spamassassin [filter getmail]
> at all of my accounts.

Thank you for your reply!

I can't seem to be too far off with my configuration, but it's just not 
working yet. Your user "ebal" is part of the group "mail", I gather? 

After adding my user to the mail group and modifying my rc-file such that it 
looks identical to yours (apart from the usernames of course) I still get the 
following errors:

Delivery error (command deliver 29175 error (127, exec of command deliver 
failed (change UID/GID to 1000/8 failed ([Errno 1] Operation not 
permitted

UID 1000 is of course my user. Upon removing the line "group = mail" from the 
rc-file I get:

Delivery error (command deliver 29696 error (75, ))

Do you know what to make of this?

Thanks again, 

Andreas
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Using deliver from Getmail?

2008-01-14 Thread Andreas Ntaflos
Hello list, 

a quick question: can I use Dovecot's LDA "deliver" as a destination in 
Getmail? I.e.:

[destination]
type = MDA_external
path = /usr/local/libexec/dovecot/deliver
arguments = ("-d", "username",)

Or is deliver not supposed to be called this way? 

What I'd like to do is use deliver in the same way I would have used procmail 
ages ago. Getmail retrieves the mail messages, filters them according to the 
filter sections set up and then puts them in the final destination as noted 
above.

Of course I would like to have deliver honour my .dovecot.sieve sieve script. 
My first tries have not been very successful, all messages retrieved in this 
way are put in the top level INBOX, not being sieved. 

I also got this error message, but I am not sure how it is related:

Jan 14 16:08:04 localhost deliver(username): 
net_connect(/usr/local/var/run/dovecot/auth-master) failed: Permission denied

Does my user need any special permissions to use the LDA?

TIA!

Andreas

P.S.: Using Dovecot 1.0.5 with the Sieve plugin. I can post the output of 
dovecot -n but I don't think it's necessary?
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] deliver and namespaces in 1.1

2007-11-18 Thread Andreas Ntaflos
On Sunday 18 November 2007 13:10:32 Nikolay Shopik wrote:
> > Namespaces are supported everywhere now.
>
> Does this means what we can finally use "deliver" to deliver messages in
> namespaces?

Sorry to sound ignorant, but what /does/ it mean to deliver messages in 
namespaces? What would be a typical scenario for that?

Andreas
-- 
Andreas "daff" Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2 [FIXED KMail]

2007-08-08 Thread Andreas Ntaflos
On Monday 06 August 2007 17:53:56 Stephan Bosch wrote:
> Hi Andreas,
>
> Stephan Bosch wrote:
> > I submitted the patch to the kdepim mailinglist and I hope they will
> > merge it into their future releases to definitively resolve these 
issues.
>
> The patch is committed to kde-3.5.8 and kde-4.0. So, these releases
> should no longer have the presented problems. However, the kde sieve
> code is unmaintained at the moment and other problems exist. I'm
> contemplating fixing the kde sieve code towards managesieve
> specification conformance. So, if you find other problems, you can
> report them to me or to the kde-pim bugtracker (if you are sure it is
> KDE/KMail-related).

Stephan, 

thank you so much for taking the time to track this problem down and 
even supply a fix to the KDE developers. I am very much looking forward 
to 3.5.8 (i.e. KMail 1.9.8) and to hopefully finally being able to edit 
my sieve scripts without having to ssh into the mailserver.

Again, thank you!
-- 
Andreas "daff" Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2

2007-08-01 Thread Andreas Ntaflos
On Wednesday 01 August 2007 17:53:16 Stephan Bosch wrote:
> Hi Andreas,
>
> On Wed, 2007-08-01 at 16:45 +0200, Stephan Bosch wrote:
> > Most likely the problem relates to the fact that, unless configured
> > otherwise, dovecot will refuse to use plain text SASL mechanisms if the
> > connection is not encrypted. I haven't re-tested the STARTTLS command in
> > the last versions... I will give it a go.
>
> I gave it a go and STARTTLS still seems to work fine at my end. This
> test was performed using 'disable_plaintext_auth = yes' in the config
> file, forcing a _remote_ host to use TLS/SSL for all protocols.

Thanks for taking the time to investigate this further! I will try to provide 
you with everything I can.

I have my server configured the same way, allowing only TLS connections for 
plaintext login on the standard IMAP port 143. I shall attach the output of 
dovecot -n.

> The gnutls-cli tool is very useful to test the STARTTLS command in
> various protocols. Using the --starttls switch the client starts in
> plaintext mode and starts the TLS negotiation when Ctrl-D is pressed.
>
> With the information you provide I could test it with your setup, but of
> course you can test it yourself as well.

I got this working just fine, using the method you described below. Of course 
I had to base64-encode the "username\0username\0password" string first, which 
is probably not so obvious to someone who doesn't have much experience 
debugging authentication problems :)

I am using KMail 1.9.7 and KDE 3.5.7 to connect to the server (KDE has a 
kioslave for sieve). 

But seeing that connecting and authenticating worked fine with gnutls-cli this 
seems to be a KMail- oder KDE-related problem?

Is there anything else I can provide? How do you want the connection log? As 
the output of a tcpdump session? 

Thanks again!

Andreas

# 1.0.2: /usr/local/etc/dovecot.conf
base_dir: /var/run/dovecot/
protocols: imap managesieve
listen(default): *
listen(imap): *
listen(managesieve): *:2000
ssl_cert_file: /etc/ssl/certs/pseudoterminal.org_dovecot.crt
ssl_key_file: /etc/ssl/private/pseudoterminal.org.key
login_dir(default): /var/run/dovecot//login
login_dir(imap): /var/run/dovecot//login
login_dir(managesieve): login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login
mail_extra_groups: mail
mail_location: maildir:~/Maildir
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve
imap_client_workarounds(default): outlook-idle delay-newmail 
tb-extra-mailbox-sep
imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep
imap_client_workarounds(managesieve): outlook-idle
namespace:
  type: public
  separator: /
  prefix: Public/
  location: 
maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public
namespace:
  type: private
  separator: /
  inbox: yes
auth default:
  mechanisms: plain login
  passdb:
driver: pam
  userdb:
driver: passwd
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix

-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] MANAGESIEVE patch v5 for dovecot 1.0.2

2007-08-01 Thread Andreas Ntaflos
On Tuesday 31 July 2007 01:41:11 Stephan Bosch wrote:
> Have fun testing the patch. Notify me when there are problems.

Hello Stephan, 

I still get the following message when trying to connect and authenticate:

Choose a different authentication method to PLAIN.

The same with LOGIN when I tell Dovecot to use the login authentication 
method. The logs show:

Aug  1 15:25:52 hostname dovecot: managesieve-login: Login: user=, 
method=PLAIN, rip=aa.bb.cc.dd, lip=ww.xx.yy.zz, TLS
Aug  1 15:25:52 hostname dovecot: MANAGESIEVE(username): Disconnected: Logged 
out

I am using real Unix users and Dovecot is configured with authdb pam and 
userdb passwd. I previously described the problem in [1].

Does your patch not support PLAIN or LOGIN or am I missing something?

TIA

Andreas

[1] http://www.dovecot.org/list/dovecot/2007-June/023283.html
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


[Dovecot] Shared mailboxes (maildir, symlinks) and permissions

2007-07-27 Thread Andreas Ntaflos
Hello list, 

I am trying to set up a public mailbox for users to put spam in so that 
sa-learn can do its job at night. Only I can't seem to fully understand how 
and which permissions should be set. I've read [1] and am using Dovecot 
1.0.1.

First some background information: I do not host or care (at the moment) about 
virtual users or virtual mail hosting. All users have Unix system accounts 
and shell access. I'd like to have a Spam folder, say /var/mail/public/.Spam 
that is a maildir where users can put Spam that got through the server-side 
filter. Spamassassin's sa-learn runs nightly and learns from the contents of 
the Spam folder.

After reading [1] I think I should have under /var/mail/public a file called 
dovecot-shared that belongs to root:mail and has permissions 0660 (with user 
dovecot being a member of group mail) so that it looks like this:

[EMAIL PROTECTED]:/var/mail/public# ls
drwxr-sr-x 2 root mail 4096 2007-07-28 03:29 .
drwxrwsr-x 3 root mail 4096 2007-07-28 02:19 ..
-rw-rw 1 root mail0 2007-07-28 02:46 dovecot-shared
[EMAIL PROTECTED]:/var/mail/public#

The first question arises: should Dovecot have write access 
to /var/mail/public itself?

Now I should create the Spam folder called /var/mail/public/.Spam. Should this 
directory be in maildir format, i.e. should it already contain the 
subdirectories cur, tmp and new? What of the permissions of this directory? I 
am pretty sure Dovecot needs write access to it, so it should look like this:

[EMAIL PROTECTED]:/var/mail/public# ls
drwxr-sr-x 3 root mail 4096 2007-07-28 03:44 .
drwxrwsr-x 3 root mail 4096 2007-07-28 02:19 ..
-rw-rw 1 root mail0 2007-07-28 02:46 dovecot-shared
drwxrwsr-x 2 root mail 4096 2007-07-28 03:44 .Spam
[EMAIL PROTECTED]:/var/mail/public#

The .Spam directory here is completely empty.

Now in a user's Maildir (/home/user1/Maildir) there are the user's private 
folders; a symlink to /var/mail/public/.Spam should be added:

[EMAIL PROTECTED]:/home/user1/Maildir# ln -s /var/mail/public/.Spam .
[EMAIL PROTECTED]:/home/user1/Maildir# ls
...
drwx--  5 user1 user1 4096 2007-07-19 16:14 .INBOX.foo
drwx--  5 user1 user1 4096 2007-07-06 23:01 .INBOX.bar
...
lrwxrwxrwx  1 user1 user1  22 2007-07-28 03:51 .Spam -> /var/mail/public/.Spam
...
[EMAIL PROTECTED]:/home/user1/Maildir#

Is that all I have to do? Probably not, because I keep getting errors like the 
following when connecting (after subscribing of course):

Jul 28 03:52:35 host dovecot: IMAP(user1): 
mkdir(/home/user1/Maildir/.Spam/cur) failed: Permission denied

Should I have created the cur, tmp and new subdirectories manually and set 
their permissions like /var/mail/public/.Spam? But that still wouldn't give 
user1 write access. If I gave the users (or "others": chmod o+w) write 
permissions then Dovecot's index files would be owned by the first user that 
connects to the server and uses that folder. Apparently also not a solution. 
I also don't think I should have to make my users members of the mail group, 
but I could be wrong here.

So I am not sure what I am missing, or if what I want to do is at all possible 
(without taking out the sledgehammer and setting all permissions to 0777). I 
also apologise for this lengthy post with many details and little interesting 
questions. It's getting late and I fear I've reached a dead end.

I'd really appreciate it if someone knowledgeable could point me in the right 
direction here.

Thanks in advance!

Andreas

[1] http://wiki.dovecot.org/SharedMailboxes
-- 
Andreas "daff" Ntaflos
Vienna, Austria

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


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


Re: [Dovecot] Latest MANAGESIEVE patch -- how to start daemon?

2007-06-06 Thread Andreas Ntaflos
On Wednesday 06 June 2007 10:00:57 Joseba Torre wrote:
> Hi,
>
> first of all: there's a newer version of the patch
>
>http://sinas.rename-it.nl/~sirius/dovecot-1.0.rc28-MANAGESIEVE-v4.diff.gz

Hi and thanks for the reply! 

> Second: which were your steps for compilation? (patch, configure,
> make, make install, or what did you between patch and configure?)

I applied the v4 patch, which worked fine, but I had to re-autogenize 
the whole project before configure would create the new Makefiles, i.e. 
aclocal, libtoolize, autoheader, automake, autoconf.

That was the problem in the first place, managesieve support wouldn't be 
compiled at all, so no binaries to run.

> Third: you must tell dovecot that it should use a new protocol,
> managesieve. So, in dovecot.conf you need
>
> protocols = imap imaps pop3 pop3s managesieve
>
> and later
>
> protocol managesieve {
>   listen = *:2000
>   login_executable = /usr/local/libexec/dovecot/managesieve-login
>   mail_executable = /usr/local/libexec/dovecot/managesieve
> }

Thanks for that hint! Now the daemon seems to start fine and listens on 
port 2000. 

The problem I am having now is that it won't authenticate me, saying:

"Choose a different authentication method to PLAIN. is not supported.".

I am using a real unix user on the server, with .dovecot.sieve in a real 
home directory and PAM authentication (passdb: driver PAM and userdb: 
driver passwd), but this doesn't seem to be supported? Is there a way 
to get this to work or am I out of luck? Also see dovecot -n at the end 
of this message.

Thanks in advance!

Andreas

dovecot -n:

protocols: imap imaps managesieve
listen(default): *
listen(imap): *
listen(managesieve): *:2000
disable_plaintext_auth: no
login_dir(default): /usr/local/var/run/dovecot/login
login_dir(imap): /usr/local/var/run/dovecot/login
login_dir(managesieve): login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login
login_process_size: 64
valid_chroot_dirs: ~/.maildir/
verbose_proctitle: yes
first_valid_gid: 0
mail_extra_groups: mail
default_mail_env: maildir:~/.maildir/
mail_location(default): maildir:~/.maildir/
mail_location(imap): maildir:~/.maildir/
mail_location(managesieve):
maildir_copy_with_hardlinks: yes
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve
imap_client_workarounds(default): delay-newmail outlook-idle 
netscape-eoh tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh 
tb-extra-mailbox-sep
imap_client_workarounds(managesieve): outlook-idle
auth default:
  verbose: yes
  passdb:
driver: pam
  userdb:
driver: passwd

-- 
Andreas "daff" Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


pgpr2ac4Repho.pgp
Description: PGP signature


[Dovecot] Latest MANAGESIEVE patch -- how to start daemon?

2007-06-05 Thread Andreas Ntaflos
Hello list, 

I'm using Dovecot 1.0.0 on FreeBSD 6.2-RELEASE and applied the latest 
MANAGESIEVE patch v3 [1] which seems to have worked smoothly, i.e. all 
hunks succeeded and no compilation problems.

Now this may be stupid question with an obvious answer, but I am at a 
loss at how to start the daemon? What's the binary called that starts 
the sieve server? Is there a special way to invoke it? I haven't been 
able to find anything useful on that matter and there doesn't seem to 
be a TFM to R yet, the Wiki just links to [1].

What do I have to do? Did I forgot to patch something?

I'd appreciate any insight on this subject!

Thanks in advance!

Andreas

[1] http://dovecot.org/list/dovecot/2007-March/021130.html
-- 
Andreas "daff" Ntaflos 
Vienna, Austria 

GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC  7E65 397C E2A8 090C A9B4


pgp3wSZqlhDQp.pgp
Description: PGP signature