C#调用Gmail SMTP发授权邮件报5.7.0错误解决方案咨询
问题根因
你碰到的SMTP 5.7.0报错没有其他原因,就是谷歌2022年5月30日正式下线了「低安全性应用访问」通道,直接用谷歌账号的登录密码走SMTP认证的方式已经彻底失效,和你代码里的发信逻辑本身没有太大关系。另外你代码开头那堆Encoding转码是完全无效的冗余代码,重复给EnableSsl赋值两次也没有必要。
目前可用的Gmail发信实现方式
方案一:应用专用密码(改造成本最低,适配你现有代码)
这个方案要求你的谷歌账号已经开启两步验证,未开启两步验证的账号无法生成应用专用密码:
- 进入谷歌账号管理的「安全性」页面
- 找到「两步验证」选项,完成身份校验后开启功能
- 两步验证开启后,安全性页面会新增「应用专用密码」入口
- 应用类型选「邮件」,设备选当前使用的开发设备,点击生成即可得到16位的应用专用密码
- 把你代码里原本填写的谷歌账号登录密码,替换成这个16位应用专用密码即可,原有的SMTP配置(服务器地址smtp.gmail.com、端口587、开启SSL)不需要调整
方案二:Gmail API + OAuth2.0认证(官方推荐,适合正式商用场景)
如果不想开启两步验证,或者要做面向用户的正式产品,不建议用账号/应用密码的方式,应该走标准OAuth授权流程:
- 到谷歌云控制台创建对应项目,启用Gmail API服务
- 申请创建OAuth2.0凭据,获取客户端ID、客户端密钥
- 在程序中实现OAuth授权跳转逻辑,拿到对应账号的发信权限访问令牌,用令牌替代密码完成SMTP认证
- 这个方案不需要用户提供账号明文密码,安全性更高,但改造成本远高于应用专用密码方案
现有代码的修正点
你代码开头写的6段Encoding转码逻辑完全没有存在的必要,Encoding.Default在不同语言、不同版本的操作系统下默认编码不统一,反而可能把正常的字符串转成乱码,直接删掉即可。另外你传入了name参数但全程没有使用,发件人名称可以在构造MailAddress对象时传入,同时要明确指定邮件各部分的编码为UTF8,避免中文乱码。
修正后的核心代码如下:
public static class EmailSender { public static bool Send (string from, string to, string subject, string senderName, string body, string fromPass) { MailMessage message = new MailMessage(); // 构造发件人信息时传入显示名,统一指定UTF8编码避免乱码 message.From = new MailAddress(from, senderName, Encoding.UTF8); message.To.Add(new MailAddress(to)); message.Subject = subject; message.SubjectEncoding = Encoding.UTF8; message.Body = body; message.BodyEncoding = Encoding.UTF8; // 如果要发送HTML格式邮件,把下面属性设为true message.IsBodyHtml = false; SmtpClient client = new SmtpClient("smtp.gmail.com", 587) { EnableSsl = true, DeliveryMethod = SmtpDeliveryMethod.Network, UseDefaultCredentials = false, // 使用应用专用密码时,此处fromPass填入生成的16位密码即可 Credentials = new NetworkCredential(from, fromPass) }; try { client.Send(message); return true; } catch (Exception ex) { MessageBox.Show(ex.Message, "Information", MessageBoxButton.OK, MessageBoxImage.Information); return false; } } }
Onet邮箱发信失败说明
你用Onet邮箱发信失败是因为直接套用了Gmail的SMTP配置,不同邮箱服务商的SMTP服务器地址、端口、认证规则都不一样,Onet邮箱需要单独查对应的SMTP配置参数,另外大部分第三方邮箱默认会关闭SMTP发信权限,需要先登录网页版邮箱,在设置里手动开启SMTP服务后才能正常调用。
注意:个人邮箱不适合用来批量发送注册验证类事务邮件,很容易被服务商判定为垃圾邮件拦截,正式上线的产品建议使用专门的事务邮件推送服务。
内容的提问来源于stack exchange,提问作者Giusek keisuG
相关产品推荐
相关产品推荐

