On Thu, Jul 13, 2017 at 12:42 AM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
vaibhav singh <vaibhavsinghacads@xxxxxxxxx> wrote:
> First of all, I am kind of new and still learning how email
> infrastructure fits in, so please feel free to highlight any glaring
> issues with my logic.
> I was working on implementing Email Delegation for my email server, and
> felt a need to highlight a couple of things.
> 1.) I could not find a place where this workflow is outlined. It seems
> like everyone, from Microsoft to Google, have an implementation for
> email delegation, and they are all kind of doing their own thing.
I think that when you say "email delegation", you mean where a manager
(or other person) authorizes their "PA" (personal assistant, formerly known
as "secretary") to send email on their behalf. Back in the days of BNR COCOS
it was very common thing for middle management, but even in those dark days
of mainframe based email, it was usually accomplished by having the PA log in
with the manager's email.
It's good that microsoft(outlook) and google(gmail) have realized that
sharing passwords is a dumb thing. I think that in the walled gardens of
those systems, that the email delegation is accomplished entirely within
their MUA/MTA.
Exactly!! That is the workflow I am talking about. However, I feel that this could be something which could be used for other things as well, for example, in the place where I work, we have some automated tools where a user can input certain data and the tool will send mails to our group email address on behalf of the user.
Couple of terms:
manager = The user who wants to delegate some other user to manage his account on his behalf.
I think “principal” is a better term. I would expect “manager” to authorize b to manage on behalf of c. delegate = The user who has to get access to the manager's account. entity = Any email user.
Please note that email delegation could also cover cases like creating folders, deleting folders etc in the manager's account. This concept, in my opinion, could be generalized to include "entities" which could request permission to send mails on behalf of some other "entity". Sort of like OAUTH with emails, if you will. I am still hazy with all the details and not sure about how useful this could be, but it seems promising to me.
Another question which I was not clear about was how S/MIME would be integrated with delegation. For example, suppose the delegate were to create a signed email on behalf of the manager, in which case the manager would have to share his private key with the delegate. This would definitely not be secure.
This is part of a wider issue. Even without delegation, if I use my own email account with several MUAs (say, my laptop and my phone), where is the private key stored? Is it shared between laptop and phone?
You end up reading encrypted mail only using one MUA, which is one more thing dragging the use of S/Mime down.
While it may be OK to share a key with my phone (but too difficult to do securely in practice), sharing with a delegate is hairy on many different layers. But still it’s the same issue.
Yoav |