Re: Need for secured email delegation workflow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Jul 12, 2017, at 3:03 AM, vaibhav singh <vaibhavsinghacads@xxxxxxxxx> wrote:
> 
> 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 suspect this topic is not really appropriate for this list, so I'll keep this brief.

> Am I missing something here? Is this something which should be an Internet draft/RFC?

It seems you want to authorize a third party to send email on your behalf.
It is not clear that logistical guidance of how to do is proper subject
matter for an RFC.  The relevant technical standards are:

	* DKIM, allows you to delegate a keypair and a "selector" for a third
	  party to send authenticated email with "d=<yourdomain.example>"

	* SPF, allows you designate a set of SMTP clients that are authorized
	  to originate email with envelope sender addresses in your mail.

	* SMTP generally allows any client to send from any domain.  Any
          constraints that block third parties from sending on behalf of
	  of your domain are "self inflicted" (restrictive SPF, abominable
          DMARC).  To the extent that you employ these, they provide the
          means to exempt third parties from your own restrictive policies.

Any process that the third party wants you to follow in order to register
with them to send on your behalf is I think outside the scope of IETF
standards.

-- 
	Viktor.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]