自從電子郵件大大降低了信息的傳播成本，垃圾郵件便隨之而產生。
筆者作為國內互聯網的較早的用戶，使用的是自己注冊的域名的電子郵件地址，從一開始使用至今一直沒有變過，而該郵件地址在國內互聯網發展初期曾注冊過許多網站服務，因此成為垃圾郵件的目標。
筆者的郵件地址在2000年即每天收到近百封垃圾郵件，因此從那時即開始關注垃圾郵件的控制方法。
2004年1月底，國家四部委聯合發文整治垃圾郵件和不良信息，快速啟動了國內反垃圾郵件的市場，反垃圾郵件產品廠商風起云涌，但筆者認為許多宣傳僅從郵件安全的某個局部出發，失于片面。反垃圾郵件僅僅是郵件安全的一部分技術，郵件安全至少應當包括反垃圾郵件、反郵件病毒、內容過濾等功能，還可能包括郵件溯源、郵件審計等功能。本文由于篇幅所限，只說明反垃圾郵件的技術。
1. SMTP安全漏洞與垃圾分析
1.1 SMTP起源
在互聯網上使用的郵件傳輸協議稱為SMTP(Simple Mail Transfer Protocol簡單郵件傳輸協議，RFC-821)，也許有很多初次了解SMTP協議的人會奇怪為什么稱為簡單郵件傳輸協議，那么復雜郵件傳輸協議在哪里？如果這樣考慮，可以理解1984年ISO(國際標準化組織)和ITU(國際電信聯盟)發布的X.400信件傳遞標準就是復雜郵件傳輸協議(當然，其相關協議早在近十年前就在討論、完善，只是直到1984年才發布標準)。1982年由互聯網協會發布了基于TCP/IP的SMTP(RFC821)后，隨即發布了RFC822 ASCII純文本郵件結構，這樣就滿足了人們發送純文本郵件的需求，隨著需求的增長，1996年發布了一系列MIME(Multipurpos Internet Mail Extensions)格式定義，使電子郵件可以傳遞任意格式的文件，大家發送郵件時會發現，郵件的大小比附件的大小要大很多，原因就是附件可能經過了MIME編碼，導致變大。MIME滿足了人們發送任意格式郵件的需求，也同時導致了惡意代碼通過電子郵件傳遞。
1.2 郵件發送過程
一封郵件從發件人編輯郵件到收件人接收郵件一般要通過如下四步：
1. 發送客戶端‘(smtp)‘發送郵件服務器：發件人在發送客戶端(~MUA~，~Mail User Agent~)編輯郵件后發出，MUA向他定義的發送郵件服務器(~MTA~，~Mail Transport Agent~)發出SMTP請求并握手，發送郵件服務器將郵件接收下來放在相關的郵件隊列中。一般來說，MUA在和發件MTA握手時，使用的是用戶在MUA該帳號上注冊的郵件帳號信息作為信封Mail From和信頭From的參數，是相同的；
2. 發送郵件服務器-->(smtp)-->接收郵件服務器：發送郵件服務器根據郵件的目的地址，如果目的地址不是本地，則會將郵件轉而放到相應的發送隊列中，MTA將郵件從等候的發送隊列中取出，向接收郵件服務器發起SMTP請求并握手，接收郵件服務器將郵件接收下來，放入相關的郵件隊列中。一般來說，發送MTA會把郵件的信封部分和郵件部分(data，包括信頭和信體)分開保存，這樣在與接收MTA通信時，Mail From依然使用原來的信息不變；
3. 接收郵件服務器dispatch到郵箱：接收郵件服務器根據郵件的目的地址(當然是本地了)，將郵件由MDA(Mail Deliver Agent)放到用戶的郵箱中。接收MTA在和發送MTA握手時，得到的Mail From數據仍然是發件MUA給出的信息。
4. 郵箱服務器-->(pop/imap)-->接收客戶端：最后，接收客戶端使用POP或IMAP協議將郵件下載、閱讀。
1.3 模擬收發過程
SMTP協議是TCP/IP協議的應用層協議，其傳遞的數據都是人可讀的數據，因此可以使用Telnet來仿真、觀察SMTP協議的握手過程(假設郵件服務器IP是192.168.100.100)。
Telnet 192.168.100.100 25 ; 25是TCP/IP協議給SMTP定義的端口號
<<< 220 smtp.my.com ESMTP Service (SMTP server) ready at 日期、時間 +0800
>>> helo haha.com
<<< 250 smtp.my.com Hello haha.com ([192.168.100.50]), pleased to meet you
>>> mail from:abc@abc.com
<<< 250 abc@abc.com... Sender OK
>>> rcpt to:realname@my.com
<<< 250 realname@my.com... Recipient OK
>>> data
<<< 354 Enter message, end with "." on a line by itself
>>> Reply-to:ccc@ccc.com
>>> From:aaa@aaa.com
>>> To:bbb@bbb.com
>>> Subject:testest
>>>
>>> This is a Test Email.
>>> .
<<< 250 Message accepted for delivery
>>> quit
<<< 221 smtp.my.com SMTP Service closing transmission channel
這樣就用Telnet直接向smtp.my.com送入了一封給realname用戶的郵件。
讓我們來看一下收到的這封郵件的源文件：
Received: from haha.com ([192.168.100.50])
by smtp.my.com (SMTP server)
with SMTP id 2004062314152297-16576 ;
Wed, 23 Jun 2004 14:15:22 +0800
Reply-to:ccc@ccc.com
From:aaa@aaa.com
To:bbb@bbb.com
Subject:testest
X-MIMETrack: Itemize by SMTP Server on Mail/my() at 2004-06-23 14:17:10,
Serialize by POP3 Server on Mail/my() at 2004-06-23 14:18:45,
Serialize complete at 2004-06-23 14:18:45
Date: Wed, 23 Jun 2004 14:17:10 +0800
Message-ID: <OF39FF5AC9.A74F14E2-ON48256EBC.00228835@my.com>
This is a Test Email.
從上面的模擬過程可以看出，該郵件在郵件頭中聲稱郵件來自~aaa@aaa.com~，要發給bbb@bbb.com；而在SMTP握手中聲稱使用計算機haha.com，郵件來自abc@abc.com，要發給realname@my.com(這是真正收到該郵件的用戶)。郵件頭的說法和SMTP握手中的說法完全不同，而當用戶(~realname@my.com~)收到此郵件時，他所能看到的只是郵件頭中所聲稱的內容和發送該郵件所聲稱的機器名和IP。然而，要使用戶realname收到這封郵件，除了SMTP握手中rcpt to必須是真實的以外，其他所有東西都可以偽造，From:和To:都可以不寫。尤其不幸的是：為了返回錯誤提示郵件，SMTP協議甚至允許mail from:后面是空白。
上面data后的內容是真正的郵件，data之前的內容是SMTP握手，或稱信封。用戶收到的郵件已沒有信封，但SMTP服務器可能會根據信封內容在data的信頭部分增加Received數據保存一些信封的內容。
在郵件客戶端，用戶將看到郵件來自aaa@aaa.com，而回復時，自動將ccc@ccc.com作為目的地址。
上述郵件模擬發送過程中，只有收件人地址是真實的(呵呵，否則誰收啊？)；收到的郵件看到的源文件，只有最后一個發件IP是真實的(前面如果還有，也可能是偽造的)。