1 / 26

An Anti-Spam Method with SMTP Session Abort

An Anti-Spam Method with SMTP Session Abort Nariyoshi YAMAI 1 Kiyohiko OKAYAMA 1 Takumi SEIKE 1 Keita KAWANO 1 Motonori NAKAMURA 2 Shin MARUYAMA 3 1 Okayama University, Japan 2 National Institute of Informatics, Japan 3 CO-CONV Corporation, Japan Existing anti-spam methods

sandra_john
Download Presentation

An Anti-Spam Method with SMTP Session Abort

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Anti-Spam Method with SMTP Session Abort NariyoshiYAMAI1 Kiyohiko OKAYAMA1 Takumi SEIKE1 Keita KAWANO1 Motonori NAKAMURA2 Shin MARUYAMA3 1 Okayama University, Japan 2 National Institute of Informatics, Japan 3 CO-CONV Corporation, Japan

  2. Existing anti-spam methods MIT Spam Conference 2008

  3. Tempfailing(1) • Utilizes difference of MTA behavior after temporary error • Legitimate MTAs • Retry to send the temporarily failed messages • Spam sending MTAs • Prefer throughput • Give up resending the temporarily failed messages MIT Spam Conference 2008

  4. Saves triplet ( Sender IP, SMTP From, SMTP To) Tempfailing (2) First Delivery Second delivery retry Sender IPSMTP FromSMTP To MTA Legitimate MTA temporary error Sender IPSMTP FromSMTP To Spam sending MTA temporary error Recipients MIT Spam Conference 2008

  5. Tempfailing(3) • Problems • RFC2821: 4.5.4.1 Sending Strategy (excerpt) The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes. Causes large delay for legitimate mail delivery MIT Spam Conference 2008

  6. Tempfailing (4) • Problems (cont.) • Utilizes the following triplet for retransmission judgment: • Sender IP • SMTP From • SMTP To Rejects retries from a different MTA MIT Spam Conference 2008

  7. Tempfailing (5) • Problems (cont.) • Rejects before receiving header/body • Logs only the triplet (Sender IP, SMTP From, SMTP To) Difficult to recover false positives MIT Spam Conference 2008

  8. Distributed collaborative filter MTA Spam sending MTA Only messages already read by existent recipients can be filtered out check found not found spam register Spam database Recipients MIT Spam Conference 2008

  9. Anti-spam method withSMTP session abort MIT Spam Conference 2008

  10. Summary of known problems • (Tempfailing) Large delay • (Tempfailing) Retries from a different MTA • (Tempfailing) Recovery from false positives • (Distributed collaborative filter) only messages read by recipients into DB MIT Spam Conference 2008

  11. Features of the proposed method • Introducing two mail gateways (MGs) • Immediate fallback to the secondary MG • (Tempfailing) Large delay • (Tempfailing) Retries from a different MTA • (Tempfailing) Recovery from false positives • SMTP session abort function • Preserving header/body on first attempt • Retransmission judgment with Message-ID or checksum instead of IP • (Distributed collaborative filter) only messages read by recipients into DB • Automatic registration of unresent/undeliverable messages • Early registration of many spam mails MIT Spam Conference 2008

  12. Sender MTA Preserving header/body in case of false positive System layout and behavior (1) Retry × header body Primary mail gateway Preserving header/body Mail gateway InsideMTA TCP segment (RST) SMTP session abort header body Check triplet (MsgID/checksum, SMTP From, SMTP To) Secondary mail gateway After SMTP session to the primary MG is aborted, a legitimate MTA usually sends the message to the secondary MG immediately. Reducing delay of legitimate mail delivery Spam database Retransmission judgment based on header(MsgID) or body(checksum) Organization Recipients MIT Spam Conference 2008

  13. System layout and behavior (2-1) Unknown recipient RCPT TO × header body Primary mail gateway Spam sending MTA recipient check InsideMTA SMTP session abort undeliverable Secondary mail gateway register header body Spam database Organization Recipients MIT Spam Conference 2008

  14. Sender MTA System layout and behavior (2-2) Unknown recipient RCPT TO × header body Primary mail gateway Recipient check InsideMTA SMTP session abort Recipient check header body formerly deliverable Secondary mail gateway RCPT TO register Automatic registration of unresent/undeliverable messages cancel header body Spam database Organization Recipients MIT Spam Conference 2008

  15. User preference of abort timing (1) • Affects network traffic and delay • Possible options • Accept • No session abort • Header • Abort after End of Header • Low traffic/delay • Body • Abort after End of Message • Easy recovery on false positives MIT Spam Conference 2008

  16. Sender MTA User preference of abort timing (2) RCPT TO: A RCPT TO: B RCPT TO: C × Primary mail gateway header body RCPT TO: A InsideMTA SMTP session abort at end of message RCPT TO: B RCPT TO: C Secondary mail gateway RCPT TO: A RCPT TO: B RCPT TO: C accept header body Spam database Organization A B C MIT Spam Conference 2008

  17. Implementation and evaluation of prototype system MIT Spam Conference 2008

  18. Prototype system implementation • Platform • FreeBSD with sendmail & DCC • SMTP session abort function • An external program using “ipfw” • Retransmission judgment • (Message-ID, SMTP From, SMTP To) MIT Spam Conference 2008

  19. First operation test (1) • Objectives • Performance evaluation of blocking/filtering • Test domains • Some sub-domains in okayama-u.ac.jp • Already obsolete five years before • To be removed in one month • Some legitimate mails were possibly sent to these domains • Test period • Seven days from Jan. 29 to Feb. 5th, 2006 MIT Spam Conference 2008

  20. First operation test (2) • Result • 81% (44303/54719) of mails processed were blocked by SMTP session abort • 20% (2180/10416) of mails received were filtered out by DCC • NB: we counted both legitimate mails and spam mails. MIT Spam Conference 2008

  21. Second operation test (1) • Objectives • Comparison with conventional tempfailing as for processing of legitimate mails • Test domain • New sub-domain dedicated for this test • Only 1 IP address available • Two MGs have the same IP address • Usual in small companies in Japan MIT Spam Conference 2008

  22. All messages even from gmail.com were accepted without whitelist Second operation test (2) Small delays of mail delivery from many domains • Result Some domains using qmail still had large delays MIT Spam Conference 2008

  23. Possible false positives • Messages without Message-ID • Use Date: field (mandatory), or • Use the checksum of the body • MTAs without retransmission • Can recover lost headers/bodies easily • Find such MTAs and register them into whitelist • MTAs changing SMTP From address • Use (Message-ID, SMTP To) without SMTP From for retransmission judgment MIT Spam Conference 2008

  24. Conclusions MIT Spam Conference 2008

  25. Conclusions • Combination of three functions • Tempfailing • Distributed Collaborative filter • SMPT session abort • Reduces the drawbacks of existing two methods • Future works • Long term actual performance evaluation • Combination with on-the-fly filters MIT Spam Conference 2008

  26. Questions ?Please speak slowly and clearly MIT Spam Conference 2008

More Related