Remove "On Behalf of..." from delegate email

[vlaurenz]

Is it possible to do so? The whole point of us using this feature is because we have users that will need to be able respond to email sent into a PDL. These users should be responding as that PDL's email address. (eg: support@domain) Their personal email address should be hidden when they respond.

We're looking at doing it this way because there really is no other way to send mail via an alternate SMTP address with Scalix. I know Scalix hasn't agreed in the past, but I feel that this is a major flaw in the product and a fix should be given an urgent priority. A stop-gap way to fix this would be to allow administrators the ability to configure whether the "Sender:" portion of the MIME header should be added for delegated mail.

I notice Scalix Support replies to email via Thunderbird to achieve this feature. Looks like you guys could use it as well.

[florian]

Since Scalix 10, we introduced a "sender" flag, which can be set using ommodu; in Scalix 11 it is also available in SAC.

When set (on the principal account to which someone has access, i.e. the "support" type account, *NOT* the users account), this will make the real sender disappear, so From and Sender headers (and actually even the SMTP envelope in Scalix 11, Scalix 10 had a bug there) will completely hide the real senders name.

Note that this is only true for email leaving the system via the Internet Mail Gateway; internal eMail will continue to show both From address and sender; this is by design.

Florian.

P.S. Our support folks are T'Bird diehards and as they are not using calendaring or anything on the support mailbox, they won't change their clients even with this behaviour. Which is fine. Clients of choice.

[vlaurenz]

Thank you florian! While not the best solution, this may work out for us in the interim.

Code: Select all

       --sender Y|N
               If sender is set to N on a mailbox, then delegates sending via that mailbox will not
               have a Sender header added to an outgoing  internet message. Default Y.


[florian]

what further solution to which problem would you require?

Florian.

[vlaurenz]

what further solution to which problem would you require?

Florian.

I would prefer to have this same functionality without having to make the PDL in question into a user account (which will use one of our licenses). We have potentially hundreds of PDLs which would require this functionality and it would not be cost-effective to have to use a license for each of these PDLs just so our users could reply to the messages while hiding their personal email address.

[florian]

OK, but that's not likely to happen anytime soon.

By definition, a sender is entity with identity; this is limited to mailboxes and obviously we won't easily change functionality that affects our licensing model and business.

We're looking into enabling a user to send-as one of his aliases; however, this would be an alias on a personal mailbox (and each address can only be an alias to one) and not a PDL. It seems, though, that outlook does not easily allow this to happen as it seems to normalize the sender address. Under investigation.

Cheers,
Florian.

[vlaurenz]

Hello again. The sender flag seems to "disappear" from the account in question. Any ideas? Is this a bug?

Code: Select all

[root@foo ~]# ommodu comments --sender N
ommodu: The user was modified successfully

[root@foo ~]# omshowu comments
Authentication ID: comments
User Name : Comments /CN=Comments
MailNode : email
Internet Address : something@somwhere.com
System Login : 348545
Password : set
Admin Capabilities : NO
Mailbox Admin Capabilities : NO
Language : AMERICAN
Virtual Vault : Enabled (default)
Mail Account: Unlocked
Last Signon : 01.24.07 11:56:19
Receipt of mail : ENABLED
Service level : 0
Excluded from Tidying : NO
User Class : Full
Sender : NO

[root@foo ~]# ommodu comments -p 'test'
ommodu: The user was modified successfully

[root@foo ~]# omshowu comments
Authentication ID: comments
User Name : Comments /CN=Comments
MailNode : email
Internet Address : something@somwhere.com
System Login : 348545
Password : set
Admin Capabilities : NO
Mailbox Admin Capabilities : NO
Language : AMERICAN
Virtual Vault : Enabled (default)
Mail Account: Unlocked
Last Signon : 01.24.07 11:56:19
Receipt of mail : ENABLED
Service level : 0
Excluded from Tidying : NO
User Class : Full


[ls-al]

Hello again. The sender flag seems to "disappear" from the account in question. Any ideas? Is this a bug?

This seems to be addressed with Scalix 11.

I was able to reproduce with 10.0.5 but not with 11GA.

[vlaurenz]

Hello again. The sender flag seems to "disappear" from the account in question. Any ideas? Is this a bug?

This seems to be addressed with Scalix 11.

I was able to reproduce with 10.0.5 but not with 11GA.

So does that mean that this bug won't be supported or fixed in v10? I would hope not.

[ls-al]

As far I understood the Scalix patch policy I would not expect a v10 patch for this issue.
v11 is released and the 11.0.1 patch should come in the next couple of weeks.

As long there are not any really critical issues with the latest available v10 patch-release, there should be no reason for a new one.

I can understand that some people dont want to upgrade at this point but I can ensure that we already did some commercial v11 installations and a v10 to v11 migration of a 1000 user-site. All these customers are not that unhappy as some people in the forum. Maybe they have another point-of-view but this is another question.

Regarding the issue we are talking about:

Wouldnt you agree, that the audience which is using the ommodu command is manageable?
It should be possible to add the "--sender Y|N" everytime you have to reset the password or modify other attributes.

cheers,
Dirk

[florian]

The sender flag feature has been improved in multiple ways in Scalix 11, besides this little bug being fixed.

- as a new feature, sender flag can now be set using the Scalix Admin Console (SAC)
- Sender is now completely hidden; previously he was still visible in the SMTP conversation and Apparently-from headers (see http://bugzilla.scalix.com/show_bug.cgi?id=11010 for details)

As the bug mentioned is fairly minor and the feature has been improved in Scalix 11, we would normally not consider backporting it into a Scalix 10 patch, which, as Dirk says, is normally reserved for major or critical problems; based on broad assessment of the bug, I really can't see it as such. This in particular, as the user directly affected would be an administrator executing the ommodu command. The flag is not reset when changing the password from SWA or Outlook, i.e. from the user side. I agree that the most unpleasant version of this is changing the password via SAC where the sender flag is not available in Scalix 10.

If you are a customer with a running support agreement and have a specific business situation that would prevent you from upgrading to Scalix 11 in due time and which makes this bug particularly nasty for you, please go through Scalix support and open up a support case to escalate this.

Hope for your understanding,
Florian.

[mhanisch]

I just noticed this issue on my installation - and just learned that this is a known bug...

Anyway, since I cannot/ don't want to upgrade yet, I installed a quick work-around, which
consists of running the following script once every hour or so:

Code: Select all

#!/bin/bash

# TODO: Put the names of the affected users here, separated by spaces
PRINCIPAL_ADDRESSES="user1 user2 user3"

for u in $PRINCIPAL_ADDRESSES; do
        omshowu $u|(fgrep   -q "Sender :" || (echo "$u was missing sender"; ommodu "$u" --sender N)) ;
done


Hopefully someone else will find this useful...

If this sender flag is cleared by resetting the password and/or running ommodu only
then the better solution would be to write a wrapper script that sets the sender flag automatically each time it would be cleared; I'm too busy to test this, but it should work.
Just FYI...

[florian]

It would work. The problem is actually a bug in ommodu; when changing the password through the email client (either SWA or outlook), the sender flag is not reset, so indeed ommodu can be replaced by a wrapper that would insert a --sender argument preserving the value if it's not there.

When doing these kinds of workarounds, however, please note that you would need to copy the old ommodu binary to another directory and keep (!!!) the ommodu name. ommodu is actually the very same binary (hard-linked) as omaddu, omdelu and some others and will not behave correctly if you rename it to ommodu.old or so.

Also note that renaming binaries is not supported, so please make sure you don't try this at home and hit our support team with problems arising from this!

Cheers,
Florian.

[mhanisch]

When doing these kinds of workarounds, however, please note that you would need to copy the old ommodu binary to another directory and keep (!!!) the ommodu name. ommodu is actually the very same binary (hard-linked) as omaddu, omdelu and some others and will not behave correctly if you rename it to ommodu.old or so.

Point taken.
I assume ommodu is also called from SAC behind the scenes, so renaming does not
seem advisable. (I already did some work on omaddpdln re. the "group.permission" setup mentioned in the admin kit, which has proven very useful so far. I guess the same restrictions/warnings apply in this case.)

Best,
Michael.