如何为自托管 sim 配置事务邮件提供商让工作区邀请与验证邮件真正发出【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000 builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim自托管 Sim 会发送工作区邀请、邮箱验证、密码重置和各类通知这些邮件全部依赖你在部署环境中配置的事务邮件提供商。问题在于一个提供商都没配的时候不会有任何报错——mailer 只会打印一行包含收件人、主题和发件人的日志然后报告发送成功实际什么都没发而且消息正文不落日志这封漏掉的邮件无法从日志里找回。在生产部署上这意味着工作区邀请会悄无声息地永远到不了。本文的目标就是让邀请和验证邮件真正发出去选择一个邮件提供商、写入正确的环境变量、把凭据放进 Secret最后通过一次真实邀请验证日志。适用于 Docker Compose 或 KubernetesHelm部署的自托管 Sim配置内容参考 邮件配置文档。在邮件配通之前不要设置EMAIL_VERIFICATION_ENABLEDtrue。按 认证文档的说明该开关要求邮箱验证通过才能登录没有邮件提供商时 mailer 只是空转结果就是所有用户永远无法验证、永远无法登录。提供商如何选择固定顺序的 failoverSim 没有启用哪个提供商的开关变量。所有设置了变量的提供商都会激活mailer 按固定顺序尝试只有上一个失败才落到下一个Resend → AWS SES → SMTP → Azure Communication Services → Gmail所以排在前面的提供商承接正常流量其余配置都自动充当兜底。只配一个是最简单的情况配两个会多一份 fallback 路径代价是偶发情况下邮件可能从另一个发件地址发出。下面按常见程度给出各提供商的配置选一条主路径即可其余可留作可选分支。公共配置发件人地址无论选哪个提供商都需要先定发件人。这几个变量各提供商共用变量说明FROM_EMAIL_ADDRESS发件地址例如Sim noreplyexample.comEMAIL_DOMAIN未设置FROM_EMAIL_ADDRESS时的兜底域——以noreplyEMAIL_DOMAIN发送EMAIL_VERIFICATION_ENABLED设为true后注册必须完成邮箱验证文档把发件地址不匹配列为邮件被丢弃的头号原因发件地址必须是你的提供商已授权可发送的地址否则邮件可能被提供商接收后在下游被静默丢弃或判为垃圾邮件。主路径一Resend没有现成邮件基础设施时最简单RESEND_API_KEYre_... FROM_EMAIL_ADDRESSSim noreplyyourdomain.com其中re_...换成你在 Resend 平台拿到的 API keyyourdomain.com换成你自己的域名。上线前要在 Resend 控制台完成发送域名验证并添加它给出的 DNS 记录。主路径二SMTP已有任意中继可用SMTP 路径兼容任意中继——Postfix、SendGrid、Mailgun、Google Workspace SMTP relay本地测试可以用 MailHogSMTP_HOSTsmtp.example.com SMTP_PORT587 # 465 implicit TLS, 587 STARTTLS, 25 plain SMTP_USERapikey # omit for unauthenticated relays SMTP_PASS... # omit for unauthenticated relays # SMTP_SECUREtrue # only for implicit TLS. Leave unset on 587 — it is # automatic on 465, and forcing it on a STARTTLS port fails to connect # SMTP_EHLO_NAMEmail.yourdomain.com # only if the relay expects an identity other # than the domain Sim is served from FROM_EMAIL_ADDRESSSim noreplyyourdomain.com几个适用条件SMTP_PORT按你的中继协议选465 是 implicit TLS587 是 STARTTLS25 是明文。SMTP_SECURE只在 implicit TLS 时设置。587 端口上留空——465 会自动启用而在 STARTTLS 端口强行开启会导致连接失败。SMTP_EHLO_NAME几乎用不上Sim 会用自身服务域名由NEXT_PUBLIC_APP_URL推导向中继打招呼。Kubernetes 上 pod 主机名不含点号若不这样推导底层邮件库会退化成[127.0.0.1]严格中继会直接拒绝这个问候。走 Google Workspace 但没有服务账号时用中继而不是 Gmail APISMTP_HOSTsmtp-relay.gmail.com、SMTP_PORT587。需要在中继侧把你的部署出口 IP 加入 Workspace 管理控制台的允许列表不需要服务账号和域名级委托除非无法固定出口 IP文档建议优先这条路径而非 Gmail API。可选分支AWS SES、Azure ACS、Gmail APIAWS SESAWS_SES_REGIONus-east-1 FROM_EMAIL_ADDRESSSim noreplyyourdomain.com凭据走标准 AWS provider chain环境变量、shared config、ECS/EKS task roleIRSA、EC2 实例 profile 或 SSOEKS 上给 IRSA 角色加ses:SendEmail和ses:SendRawEmail即可一个 key 都不用配。注意新 SES 账号处于sandbox状态只能发给已验证的地址团队邀请会失败需要先申请 production access同时完成发送域名验证和 DKIM 配置。Azure Communication ServicesAZURE_ACS_CONNECTION_STRINGendpointhttps://...;accesskey... FROM_EMAIL_ADDRESSSim noreplyyourdomain.com先开通 Email Communication Service、连接已验证的域名再把它关联到 Communication Service 资源发件地址必须属于已关联的域名。Gmail APIGCP 没有第一方事务邮件服务Google 原生路径就是 Gmail API Workspace 发件人GMAIL_CREDENTIALS_JSON{type:service_account,...} GMAIL_SENDERnoreplyyourdomain.com FROM_EMAIL_ADDRESSSim noreplyyourdomain.com步骤创建服务账号并下载 JSON key在 Workspace 管理控制台Security → Access and data control → API controls → Domain-wide delegation → Add new中登记服务账号的client_idscope 为https://www.googleapis.com/auth/gmail.sendGMAIL_SENDER设为服务账号所冒充的 Workspace 用户。两个限制FROM_EMAIL_ADDRESS必须与GMAIL_SENDER或其已注册别名一致Gmail 会改写无法识别的 From 地址不匹配时邮件发送成功但显示为错误发件人Gmail 每用户每天约 2,000 封的上限对邀请和验证场景足够超出则换成 Workspace SMTP 中继或 Resend都是纯配置改动。粘贴 JSON 到 values 文件时保持单行jq -c . service-account-key.jsonKubernetes 上把凭据放进 Secret邮件凭据是 secret应经 Secret 存储提供而不是明文 values。values.yaml里这样写app: env: FROM_EMAIL_ADDRESS: Sim noreplyyourdomain.com RESEND_API_KEY: re_... # via External Secrets or an existing Secret在 default 和 External Secrets 两种模式下app.env的 key 会写入 chart 管理的 Secret 并经envFrom挂载不会出现在 pod spec 里。但提交进values.yaml的 secret 依然是你 git 历史里的 secret——更稳妥的做法是走 External Secrets 或预先创建的 Secretapp.secrets.existingSecret见 Kubernetes 文档。另外app.env下的 key 同时会落到 realtime pod 上——chart 把它们写入一个两个 Deployment 共享的 Secret。验证发一次真实邀请并看 mailer 日志文档给出的验证方式是端到端的从 workspace 设置里邀请一个用户然后看应用日志。先确保日志级别能看到 mailer 的那行输出。生产构建下 logger 默认ERROR此时什么都不会记——Verify 文档的说明是把LOG_LEVEL提到INFO变量名只接受大写才能看到 no-op 那一行。Kubernetes 上kubectl logs -n simstudio -l app.kubernetes.io/componentapp --tail100 | grep -i mailDocker Compose 部署等价地查看应用容器日志服务名simstudio与docker compose -f docker-compose.prod.yml ps中列出的一致docker compose -f docker-compose.prod.yml logs --tail100 simstudio | grep -i mail按 Email 文档的对照表判断结果看到的日志含义只有一行含收件人、主题、发件人的日志没有投递没有配置提供商——mailer 空转了提供商 API 报错凭据或发件地址问题错误信息会指出是哪一个显示成功但收件人没收到邮件已交给提供商——去提供商控制台查投递再依次排查垃圾邮件过滤、SPF、DKIM一行日志 报告成功 实际未投递是最容易误判的情况它不代表配置成功恰恰说明没有任何提供商被激活。常见故障对照Delegation denied /unauthorized_clientGmail域名级委托条目缺失、client ID 或 scope 错误。对照服务账号 JSON 里的client_id重查管理控制台条目确认 scope 恰好是https://www.googleapis.com/auth/gmail.send。From 地址报错被拒收发件人未在提供商已验证域名上授权。把FROM_EMAIL_ADDRESS与已验证域名对齐Gmail 路径还要与GMAIL_SENDER对齐。SES 拒绝收件人账号仍在 sandbox申请 production access。邮件进了垃圾箱为你的发送域名配置 SPF、DKIM、DMARC——这是你 DNS 上的事不在 Sim 侧。SMTP 在问候阶段报421-4.7.0 Try again later, closing connection. (EHLO)中继拒绝的是客户端的自我标识方式不是凭据或 IP 白名单。严格中继Google Workspace 是其中之一不接受非完全限定域名的问候。Sim 已改为用服务域名问候理论上不应出现若仍出现把SMTP_EHLO_NAME设为中继接受的一个带点主机名。旧版本在 Kubernetes 上总是以[127.0.0.1]问候——文档的建议是升级而不是绕过。配通之后验证表格确认邀请真正投递后再做两件事一是可以安全地设置EMAIL_VERIFICATION_ENABLEDtrue要求注册时完成邮箱验证认证文档明确要求先确保邮件可用二是如需要兜底路径再配置第二个提供商——顺序表中靠前的承接流量后一个自动 failover。整套安装的其他子系统检查可继续走 Verify Your Install清单其中第 9 步从 workspace 设置邀请一位队友正是对邮件链路的复验。【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000 builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考