BillionMail 批量发送任务如何启用发送者 IP 预热（Sender IP Warmup）

BillionMail 批量发送任务如何启用发送者 IP 预热Sender IP Warmup【免费下载链接】BillionMailBillionMail gives you open-source MailServer, NewsLetter, Email Marketing — fully self-hosted, dev-friendly, and free from monthly fees. Join the discord: https://discord.gg/asfXzBUhZr项目地址: https://gitcode.com/GitHub_Trending/bi/BillionMail当一台邮件服务器开始承担批量发送时发送者 IP 需要一个逐步爬升的预热过程而不是直接满速发送。BillionMail 在批量发送任务Batch Mail Task上提供了「关联IP预热系统」开关开启后任务会与该服务器 IP 的预热记录bm_sender_ip_warmup建立关联系统按 IP 当前预热状态限制发件速率并在后台周期性地评估 IP 的得分与预热进度。本文说明如何在创建批量发送任务时启用 Sender IP Warmup以及如何核对预热关联确实生效。预热开关的位置前端任务编辑页 edit.vue 中有一个开关绑定form.warmup字段取值1/0界面文案来自语言包 zh.json标签关联IP预热系统提示开启后将会限制发件速率同一个开关在 API 层对应warmup参数出现在两个接口定义中见 batch_mail.go创建任务POST /api/batch_mail/task/createwarmup v:in:0,1 dc:warmup default:0更新任务POST /api/batch_mail/task/update同样带warmup0 或 1。默认值是0即不启用预热需要显式传1。方式一在控制台创建任务时开启最短路径进入批量发送任务的新建/编辑页面完成发件人addresser、主题、邮件模板template_id和联系人分组group_id等必填项找到「关联IP预热系统」开关并打开即把warmup置为1保存任务。保存后系统会执行预热关联逻辑见 batch_mail.go当Warmup 1时调用warmup.WarmupCampaign().AssociateCampaignWithWarmup(ctx, id, serverIP)把任务与服务器 IP 的预热状态绑定。对已有任务通过更新接口把warmup改为1也会触发同样的关联见 batch_mail.go。方式二直接调用任务创建接口如果通过 API 管理任务可以在创建请求中带上warmup: 1。下面的请求体结构来自仓库中的 E2E 测试 test_06_warmup.py其中addresser、subject、template_id、group_id需替换为你实例中真实的发件邮箱、主题、模板 ID 和联系人分组 IDAuthorization头填你的访问令牌curl -X POST http://你的实例地址/api/batch_mail/task/create \ -H Content-Type: application/json \ -H Authorization: 你的访问令牌 \ -d { addresser: 发件人邮箱, subject: 任务主题, full_name: 发件人姓名, template_id: 1, group_id: 1, start_time: 1757836800, track_open: 1, track_click: 1, unsubscribe: 1, threads: 1, warmup: 1 }注意两点start_time是 UNIX 时间戳E2E 测试里特意把开始时间设为未来一小时int(time.time()) 3600以避免任务立即开始发送测试场景下值得照做。开启后系统实际做了什么关联逻辑在 warmup_with_campaigns.go 中顺序如下初始化或取出该服务器 IP 的预热记录。若bm_sender_ip_warmup表中还没有这个 IP会新建一条预热周期period默认 45 天初始得分score为 40进度progress为 0end_time设为开始时间加 45 天见 sender_ip_warmup.go 与建表默认值 sender_ip_warmup.go写入任务与预热的关联在bm_campaign_warmup表插入一条task_id → warmup_id的记录若任务此前关联的是别的预热 ID会更新为新 ID计算预计发送时长CalculateEstimatedTime用未发送收件人数量除以各邮箱服务商分组Gmail、Yahoo、Outlook、Apple、Proton、Zoho、Amazon、Other调整后的小时发送上限得到预计秒数。任务列表中的estimated_time_with_warmup字段展示这个值-1表示该任务没有启用预热见 batch_mail.go 和前端列表列 index.vue。运行期任务执行器在发送前会检查该任务是否已关联预热warmupAssociated若已关联则对每个收件人按其所属邮箱服务商分组调用RateLimiter().Allow(...)决定是否放行见 task_executor.go。同时后台定时器周期性调用SenderIpWarmup().PeriodicTask(...)见 timers.go基于评估窗口内的送达、硬/软退信、deferred 以及打开/点击数据更新 IP 的score与progress并动态调整预热周期低分会延长周期得分高且进度过半则缩短周期预热完成后若分数显著下降还会触发重新预热逻辑见 sender_ip_warmup.go。验证预热是否生效E2E 测试 test_06_warmup.py 给出了仓库自带的核对方式可以照此验证创建请求返回 HTTP 200 且响应体code 0data.id即新任务 ID用GET /api/batch_mail/task/find?id任务ID能取回任务信息查询数据库确认关联记录存在BillionMail 使用 PostgreSQL$1为任务 ID 参数SELECT id FROM bm_campaign_warmup WHERE task_id $1;返回一行即说明任务已关联预热没有行则说明warmup未生效。另外可查bm_sender_ip_warmup表确认服务器 IP 的记录新 IP 应能看到period 45、score 40、progress 0的初始值以上为代码和建表脚本定义的初始值不是运行一段时间后的固定预期。限制与边界开关的界面提示是「开启后将会限制发件速率」——启用预热的直接效果是任务发送被限速任务整体跑完会变慢任务列表的estimated_time_with_warmup就是该任务在预热限速下的预计耗时预热以服务器 IP为单位而非以任务为单位同一 IP 上的多个预热任务共享同一条bm_sender_ip_warmup记录任务的warmup参数只决定本任务是否接入该 IP 的限速逻辑预热周期不是固定 45 天会按 IP 得分与进度动态伸缩见 UpdateWarmupPeriod预热完成后低分 IP 也可能被重置重新预热。【免费下载链接】BillionMailBillionMail gives you open-source MailServer, NewsLetter, Email Marketing — fully self-hosted, dev-friendly, and free from monthly fees. Join the discord: https://discord.gg/asfXzBUhZr项目地址: https://gitcode.com/GitHub_Trending/bi/BillionMail创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考