Hi Humberto . Sounds like you are advancing in your DBMail experience.
I'll preface my response with some points (albeit obvious in some cases, but
just to be clear) to put us on the same page.
Background:
1) MTA virtual mapping should not be required in your instance and could
conceivably cause some chaos. To avoid complicating things more then they
must be, I try and consolodate delivery functionality to DBMail and minimize
dependency on MTA tools. (There is even yet-to-be-exploited exstensibility
within DBMail.)
2) I am not alone in having hundreds or just dozens of domains running in
single databases in several environments without ever using the MTA's
virtual mapping for deliveries.
3) A reminder: the user name (dbmail_users.userid ) is indexed 'unique' in
the SQL database. It is a login name and must be unique as is the case with
login names in any scenario.
4) References to the user account within the database are by the numeric
user_idnr.
5) As a manner of thinking, the user name could be thought of as the
customer's unique "nick name" (If that helps to keep it unique). This does
not dictate the formation of an email address. The userid does not need to
ever be used in an email address (Imagine how many "Mike"'s exist on this
planet? Hence I am mikeO, mike1, mikethis, mikethat but my email address is
[EMAIL PROTECTED] unless another mike on that domain gets it first, in
which case I must use a more original email address :o) The point is that
some users need to be told "No, that email address is taken, please choose
another".
6) Aliases, while uniquely identified by the alias_idnr, on the other hand
are not unique in the database. While one needs to be careful, in my view,
this is an enabling feature and affords another regime in which DBMail is
extremely exstensible and scalable in retrieval and delivery. (You'll see
what I mean in the example below.)
7) Ordinary Aliases (i.e.: not a forward) point to a usr_idnr (not a name)
for delivery.
8) I have not tried running multiple instances of any DBMail programme
(-lmtpd, -impad etc) each with its own database nor can I imagine a reason
why to do this on a single host. (Might be an interesting if not chaotic
experiment, but for no eventual purpose I can foresee.)
Solution:
** If you are trying to store a copy locally of a message while at the same
time sending a copy of the same message to another recipient, it is very
easily administered using DBMA.
Go to the User's Account Window in DBMA (DbMail Administrator), press
'Modify' and create two identical aliases (click click) then scroll to one
of the duplicates, selecting "forward" and type the address you want the BCC
to be sent to. Done.
DBMA edits the entry on the basis of the alias_idnr which is unequivocal.
The result in the database will show two identical aliases, one pointing to
the owner_idnr and one pointing to an internal or external forward email
address. In each case DBMA enters the client_idnr of the original account.
This gives a completely blind BCC and it can be done as many times as you
like.
Example:
One organization I do some volunteer work for has twenty executive board
members out of about three thousand total. It's Secretary from time to time
needs to send monthly meeting minutes only to that select group. I created
an account called meeting_notes. I quickly created 20 aliases for
[EMAIL PROTECTED]; then in each case selected 'forward' and one by one
added the addresses of the twenty board members. Once the inital setup was
completed, all future work is a matter of editing. The Secretary sends one
copy of her Meeting Minutes to the meeting_notes address and all twenty
designated recipients receive a copy. From time to time, members of this
group change so she opens the forwards list, selects 'edit' for the
retiring member, and changes the forward address to that of the incoming
board member. ... I think you get the idea. I'ts not the only way of doing
this but it is ultra simple and user-friendly. This little process is now
managed by a non-IT person (DBMA authenticated in SSL configured in
RESTRICTGroupID mode.) with no ill effect whatsoever.
(NOTE: This might help a little. DBMA only converts existing *working*
aliases [on the basis of alias_idnr] into forwards which as a process averts
user errors that could otherwise create multiple instances [a real mess] in
the database. At one time DBMA allowed the administrator to type any email
address as an alias and any mail address as a forward. The errors an admin
can make in this regime were just unbelievably horrid, so (oops, sorry) that
mehodology got tossed.)
This current DBMA functionality and methodology is derived from DBMA-users
experience where a forward is most often a decision to shift delivery from
one place to another, hence, recycle the working alias--add more if needed.
It is also a great way to to do BCC's, and, optionally, front-line support
personnel (level one and two) can be easily trained to do this work with a
minimumal possibility for error.
Hope this 'hitch-hiker's' guide helps out...
:o)
Mike
----- Original Message -----
From: "Humberto Valiente" <[EMAIL PROTECTED]>
To: <dbmail@dbmail.org>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, June 29, 2005 11:40 PM
Subject: [Dbmail] Sender and Recipients bcc maps
Hello Mike
Which are the possibilities to manage with DBMA the postfix parameters:
- always_bcc
- sender_bcc_maps
- recipient_bcc_maps
---------------------------------------------------------------------
- virtual maps ..too
Im using it because I have "one dbmail database" with accounts for two
different domain.
The problem become when I need to create two accounts with the same
username ... "account" for example
So ...when I created [EMAIL PROTECTED] and [EMAIL PROTECTED] dbmail
creates two alias for the same user instead of two different mailbox
In this case the virtual maps redirect email from
[EMAIL PROTECTED] to ....user1 mailbox
[EMAIL PROTECTED] to ...user2 mailbox
Another solution could be to create two databases for each domain an use
two postfix instances I guess
Whats your opinion about it??
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
