Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Send on behalf of" functionality for delegated mailboxes #6134

Open
ralfbergs opened this issue Nov 2, 2024 · 4 comments
Open

"Send on behalf of" functionality for delegated mailboxes #6134

ralfbergs opened this issue Nov 2, 2024 · 4 comments

Comments

@ralfbergs
Copy link

Summary

I would like to be able to delegate mailboxes in a fashion so that the user to which the mailbox has been delegated can send email "on behalf of" the owner of the mailbox. This should be made visible by using the "Sender" email header in addition to the "From" header, so that recipients of such messages can see something like "From 'Janet Doe' on behalf of 'Big Boss.'"

Sender: Janet Doe [email protected]
From: Big Boss [email protected]

Motivation

Currently, a user to which a mailbox has been delegated can send email thru that mailbox, i.e. using the corresponding email address. However, it's not detectable in any way by the recipient, that the message was not sent by the owner of the visible name/address, but by someone else.

In companies, this is often not acceptable for compliance reasons. It must be visible that someone else did it, e.g. an assistant.

Additional context

No response

@apio-sys
Copy link

apio-sys commented Nov 2, 2024

That works as described here: https://docs.mailcow.email/models/model-sender_rcv/ . I have used that on multiple occasions and it works as expected for me. Does that answer your question?

@ralfbergs
Copy link
Author

@apio-sys Hi Joris. Thank you for your response.

Either I'm misunderstanding the page you referred me to (I did read it before I raised this ticket!), or you are misunderstanding the intent of my ticket.

I am able to successfully delegate access to "[email protected]" to "[email protected]", and she can send on behalf of her boss now. But -- it's not visible whether she sent a message on his behalf, or whether he sent it himself.

And that's exactly what my feature request is about. I want to (optionally, I guess there is also valid use cases for desiring the current behavior that is not ideal for my case) exhibit the fact that the message was sent by a person other than the one on whose behalf the message is sent.

Is it now clear? Am I missing anything?

Many thanks for your help.

@apio-sys
Copy link

apio-sys commented Nov 2, 2024

OK I see what you mean. Sorry for having replied to quickly because indeed, it doesn't work like that. It will just show as being from "boss@" and not "janet@ on behalf of boss@". I remember that MS Exchange did/does that. Not sure if that's really added value though but that's just my opinion. I would suggest the assistant signing their mail with some sort of "Po" or "PP" signature. You could maybe even write a filter for that to act upon some part of the mail to indicate this.

@ralfbergs
Copy link
Author

OK I see what you mean. Sorry for having replied to quickly because indeed, it doesn't work like that. It will just show as being from "boss@" and not "janet@ on behalf of boss@". I remember that MS Exchange did/does that. Not sure if that's really added value though but that's just my opinion. I would suggest the assistant signing their mail with some sort of "Po" or "PP" signature. You could maybe even write a filter for that to act upon some part of the mail to indicate this.

But that's exactly what the Sender: header is for. It's a mechanism defined in the RFC for the email message format, for cases where an "agent" sends the message on behalf of someone. It would be great if we could use this feature in mailcow...

Outlook shows this as 'Janet Doe' on behalf of 'Big Boss', while Thunderbird would just show 'Big Boss'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants