From: Tom Metro (tmetro+postfixvl.com)
Date: Thu Sep 02 2004 - 04:09:48 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

(This might be a more appropriate discussion for postfix-devel. I'm not
subscribed there, and archives don't seem to be available, so I don't
know the tone of that list.)

The virtual(8) man page says it was "originally based on the Postfix
local(8) delivery agent," which means that .forward processing was
removed. Why?

The obvious answer is for security. Yet whenever someone needs filtering
capability for virtual users, maildrop is recommended, and I haven't
seen anyone bring up the security risks in that. I'm guessing the reason
is that people assume the administrator is prepared to trade off
security for added capability.

If so, wouldn't it make sense to have .forward processing at least be an
option in virtual(8)?

I recently went through the process of setting up maildrop (v.1.5.3) as
a replacement for virtual(8), and learned that maildrop isn't quite a
drop-in replacement. Specifically:

1. Formal documentation on how to configure maildrop to work with MySQL
(and I presume LDAP) doesn't seem to exist. What is available is a
commented configuration file and various third-party HOWTOs.

2. maildrop doesn't automatically create maildirs.
(There are maildroprc hacks to get around this, but in my opinion it
should be built-in to the core as it with virtual(8).)

3. maildrop doesn't automatically fall back to ${user}${nexthop}
if ${recipient} (a.k.a. ${user}+${extension}${nexthop}) isn't found in
the database.

maildrop does incorporate logic for doing something similar when
selecting maildroprc files (see -M switch), so you could approximate the
behavior with something like:

maildrop -M ${extension} -d ${user}${nexthop}

but if you want it to first try and obtain the mailbox path from the
database, this approach doesn't work.

Theoretically, Postfix's pipe(8) command, when enabled via a message
processing flag, could perform this logic and insure that the
${recipient} handed to the transport was one found in the
virtual_mailbox_maps. I'm not sure though whether it makes sense for
that logic to be in pipe(8). (I'm guessing pipe(8) probably doesn't do
any database I/O currently.)

These last two limitations should be noted in:
http://www.postfix.org/MAILDROP_README.html

Additionally, because of the loose integration with maildrop, it:

4. doesn't know about Postfix's 'recipient_delimiter' (related to #3) or
'virtual_mailbox_base';

5. requires an additional database configuration file (and has somewhat
different requirements for the database schema than Postfix, though
obviously the two can be coerced to work off of the same table).

Has anyone considered creating a Postfix-specific fork of maildrop that
would address these issues and make it truly a drop-in replacement for
virtual(8). (Patches exist for #2. #3 should be fairly trivial to
address. What remains would be adding code to obtain parameters from
Postfix's main.cf.)

Another take on this might be to expand the macros that pipe(8) can pass
on the command line to other programs. For example, if that list
included the full path to the target mailbox, one could use maildrop
without a database. Instead a common maildroprc would set DEFAULT to the
path passed on the command line. (Not a complete solution, but it would
address #1, 3, and 5 above. It would also make it easier to use other
delivery transports (say procmail, if you really wanted to) for Postfix
virtual users. Though to accomplish this might require blending pipe(8)
with virtual(8), which may not be desirable.)

  -Tom

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]