Re: [Dovecot] deliver vs lda

2009-04-08 Thread Tom Metro

Daniel L. Miller wrote:
deliver has nothing to do with the listening daemons.  So having the 
lda configuration in the dovecot.conf file might be inappropriate - I 
would suggest splitting that off to a dovecot-lda.conf file (or 
whatever you change the delivery agent name to).


I found the combination of configuration for IMAP and LDA to be a bit 
unnatural as well, with little to no overlap between the two. And so I 
ended up splitting them up so that I could have each logging to 
different places (IMAP to its own file, as it doesn't relate to mail 
delivery), and their own base_dir.


I also created a separate init script (or more accurately, modified the 
stock Debian init script so that I cold symlink to it, and it would load 
a matching config from /etc/defaults to get the non-default config file 
used by deliver).



Timo Sirainen wrote:

...inside protocol lda {} it can also override all settings from
dovecot.conf.


I might not have been aware of that at the time I set up deliver, or ran 
into complications with it. I don't recall. In any case, I prefer the 
logical separation. Delivery and access are related, but still quite 
separate functions.


 -Tom



Re: [Dovecot] different auth config for LDA

2009-04-08 Thread Tom Metro

Timo Sirainen wrote:

deliver doesn't use base_dir at all.


Hmmm...looks like it came about due to needing a different 
authentication configuration between IMAP and deliver, which led to a 
different auth process and necessitated a separate base_dir. The two run 
directories are clearly different, and both used:


/var/run/dovecot:
auth-worker.25176=  dict-server=login/  master.pid 



/var/run/dovecot-deliver:
auth-master=auth-worker.13452=  dict-server=login/ 
master.pid



Perhaps there's a way to do that within a single config file.

 -Tom


Re: [Dovecot] deliver vs lda

2009-04-07 Thread Tom Metro

Timo Sirainen wrote:

deliver is the binary name.

a) deliver binary, protocol deliver {}


The problem I have with the deliver name in general is that there is a 
pre-existing LDA project[1] with the same name, and even within the 
scope of the Dovecot mailing list, it isn't a unique term, so it makes 
it harder to sift out information specific to the LDA sub-project.


1. http://packages.debian.org/etch/deliver



c) dovecot-lda binary, protocol lda {}


This gets my vote. (Assuming Dovecot-lda replaces the deliver name 
in the documentation, as well.)




c) and e) choices also makes me think if e.g. imap and imap-login should
be called dovecot-imap and dovecot-imap-login instead. People have had
trouble finding them since ps|grep dovecot doesn't find them..


Agreed.

 -Tom


[Dovecot] Dovecot LDA and address extensions

2007-05-23 Thread Tom Metro
I'm converting over a virtual user installation that used Postfix and 
maildrop with a MySQL back-end for mailbox lookups to use Dovecot LDA. 
The maildrop setup used a database table like:


+-++-++
| address | owner  | domain  | mailbox|
+-++-++
| [EMAIL PROTECTED]  | tmetro | example.com | .admin.postmaster/ |
| [EMAIL PROTECTED]| tmetro | example.com | .admin.root.lex/   |
| [EMAIL PROTECTED]  | tmetro | example.com | .INBOX/|
| [EMAIL PROTECTED] | tmetro | example.com | .spam.tmetro/  |
[...]


where maildrop was handed ${recipient} from postfix, and it queries the 
above table matching ${recipient} to the address column, getting back 
the expression CONCAT_WS('/','/var/mail',domain,owner) as the home 
directory, and CONCAT_WS('/','/var/mail',domain,owner,mailbox) as the 
mailbox. The UID/GID are fixed, as this is a virtual user setup.


So looking up the mailbox for the user [EMAIL PROTECTED] returns:
/var/mail/example.com/tmetro/.admin.postmaster/

Currently I'm using a static user database with Dovecot. This SQL 
appears to replicate the maildrop setup:

user_query = SELECT CONCAT_WS('/','/var/mail',domain,owner) as home,
CONCAT_WS('/','maildir:/var/mail',domain,owner,mailbox) as mail,
5000 as uid, 5000 as gid FROM vmbx2 WHERE userid = '%u'

And this works for mail deliveries.

The problem with this is that not only is a database lookup overkill for 
the IMAP server, as the root mail location for IMAP users follows a 
simple pattern adequately represented by the static userdb, it also 
breaks IMAP, because the returned 'mail' overrides mail_location, 
(currently set to maildir:/var/mail/%d/%n/), so for user 
[EMAIL PROTECTED] it returns:

maildir:/var/mail/example.com/tmetro/.INBOX/

instead of:
maildir:/var/mail/example.com/tmetro/

(which is the same as the home directory).

Can the userdb sql directive be added to the protocol lda section? 
Or perhaps instead create a new auth lda section, and move the userdb 
sql and socket listen directives to that section?



The second issue is how to best deal with address extensions, something 
that wasn't fully implemented in the maildrop setup. Ideally I'd like a 
setup where a lookup is first performed for [EMAIL PROTECTED], and if it 
fails to return a mailbox, then lookup [EMAIL PROTECTED] Assuming Dovecot can 
handle a multi-row query result (grabbing the first record and ignoring 
the rest), this can probably be hacked using an appropriate WHERE 
expression.


But the difficulty is getting the address components. Postfix will 
provide them, but Dovecot's deliver doesn't seem to have a way of 
receiving them and passing them on to the user query. The example LDA 
setup shown here:

http://wiki.dovecot.org/LDA/Postfix

suggests passing the extension as an argument to the mailbox (-m) 
switch. But this assumes that one wants a one-to-one direct mapping 
between extensions and mailbox names.


I suppose I could switch from:
-d [EMAIL PROTECTED]
 to:
-d ${recipient}
and add even more complexity to the SQL to parse out the extension. But 
I'd rather avoid embedding the extension separator character in the SQL, 
and would rather eliminate it from the database as well.


Maybe Sieve is the answer. I presume the argument to -m could be 
inspected in a Sieve script, which could then map to the desired target 
mailbox. The non-IMAP users (like [EMAIL PROTECTED]) could be 
reimplemented as aliases that redirect to a [EMAIL PROTECTED] address 
for the user responsible for that domain. But using Sieve scripts for 
extension to mailbox mappings seems far less elegant than using a database.


Maybe I need to wedge a wrapper program between Postfix and deliver that 
will accept the address components from postfix, perform the lookup, and
convert the results into a -d argument pointing to the owner (see 
table above) and a -m argument pointing to the mailbox.



On a side note...

When I used this command in postfix's master.cf:
/usr/lib/dovecot/deliver -d [EMAIL PROTECTED] -n -m ${extension}

as recommended in the wiki, the following error gets logged:

  ... status=bounced (command line usage error. Command output: Fatal:
  Unknown argument: -d Usage: deliver [-c config file]
  [-d destination user] [-m mailbox][-f envelope
  sender] )

which doesn't make a lot of sense. I suspect what it is trying to say is 
that it didn't like something about the argument to the -d switch. Maybe 
that should be ${domain} instead of ${nexthop}.


(What's up with all the whitespace between [-m mailbox] and [-f 
envelope sender]? Also, might be a good idea to have deliver always 
write errors - even startup errors - to the specified logging facility, 
given that not all programs that launch it will report what it writes to 
STDERR. I notice most postfix commands - even the