On November 30, 2004, 12:33 PM Tom Collins wrote:
> How do you define an alias vs. a forward? Do you count the number of
I've been thinking about this since aliases were eliminated from qmailadmin.
if the destination of a forward is a local mailbox, then the account should
be created by mirroring the destinations entry in the vpasswd file, and
simply changing the maildir (and possibly setting some attribute and/or
modifying/locking the password). We'd call this an alias.
if the destination of a forward is a local forward or alias (via
.qmail-username), then the account should be created by creating a hard/soft
link to .qmail-username. We'd also call this an alias.
if the destination of a forward is to a remote account, create a
.qmail-username with &[EMAIL PROTECTED] we'd call this a forward.
while removing .qmail-username files:
1. check to see if any other .qmail-usernames are linked to it
If so, (possibly warn user) and delete them
2. check to see if username is a local mailbox.
If so, realize any username/.qmail is possibly harmful now (was
previously irrelevent)
while removing entries from the vpasswd db,
1. check to see if this account is the main account (if the directory ends
in /username)
if it is, (possibly warn user) and remove all other accounts pointing to
this directory.
this behavior would eliminate all the "why is my alias not getting spam
filtered but the main account is" problems.
> I assume your logic is that you allow more aliases (local addresses)
> since it doesn't use any bandwidth and limit forwards (remote
> addresses) due to bandwidth usage.
>
> Or maybe it's just that forwarding to a remote address is more valuable
> and therefore worth more money?
not necessarily - in some of my environment, all local accounts get spam
filtered, and therefor users creating aliases could actually increase the
load on my servers (versus the chkusr patch rejecting the recipient at SMTP
time).
> We're moving in a direction with QmailAdmin where you can have forwards
> that:
[...]
> 2) Bounce email back with an error message (see qmail's bouncesaying
> program for details). Again, no interface yet but it's in the planning
> stages.
while this is very cool, whoever's working on the code: _please_ make sure
this is limitable in .qmailadmin-limits or disablable at compile time.
bounces/autorepsonders/vacation messages are generally a nightmare and
vulnerable to abuse (even with the latest and greatest autoresponders).
--
Jeremy Kister
http://jeremy.kister.net/
