爲了打擊點對點垃圾短信，最近三大運營商擬執行“短信限發令”：每號碼在非節假日期間每小時不得超過200條，每天總量不得超過1000條，節假日每小時不超過500條，每天總量不得超過2000條。
我認爲，“短信限發令”的出現是個很大的進步，標誌着運營商在打擊垃圾短信問題上終於採取實質性的措施。但是，當前短信限發依據“發送量”作爲判斷標準，完全沒有抓住垃圾短信的關鍵特徵，將會帶來很多問題，建議短信限發以“發送號數數”作爲判斷標準，並以實時監控和每日監控作爲技術手段加以實現。
（一）進步之處
1、從空想到務實
在垃圾短信治理問題上，意見很多，但大部分意見都是瞎掰，因爲根本不具備實際的可操作性。
其中一類典型意見就是靠內容過濾。
如果有人相信依靠內容特徵可以過濾垃圾短信，那麼這個人肯定沒有真正做過垃圾短信治理。事實上，不少運營商早在幾年前就上線了內容過濾系統。內容過濾初期還有些微弱的效果，後來被羣發商摸透了，就徹底沒有效果了。相信憑內容可以過濾垃圾短信，不如相信綠壩能根除一切“不良信息”，因爲綠壩可以根據整個網頁的內容來判斷，而短信卻只有短短幾十個字。
這次“短信限發令”依靠用戶特徵來過濾，是走在了正確的道路上。
2、從各自爲政到步伐一致
垃圾短信治理之難，在於這是個系統工程，僅靠各省自己努力只會按下葫蘆浮起瓢。
“限發令”標誌着垃圾短信治理上升到行業標準層面，爲系統解決垃圾短信問題指明瞭方向。
（二）重大缺陷
但是當前“限發令”實在太粗糙，沒有抓住垃圾短信的關鍵特徵：短時間內向大量不同對象發送短信。
“發送量”不能作爲判斷正常號碼和羣發號碼的標準。儘管羣發號碼發送量確實很大，但發送量大的卻未必是羣發號碼。一些拇指族在一個小時內發送200來條短信是很輕鬆的事情。另外，一些公司利用手機短信進行系統監控、告知等，發送量也很大，而且也很正常，因爲其發送對象不會很多。至於M2M類行業應用就更加不用說了，一小時可能發送的短信量遠遠超過這個數，但其發送對象卻往往只有一個。
所以，目前短信限發令“誤傷無辜”的概率非常之高，一旦實施，將帶來多方面的問題。
（三）我的建議
所以，我建議採取“發送號碼數”作爲判斷羣發的標準。對應的分析方法可稱之爲“號碼離散度分析法”。
採取“號碼離散度”發，限發令可以修改如下：每號碼在非節假日期間每小時不得向超過200個號碼發送短信，每天發送號碼總量不得超過500個，節假日每小時不超過500個，每天總量不得超過1000個。
“號碼離散度分析法”並不難實現。整個技術實現分成兩個模塊：實控模塊和日控模塊。
1、實控模塊
實控模塊用於用於每小時“發送號碼數”的控制。
實現如下：短信中心爲這一小時內每個發送過短信的用戶增加一個記錄項，記錄項包含兩項信息：對端號碼和發送時間。若記錄項超過一個小時，那麼進行刪除。若一個小時記錄內記錄項超過200個，那麼執行限發指令。
這樣一個月短信話單雖然很多，但分散到每個短信中心、每個小時的話單量已經不多。另外，由於大部分用戶發送對象都比較集中，所以增加的記錄項並不會很多。整個實時監控並不需要太大的內存開銷和系統開銷，所需的僅僅是設計一個合理的數據結構和選擇一個合適的算法而已。
2、日控模塊
日控模塊用於每天“發送號碼數”的控制。
日控模塊不是一種實時控制，而是一種事後控制，因爲兩者的系統開銷可能相差百倍。
實現如下：每天凌晨，對昨天的短信話單滾一遍，找出發送對象數超過1000個號碼。然後，結合用戶是否通話等信息決定是否進行短信功能限制或停機。
目前，我每天也在運行這樣的一個垃圾短信分析程序。核心代碼只有幾十行，全部代碼也只有幾百行，非常簡單。按照每天3億條短信發送話單計算，單進程運行最多需要2個小時，若多進程並行速度會快很多。
===============================================================
我寫的垃圾短信系列博文：
1. 垃圾短信治理的關鍵在於疏堵結合
2. 號碼離散度分析法在打擊點對點羣發中的應用
3. 號碼離散度分析法在打擊網間垃圾短信中的應用
4. 號碼集中度分析法在打擊SP端口羣發中的應用
5. 號碼集中度分析法的PL/SQL實現
6. SP第三方羣發問題分析及解決建議
7. 黑網關羣發問題分析及解決建議
8. 基於單用戶的不均衡通信費結算辦法研究
9. 遏制垃圾短信不能只管短信單價