Charles Sprickman a écrit :
> Hello all,
>
> We've been using vpopmail+qmail for the past 6 years or so, and need to
> deploy new hardware. I'm seriously considering a move to something more
> modern on the software side. Vpopmail has worked well for us, but it's
> a bit hackish, as is the bundle of patches to try and make qmail more
> modern.
>
> I've been looking at how Postfix handles virtual domains and it looks
> like I should be able to put together something that gives us similar
> functionality but with a more modern MTA that is more flexible and
> currently maintained.
>
> For an ISP environment, what's the "standard" these days for hosting a
> good number of virtual domains with Postfix? I understand that Postfix
> is actually just one piece of this mess, but I'm most interested in
> querying a community with tons of Postfix users.
>
> I'm looking for the following features; any comments/corrections would
> be much appreciated:
>
> -Ability to let our billing system (Freeside) add/delete/modify accounts
> with simple shell scripts or direct sql access. This looks possible
> with something like postfixadmin. We sell domain email with blocks of
> accounts (ie: up to 10, 20, 50, etc.).
>
you can store users in an sql db and use whatever interface to manage
their list. the keywords to look for are virtual_mailbox_domains,
virtual_mailbox_maps, ...
> -Ability for end users to add/modify/delete accounts at the domain or
> user level (again, postfixadmin addresses this)
>
if the map is in sql, then use whatever interface to this sql db.
> -SpamAssassin integration; we've got 4 boxes dedicated to this
> currently. Users can alter their prefs (score threshold,
> white/blacklists) via a webmail plugin or standalone web interface that
> twiddles values in a replicated db for spamassassin. Also easy to move,
> but for one caveat which is they can turn the filtering on and off. We
> currently accomplish this by twiddling .qmail files which call a
> specific maildrop filter. I'm not seeing any similar functionality in
> any of the postfix web-admin panels, and would love to have some input
> on this. I could just by default have it on for all people and for
> those that don't want filtering have the score threshold set
> ridiculously high. I'm also unclear on what kind of flexibility I'd
> have with Postfix as far as passing the email through SpamAss - right
> now I round robin requests using the spamc client called from maildrop.
>
either keep using maildrop or move to amavisd-new. amavisd-new has
support for sql lookups. check if that's enough for you.
> -Continued use of Courier-IMAP. Not so much because I like it, but I
> don't want POP UUIDs changing or any big changes in IMAP quirks that
> suddenly cause users grief. It seems like Courier+Maildrop is fairly
> common though, so I think I'm safe there.
>
courier is ok, but you should be able to move to dovecot with few
efforts. I only tested (migration) with imap, so I can't tell about the
POP part.
> -All mailboxes under one heavily-hashed directory structure - some kind
> of intelligent directory hashing would be nice so that things don't get
> too lopsided. I believe this piece is going to be handled by whatever
> "admin" frontend I choose. I'm a bit unclear on how far down
> Postfixadmin hashes things. Vpopmail is a bit sloppy, but stores things
> like so: ~vpopmail/domains/0/example.com/0/someuser
>
if you deliver with maildrop, then postfix doesn't care about the
mailbox. you can let maildrop get the mailbox from sql (via
courier-authlib). or if your scheme is "static", you can do that in
maildroprc. I mean something like
USER=$1
DOMAIN=$2
MAILDIR=`/some/script $USER $DOMAIN`
DEFAULT=${MAILDIR}
when $1 and $2 are passed to maildrop from postfix...
If instead you move to dovecot, then you will get more flexibility. you
could for example have delivery for joe @example.com to
/some/path/example.com/j/jo/joe/maildir/
... etc.
> -smtp-auth with support for virtual domains is a must. It looks like
> the SASL implementation in Postfix has no issues with this.
>
for server side (users authenticate to your postfix), you can use
cyrus-sasl or dovecot sasl. you can run the latter without using dovecot
as imap/pop server. it is preferred over cyrus-sasl.
> -"soft" quota support outside filesystem quotas (mailstore all under one
> uid).
>
this is not simple. you'll have to search and chose which approach to
take. because delivery is not immediate, there is no "definitive"
answer. (the issue is to avoid backscatter if users get out of quota too
often).
> And things that are not possible or a real pain with qmail/vpopmail:
>
> -ability to override any RBLs for foreign dialup customers coming from
> random IPs that may be blacklisted but have authenticated without
> running another smtp listener.
>
Look for permit_sasl_authenticated.
> [snip]
