So what do we do with this:
>
> dbmail_users (id, user):
> 1 foo at server
> 2 foonew at server
>
> dbmail_aliases (alias, deliver-to):
> foo at server 2
>
> That is to say, we're trying to get all mail to 'foo at server ' to
land in
> the INBOX of 'foonew at server '. What happens:
>
> Currently:
> Mail for 'foo at server ' goes to user 1.
>
> Aaron's Proposal:
> Mail for 'foo at server ' goes to user 2.
>
> Thomas' Proposal:
> Mail for 'foo at server ' goes to user 2 and user 1.
Suggested correction to "what happens in this scenario" with Aaron's
proposal:
Mail for 'foo at server' goes to user 2 and user 1 - because the admin
makes
an explicit alias for any user who should receive mail addressed to 'foo
at server':
dbmail_aliases (alias, deliver-to):
foo at server 2
foo at server 1
Just as I believed when I set up my dbmail 2.x server months ago - that
I would
need an alias for every user. So Aaron's proposal relieves me of having
an alias
for each user - which of course I could avail myself of right now -
since the new
dbmail doesn't actually require an alias anymore... but I would
definitely have no
problem with the the concept that if I am going to use ANY alias for
user 1 ... I
must ALSO add an alias explicitly to user 1.
This seems to me to be the most backward compatible with the way dbmail
aliases and
users used to work, while retaining the advantages of not requiring an
explicit
alias if the only deliver-to for the address *is* a user matching the
address.
> I'm inclined to say that the question in this case is about what we
*want*
> to have happen. I can't think of any other demonstation cases corner
> cases right now, but let's keep the thinking caps on before doing
anything
> on this.
I feel both frustrated and helpless right now. I love postgresql, my
customers are
driving up me up the wall with their demands to be able to do this very
simple and
for them, common thing that they have been able to do for years with the
previous
MTA - and I literally cannot offer them ANY way to do this without
throwing them
into a further tizzy by making them change their user logins... going
non-standard,
away from the [EMAIL PROTECTED] which is the last thing we want to do.
Those who depended on getting their mail from accounts that are external
forwards -
now have mail they never got, waiting on our server - if I change the
user login so
that their external forwarding will start working - then the
instructions they have
for logging into webmail will not work - to get the mail they missed.
And there are
a lot of them - on various domains etc. And we just went through the
painful migration
and speaking to most of them phone call by phone call how to convert to
the nice old
standard of "all you have to remember is your user name is
[EMAIL PROTECTED] - no more
of that ampersand stuff" ... etc.
As Paul or someone commented - all I'm asking for is a fix to return the
operation to
what dbmail documentation describes - or a reasonable facsimile. Not a
new function
or new feature that should maybe be theoretically consider for some
distant debate.
If someone would tell me what file to edit and how to make the change
start happening
in my own installation now, I'd be eternally grateful. I am not a c
programmer. I don't
know if your SQL is editable wo recompiling etc or what is involved. Or
if you can
tell me the file to have messed with, I'll get one of my C programmers
to mess with it -
and do Aaron's proposal if I can't do it.
Thank you,
- April Lorenzen
