/So what do we do with this:
/>/
/>/ dbmail_users (id, user):
/>/ 1 foo at server
<http://twister.fastxs.net/mailman/listinfo/dbmail-dev>
/>/ 2 foonew at server
<http://twister.fastxs.net/mailman/listinfo/dbmail-dev>
/>/
/>/ dbmail_aliases (alias, deliver-to):
/>/ foo at server <http://twister.fastxs.net/mailman/listinfo/dbmail-dev>
2
/>/
/>/ That is to say, we're trying to get all mail to 'foo at server <http://twister.fastxs.net/mailman/listinfo/dbmail-dev>' to land in
/>/ the INBOX of 'foonew at server
<http://twister.fastxs.net/mailman/listinfo/dbmail-dev>'. What happens:
/>/
/>/ Currently:
/>/ Mail for 'foo at server
<http://twister.fastxs.net/mailman/listinfo/dbmail-dev>' goes to user 1.
/>/
/>/ Aaron's Proposal:
/>/ Mail for 'foo at server
<http://twister.fastxs.net/mailman/listinfo/dbmail-dev>' goes to user 2.
/>/
/>/ Thomas' Proposal:
/>/ Mail for 'foo at server
<http://twister.fastxs.net/mailman/listinfo/dbmail-dev>' 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 <http://twister.fastxs.net/mailman/listinfo/dbmail-dev>
2
// foo at server <http://twister.fastxs.net/mailman/listinfo/dbmail-dev>
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 w/o 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
