On Thu, Jul 13, 2017 at 12:42 AM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:
vaibhav singh <vaibhavsinghacads(_at_)gmail(_dot_)com> 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.
*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.
> 2.) As I could not find any RFC/Internet Draft covering this flow, I
> could, potentially, create a really bad email delegation
implementation
> in which I could allow potentially anyone to send mails on behalf of
> anyone, and I will still be, say, RFC-2822 compatible (I may be
RFC2822 (and 822 before it, and the one for that) always let anyone send
any
email claiming to be from anyway. That was both a strength
("permissionless
innovation"), and led to our spam disaster. So as others in this thread
have mentioned, we have SPF to give clues as to which IP addresses are
authorized to speak authoritative for a domain, and DKIM to make sure that
the headers are authentic (and optionally body). Neither provides for
content
signing that is reachable by end users at this time.
I don't think you are looking for SPF or DKIM, unless you are trying
to seperate the PA and the manager into different (submission) mail
systems.
All of this is MTA to MTA protocol, not MUA to MTA.
> incorrect here, but I could not really find any place which would
> restrict a user from sending an email on someone's behalf, by editing
> the "Sender" header before sending an IMAP request.)
Since you speak about IMAP, you are clearly not in the MTA business, but
I suspect in the MUA side of things. Maybe I'm wrong and you are building
IMAP servers. I didn't think that IMAP included email submission, but I'm
sure I'm not up to speed... (30 years since I wrote that MTA for
AmigaOS...)
So let me speak about email submission protocol (rfc4409) and you can
substitute IMAP if that is in fact appropriate.
It seems to me that a mail server that has an authorized user SHOULD force
the SMTP From (aka "Sender") to the authorized user. Perhaps it MAY also
force the body From: to a specific value, but I haven't encountered an
open source one that does. It seems that you are asking how a MUA could
indicate (and provide proof) that it is authorized to set the From:
order Sender: to another value. (I really think, btw, you want to set
the From: to the manager, and leave the Sender: as the PA)
This seems like it might be the space for a SAML assertion.
I believe that many IMAP servers use small subsets of SAML to provide
mailbox
ACLs, and it would fit right in there. I suspect that there is space for
an RFC about how to do this in a standard way.
--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software
Works
-= IPv6 IoT consulting =-
--
Regards,
Vaibhav Singh