Page 1 of 1

Trying to change the from address

Posted: Wed Jul 25, 2007 10:13 pm
by brianca
Is it possible to set up delegate rights to a distribution group in scalix? Similar to the others in this thread, I have a group called support that get's my support@domain.com mail and delivers it to several people. I need those folks to be able to send mail out as support, but I can't find a way to allow send as on a distribution group.

Also are there plans to allow a user to sendas on of his own aliases from the web interface?

Posted: Thu Jul 26, 2007 2:52 am
by jaime.pinto
It's not possible to delegate rights to a *group* in scalix (at least that I could find yet, and I did look for it), but it's turns out you can delegate rights to *another account*:

Suppose you have an *account* called support on your server. You can then login via SWA (or OL) as support and *delegate* full rights to all those users in the "distribution group". In turn, each of those users can "add a mailbox* of the support account. That would allow each user on the "distribution group" to reply-to either as themselves or as the user who delegated the rights (support). This is a very elegant way to allow a user to have more than one reply address, as long as those replies are either standard or premium users on the same scalix server (as internet users is not possible)

The above takes care of your question.
You're now left with another problem: How to have an account called *support* on the server and at the same time forward a copy of any incoming email to other users on the "support distribution list" (not support *group*). Here is another post that explains how to do that using sxaa. That also means you'll have to remove your current group called "support":
viewtopic.php?t=7592#34584

Posted: Thu Jul 26, 2007 3:11 am
by jaime.pinto
(I wish the scalix administrator/moderators would let us edit our own posts in the *Feedback* area as we can do on other areas of the forum. This way I could continue with my trail of thought without having to add another post)

... on the other hand, if users to whom the rights have been delegated to can see the Inbox of the support account, the previous step of forwarding emails with sxaa may not be necessary.

I hope that wraps up this entire subject in one post, in a clear in concise way. There have been many posts hovering around it, in particular the reply-to issue.

Posted: Thu Jul 26, 2007 4:45 am
by brianca
Is this ability expected in a future release? It's pretty basic stuff. It seems odd not to allow these things. More administrative overhead than is needed and one extra account to manage from a security standpoint for every group that you want to have a reply to change for. Not very elegant at all if you ask most folks. It sounds like more of a cluge of a workaround.

Posted: Thu Jul 26, 2007 5:08 am
by brianca
Not to mention it requires me to burn a premium account for each of my group addresses and aliases that I want to be able to send as.

Posted: Thu Jul 26, 2007 9:00 am
by jaime.pinto
Very early on when I became a scalix customer I advocated scalix to build a enterprise server that would go beyond the features and limitations of MS Exchange server. For a number of reasons Scalix seems to be having difficulty barely keeping up with the task of emulating what Exchange does. That's probably OK for now, but at some point they will have to become their own product, and come up with some innovations.

The process I described above is very compatible with how one would go about doing the same thing in exchange.

The thread/post below presents from more points of view on this subject.
viewtopic.php?t=8262#37466

Posted: Thu Jul 26, 2007 3:56 pm
by brianca
In exchange, I would assign sendas rights to a group on the distribution list, and then all the members of the group would then have rights to send as the distro list email address.

Scalix won't allow assigning this right to the distro group from what I can see, nor will it allow applying permissions at the group level rather than individuals.

That's a pretty big gap from exchange in the enterprise, IMO.