1.  公司的郵件發(fā)送平臺(tái)(用戶登錄注冊(cè)，營銷推廣，人力資源等)，今天有反應(yīng)一封測試中的新模板郵件發(fā)送失敗。

2. 現(xiàn)有流程是： java將待發(fā)送信息寫入linux 下mysql db--->c讀取table，通過smtp協(xié)議connect多臺(tái)smtp服務(wù)器(后臺(tái)可設(shè)定管理)發(fā)送郵件。并發(fā)模式為：多進(jìn)程(不同業(yè)務(wù))，多線程(同一業(yè)務(wù)的用戶郵箱列表分發(fā)投遞到多臺(tái)sendmail服務(wù)器)。

3. c組調(diào)試獲取err log "get data=552 5.6.0 Headers too large (32768 max)"。 查找資料是因?yàn)閟endmail對(duì)郵件的檔頭header，默認(rèn)有32768Bype的限制。

4. vi /etc/mail/sendmail.cf,  modify MaxHeadersLength=9999999,  restart sendmail

5. ok,問題解決

-------------------后記------------------------------------

## 郵件群發(fā)平臺(tái)存在一個(gè)待優(yōu)化的問題就是：

目前待發(fā)送的郵箱列表是在初始加載時(shí)均分( nTotalTasks / nSmtpSrvCnts )到各臺(tái)服務(wù)器發(fā)送，但實(shí)際情況是各臺(tái)快慢差別很大。(早干完活的就在那"看戲"，最后就剩一個(gè)苦逼的在跑，任務(wù)一直沒有結(jié)束)

優(yōu)化方案：

1. 將task量的分配最小化。1個(gè)線程連1臺(tái)smtp服務(wù)器，1次取1條mail, 線程間用pthread_mutex_lock/unlock()避免取到同條任務(wù)，flag標(biāo)記取走狀態(tài)。

2. 最慢的那臺(tái)"苦逼"的原因，除了服務(wù)器性能和網(wǎng)絡(luò)狀況，主要是因?yàn)榘葱蚍峙浣o他的大部分郵箱號(hào)是不存在或無法到達(dá)的(如惡意批量注冊(cè))，郵箱域名的dns解析超時(shí)(30s)，所以賊慢。 解決辦法是優(yōu)化sendmail配置參數(shù)同時(shí)線程設(shè)定socket timeout。

## 后期可考慮新增的功能：

1. 支持抄送和小容量的附件發(fā)送。

2. 將系統(tǒng)監(jiān)控報(bào)警/通知的郵件發(fā)送整合到此平臺(tái)下。

## 不曉得各郵件運(yùn)營商反垃圾郵件的算法規(guī)則。(業(yè)務(wù)部門反饋，我也沒辦法，誰讓他們整天亂發(fā))

1. 控制發(fā)送量的大小、頻率，時(shí)常更換smtp服務(wù)器IP可能有點(diǎn)效果。

2. 提示用戶點(diǎn)擊信任此發(fā)件人