Python脚本部署至GitHub或打包EXE时如何安全隐藏存储发件邮箱密码

只要你的程序是跑在别人控制的设备上，就根本不存在能100%藏住的SMTP密码——你之前觉得“把加密密钥放脚本里等于白给”的判断完全正确。不管你套多少层加密，程序运行的时候总得把明文密码传给smtplib做登录，有逆向能力的人拆包EXE、抓运行时内存，最多半小时就能把密码扒出来，这种所谓的“加密”除了拦完全不懂技术的新手，没有任何实际安全作用。

如果你要把脚本放到GitHub给其他开发者用 #

别想着把你的个人发件密码硬塞进公开仓库，这种操作不出3天就会被全球爬虫扫到，拿你的邮箱发垃圾邮件最后直接被Gmail封停。之前你觉得环境变量麻烦的问题，完全可以换个用户友好的方式解决：

• 公开仓库里只留配置模板，比如写个.env.example，里面空着留SENDER_EMAIL=、GMAIL_APP_PASSWORD=的占位
• 在.gitignore里把真实的本地配置文件.env屏蔽掉，绝对不提交到公开仓库
• 脚本里加自动加载逻辑：第一次运行的时候检测不到本地.env文件，就直接在命令行弹提示让用户填自己的发件账号信息，自动写入本地.env，下次运行直接加载——全程不需要用户手动找系统环境变量在哪设置，对开发者来说门槛极低
• 如果你只是想给仓库跑CI测试的时候用发件功能，把自己的凭证存在GitHub仓库的私有密钥库里就行，测试流程里自动读取，根本不需要把密钥写进公开代码

如果你要打包成EXE给普通终端用户用，要求开箱即用 #

你从根上的思路就错了：根本不要把你自己的个人Gmail凭证直接嵌到分发的EXE里，正确的实现方式是把发信逻辑移到服务端：

• 搭个最简单的轻量接口当发信中转：客户端EXE只需要把收件人、要发的内容POST到你的接口，服务端校验合法之后，用你自己的邮箱账号走SMTP发出去
• 这种方案的好处：
  • 你的邮箱密码完全存在你自己的服务器上，不管用户怎么拆EXE、翻内存都拿不到
  • 可以在服务端限制发信频率、过滤垃圾内容，不会因为EXE被恶意传播导致你的邮箱被滥用封禁
  • 终端用户完全不需要任何配置，真正做到开箱即用
• 不想自己搭服务器的话，就用现成的事务性邮件服务，把服务端的发信密钥存在你自己的可控环境里，客户端调用的时候做简单的权限校验，绝对不要把API密钥直接硬编码到客户端程序里

额外提一句你现有代码的小bug #

你现在写的脚本里定义了text变量，但根本没有把它通过message.attach()加到MIMEMultipart结构里，现在实际发出去的邮件是没有正文的，后面改逻辑的时候记得补上。

内容的提问来源于stack exchange，提问作者cording12