Topic: [SOLVED] Three mailboxes: forward info to each other?

[Michail Pappas]

This is a strange scenario and one that the owner of the sme server is not sure on how to pursue. At the moment there's this SME 8 box, serving 3 mailboxes. The owner wants whatever comes to one mailbox to be forwarded to all the others.

I informed him that he can have a single mailbox, with a couple of aliases if needed, accessible to all three persons via IMAP/webmail but he was not sure. He will think about it, but in the process I was wondering if a setup like the following would work:

* three mailboxes
* first mailbox userA is set to store locally as well as forward to userB
* second mailbox userB is set to store locally as well as forward to userC
* third mailbox userC is set to store locally as well as forward to userA

Would this work or would endless loops be created?

[Stefano]

before starting to find the solution, you and your customer should start from defining the real problem..

the sentence:

The owner wants whatever comes to one mailbox to be forwarded to all the others.

means nothing if we don't know what he want to achive and why

[Michail Pappas]

before starting to find the solution, you and your customer should start from defining the real problem..

I definitely agree that's the real issue here, the poster subject/problem is merely an "exercise" of sorts...

The owner is a friend and I am trying to help him help me help him figuring out a good way to have both role isolation as well as effortless information flow between the roles. We'll figure that out eventually.

The question still holds though: would mail loops be created in a forwarding scenario, as described in the first post?

[CharlieBrady]

The question still holds though: would mail loops be created in a forwarding scenario, as described in the first post?

qmail will detect the loop and refuse to deliver a second time to userA. It will generate a bounce message.

[Michail Pappas]

qmail will detect the loop and refuse to deliver a second time to userA. It will generate a bounce message.

Thank you Charlie. So the bottomline is that this is not a valid "solution", even an interim one, since users will be flooded with bounce messages.

[Boris]

Will creating group and deliver e-mail to the group instead of individual accounts work? Aliases also can be added to the group if needed.

[Michail Pappas]

Will creating group and deliver e-mail to the group instead of individual accounts work? Aliases also can be added to the group if needed.

That's one approach that can work. I believe it's better though to have a single mailbox, all users accessing it via IMAP. This has the added advantage that outgoing mail as well will be accessible to all.

[Boris]

That's one approach that can work. I believe it's better though to have a single mailbox, all users accessing it via IMAP. This has the added advantage that outgoing mail as well will be accessible to all.

Unless their goal is redundancy of the messages.
With single mailbox if one user delete the message, other two don't see it. And there is no prove who deleted it.
With group, they will end up with three duplicated messages in their mailboxes.
Outgoing mail can be configured to whatever reply address they want and can be the same for everyone.

[purvis]

You could  have 3 reg separate mail accounts and have all 3 also forward to a fourth account.
Also use maillog for backup purposes.
That fourth email account might spread viruses to all  3 at one time.
If it where me. I would look into a safe way to read that fourth email account and you could bcc any out going mail to the fourth email account as well.

[Michail Pappas]

Unless their goal is redundancy of the messages.
With single mailbox if one user delete the message, other two don't see it. And there is no prove who deleted it.

Indeed, had not thought about that. Will have to take it into account.

@purvis: Another interesting idea, will think about that as well, thanks!

[janet]

Michail Pappas

The "correct" answer is to use groups.
Use 3 groups each which represents one user. All 3 users are members of each group so that all users get everyones emails. The existing users structure you have is the problem as emails are addressed to end user accounts. You could create 3 new users, move all email etc from the existing 3 users to the 3 new users. Then delete the 3 old users and recreate them as group names. The users then login with their new user names from then onwards. It's just that the structure has started out incorrectly for doing what you want to achieve without some sort of disruption.

Problem is you may also affect Windows logins, profiles, etc, and logins to many other programs.

So the alternative is to create 3 new groups and then get the existing users to update their email clients with their new group email addresses. Users would receive email addressed to both the group and the user name, but only the group email is forwarded to all 3 users.
Perhaps then put a vacation message on the original user name accounts, advising message senders to use the new group email address please.

I am not sure there is a simple answer that does not have some sort of 'complication".

[Michail Pappas]

The "correct" answer is to use groups.
Use 3 groups each which represents one user. All 3 users are members of each group so that all users get everyones emails. The existing users structure you have is the problem as emails are addressed to end user accounts. You could create 3 new users, move all email etc from the existing 3 users to the 3 new users. Then delete the 3 old users and recreate them as group names. The users then login with their new user names from then onwards. It's just that the structure has started out incorrectly for doing what you want to achieve without some sort of disruption.

Bit confused at first, but I believe I understand what you mean. SME is employed only for email, no windows log-in functionality here...

So the alternative is to create 3 new groups and then get the existing users to update their email clients with their new group email addresses.

Sorry, I do not understand this bit; groups are merely aliases for a bunch of users, just redirects. Isn't that correct? It feels as though you are hinting that groups are acting as normal mailboxes too, with storage allocated for them, for example.

[mmccarn]

Some (random?) ideas that may provoke useful conversation with your friend:
Use bccmode to maintain a server archive, and give the 3 users access to the 'maillog' mailbox?

Use the same root email address for all users, differentiated with "-userX" (info-userA@server.tld, info-userB@server.tld, info-userC@server.tld) -- all users get individual email "addresses" that they can control with personal rules in their email clients, but there is only one mailbox on the server?

Install spiceworks on a windows box and use that for trouble tickets?

Use an Asana project (free for 30 members and unlimited "clients") to coordinate communications (and configure a local email address to forward to the project's asana inbox)?

Install a ticket tracking system on the SME server?
OTRS
Trac
Scarab

[janet]

Michail Pappas

Bit confused at first, but I believe I understand what you mean. SME is employed only for email, no windows log-in functionality here...

Then my suggestion should be workable, it just means the current username based email addresses become group name based email addresses, so as to keep continuity of the publicly known email address for each user. The users themselves connect now to the server with a different newusername details, so their username has changed eg from rob to rob1 or whatever, and rob becomes a group name of which all three users are members eg rob1, jake1 & fred1. Same for the others jake & fred become group names that forward to rob1, jake1 & fred1, (then of course also create new users jake1 & fred1 or whatever).

Make sure you move all existing email messages BEFORE deleting user names (and change ownership of all the email files etc).
 

Sorry, I do not understand this bit; groups are merely aliases for a bunch of users, just redirects. Isn't that correct? It feels as though you are hinting that groups are acting as normal mailboxes too, with storage allocated for them, for example.

No not hinting that at all. Just saying you can use a group name as an email address which forwards to a user account, the user account being where the messages are stored etc. But you will then have two valid email addresses per "newuser", the username and the groupname. If external or other users send messages to any of the three persons, then messages sent to an existing username will only be delivered to that user, but messages sent to the group email name will be sent to all three users.
So you will ideally need to force others users to only use the group email addresses for sending messages to.

I also mean that you change the Reply To: address in each users email client to show the group@mydoman address rather than the user@mydomain address, so that people only send to the address that you know will forward to all users (via the group address). The vacation message idea was a way to force this knowledge down other other users throats to make them send to the group address rather than the user address.

Hope that is clearer !

It is really quite simple, that's part of the whole idea of having groups, pseudonyms, and pseudonyms of pseudonyms etc, to give sme this sort of user versatility.
Theoretically in many changing staff situations, everyone should be given a group (or pseudonym) name, and then whatever redirections you want can be easily accomodated. They of course connect with a different user name, but their publicly advertised address is the group@mydomain or pseudonym@mydomain address. You have to ideally implement this sort of policy from day one for easier management.

In your case it is easy to change over to this method, it just means in order to integrate this change now, that the users have to change their ways slightly.

Which way you prefer to do it, and the pros & cons & logistics of each method is for you to decide.

[Michail Pappas]

Well ladies and gents, this is pretty much the reason I come back to SME: its community is simply unbeatable! Thank you all for the wealth of information, you've made me a bit wiser I'll discuss all alternatives with buddy and help him select a reasonable solution.