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.
> 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@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature