Send as another user

[leigh]

And here I was looking for it in Outlook.
Thanks again.

[leigh]

Looks much better, except for one thing.
Looking at the headers for the email I send (from behind a support@ address), it still has "return-path" set to my real address.

e.g, we have a "support@mydomain" address. Support has delegated access to both me and other team members. I have set sender=N for support@.
An email comes in to support@mydomain. I reply to it, and my email goes out being from support. However, the first line of the headers is:

Return-Path: <leigh@mydomain>

Any way of changing this?

[leigh]

And while we're complaining about headers......

If I receive an email with these headers:

From: "person's name" <email@domain.com>
To: mailing-list-address@listserv.someotherdomain.com
Sender: mailing-list-bounces@listserv.someotherdomain.com

The "from" field in Outlook is the "sender", not the "from", so all of my mailing list emails now appear to come from the list, not the original sender. This has only changed since the upgrade from 9.4.2 to 10.
Another flag I've missed somewhere?

[leigh]

Ignore previous post. Somebody beat me to it in another thread (by about two hours.)

However, getting back on topic:
When sending as another user, who has delegated me permissions, is there any way I can have it appear in their 'sent items' folder instead of my own?
I realise I could drag the sent email from my 'sent items' to theirs, but it would be nice to have it there automatically.
Even a mail rule rule would help.

[jg]

The Return-Path header is added by the MTA peforming "final" delivery.

The information is generally taken from the MAIL command of the SMTP conversation.

This information is *never* used by clients for replying to a message, and it's purpose is really for the mail system itself to report delivery problems.

The "--sender Y" removes the Sender: token from the message we send out, but it doesn't alter the SMTP conversation, we are currently considering the issues on whether to make a change here.

On your second point we follow the Outlook delegation model, i.e. if as a delegate you send a message on behalf of the principal then that messages ends up in the sent items folder of the Delegate. The issue here is really one of "default store", i.e. the Outlook/MAPI mechanism requires that the folder to which the message is to be saved must exist in the default store. Also, unless the prinicipal explictly grants it, a delegate does not have access to the principal's sent items folder...as a principal would you really want a delegate to see all the messages you've sent just to enable them to file messages they send in your sent items folder.

Because you can't save the outgoing message in a folder outside of the default store, adding the principal's mailbox to the delegate profile and explictly selecting the sent items folder of the principal (assuming you've been granted access to it) via the options menu when sending the message won't work.

This is really an Outlook limitation rather than a sanction imposed by Scalix.

Cheers,
JG

[leigh]

The "--sender Y" removes the Sender: token from the message we send out, but it doesn't alter the SMTP conversation, we are currently considering the issues on whether to make a change here.

This is fairly critical to our business in particular. We need for team members to be able to reply to customers from behind a 'support' or 'sales' alias and to remain completely anonymous.

On the second point re sent items, is it possible to enable a Scalix rule which can be applied to outgoing rules, so that the server can move messages to the principal's mail box?

[mhanisch]

On the second point re sent items, is it possible to enable a Scalix rule which can be applied to outgoing rules, so that the server can move messages to the principal's mail box?

I haven't tried this, but one way to make this work would be to
always BCC the "principal" on outgoing emails, and maybe then add a filter rule to the principal's account which moves all emails sent "on behalf" into the Sent Items folder. (When an email is sent on behalf of the principal, this is reflected in some header - this could be used to filter these messages out.)

[florian]

This is fairly critical to our business in particular. We need for team members to be able to reply to customers from behind a 'support' or 'sales' alias and to remain completely anonymous.

We've logged a change request with decent priority for this and will see that the behaviour is changed for the next product release.

--f

[florian]

Just to finish this - the fix made it into the 10.0.1 patch release, so with the "sender" flag set, the SMTP conversation (the "envelope") will also be altered to completely hide the real sender of the message.

Cheers,
Florian.

[sebastiaan]

Hi. The problem with allowing users to put anything in the From: field is that they can then masquerade as their boss or anyone else they wish to send as. We only allow people to send as themselves or as a user who has delegated permissions to them.

In our case, it's not about putting just anything in the from field.

I asume outlook sends a request to check wether the address placed in the from field is actually an existing account and wether the current user has sendonbehalf permissions for that account.

Is is not possible to just add a check for 'official' aliases to this procedure?
Perhaps add a checkbox/switch to sac/console aliases that indicates allowsendfrom

if (isalias(address)) { return true }
else {
if (sendonbehalf(address)) { return true }
else { return false }
}

The original question was not answered.
I would still very much like to see a feature like this, any news?

[charon]

I would really also like some additional "send as" feature added.

so, why can several email addresses be inserted into the user account, but then the user can also receive mail for these aliases but not send?

additionally, why is the outlook user not able to add additional accounts into his outlook (like pop or smtp) with different identities wihtin his scalix profile.

the end user could easily change his identities during the send process.

all customers beef about this and it is a huge administration effort to

- create another premium user
- setup delegation in outlook
- setup delegation in SWA
- add the additional mailboxes into OL
- add the "From" field in OL
- change signatures

when the end user wants to send he hast to:

- insert the delegate into the from" field
- change the signature

From the usability point of this these are all trade-offs.


charon

[claus]

I would really also like some additional "send as" feature added.

Same to me.
I have ONE Mailbox and many Aliase. Normaly I only use Webaccess as we cannot use Outlook in my Company due to Proxy Issue...

So in first terms it would be great to get a "send as" feature for use of Aliase.
This would be a competative Feature against Outlook!!

Don't you see this?

In Outlook you normaly cannot send as another person (OK yes -> Public Folder Config) without delegation and much more Headerinfo...

- change the signature

I love this Autofeature in my Apple iPhone!
Change eMail-Account (OK this is really a account) and I got a new Signature.

This would be also Greate for send as!

(Example: I have a webmaster and a private address for my domain.
So I spare less Information on webmaster Signature as on my private mail address. Simple isnt't it???)

Greetings
Claus

see also http://www.scalix.com/forums/viewtopic.php?p=55879#55879

[tantony]

Hi,

I have read the thread and i still don't know how can i authorize some users with ommodu to send emails with an email adress from a different mailbox (not with send on behalf).

Would someone be so kind and give me an example.
For example there is userA and userB and both should be able to send emails with the email adress office@company.com from mailbox office.
Do i have to enable or disable the send headers?
Scalix Mail Server 11.4.3 is installed.


Thank you in advance!
Tantony