今天的问题是在使用pop邮箱的时候，有账号出现发送邮件时邮件服务器响应为: 5.7.1 Client does not have permissions to send as this sender。

然后使用[PS] C:\>get-mailbox "User Alias" | add-adpermission -user "NT Authority\Self" -ExtendedRights Send-As, Receive-As命令将NT AUTHORITY\SELF权限进行添加可以正常发送邮件，但是没有过多久由出现 邮件服务器响应为: 5.7.1 Client does not have permissions to send as this sender 的报错。经过几次尝试之后依然是这样最后查阅了一些相关资料找到解决办法

1.原因：

活动目录服务有个处理过程是为了保证受保护组的安全描述符不被改动。如果一个属于受保护组的账号的安全描述符跟AdminSDHolder object的安全描述符不匹配的话， 
那样这个账号的安全描述符会被AdminSDHolder object的安全描述符所覆盖。

由于修改Send As权限是通过修改用户的安全描述符来实现的，因此假如一个用户是属于某个受保护组的话，上述修改会在一个小时左右执行，即把AdminSDHolder object的安全描述符覆盖到这个用户的安全描述符，因为Send As属于安全描述符的其中的一个权限，所以同时也会被覆盖，最终导致NT AUTHORRITY/SELF 权限丢失。

而我的实践经验也发现，凡是属于受保护组的账号，都是没有Send As权限的。

2.受保护的组大概有哪些

Administrators 
Account Operators 
Server Operators 
Print Operators 
Backup Operators 
Domain Admins 
Schema Admins 
Enterprise Admins 
Cert Publishers

还有一点，有两个特殊账户也是受保护的： 
Administrator 
Krbtgt

3.如果将用户上述组的成员或者用户，Send As权限就会丢失。

微软官方建议不要使用受保护组成员来作为邮箱账号。假如你真的需要受保护组的那些权限，建议你使用两个域账号。 一个用来加入受保护组，另一个用来作为邮箱账号。

由于办公过程需要操作AD，所以加入了Account Operators这个组，就可以在本机使用dsa.msc来操作AD的账号了，随之就出现NT AUTHORRITY/SELF 权限丢失了。

所以呢，碰到这些问题的朋友们，还是按照微软的建议，分开两个账户来使用吧，总之就是不要把要用到邮箱的账号加入到上述的受保护组，即使你拼命添加NT AUTHORRITY/SELF这个权限，过一个小时左右照样会不见的。