Internet Safety Microsoft’s Anti-SPAM Strategy and Initiatives Meng-Chow Kang, CISSP, CISA Chief Security & Privacy Advisor Microsoft Asia Pacific Anti-SPAM Strategies – The Way Forward ASEAN Telecommunications Regulatory Council (ATRC) May 3-4, 2005, Cyberjaya, Malaysia Evolving SPAM Attacks • Identity Theft Virus Worm Spyware Trojans Scams • Data Leakage/Theft • DDoS Extortion • Frauds • Software Piracy • Illegal Downloads Microsoft Anti-Spam Strategy Industry Collaboration & Partnerships Govt Partnerships Strong Laws & Enforcement Education & Enablement e-mail user Protection Filters Prevention Agents Proof: Identity & Evidence “Sender ID” Computational Cycles Certificates Sender Safelists Attack detection Sender reputation Outbound filtering SmartScreen At gateway, server & desktop Update Service Technology Strategy Build an integrated, distributed system of interconnected countermeasures Target key choke points Proof, Prevention and Protection Prevent before it happens Protect against attacks Proof of identity and evidence A foundation based on authentication, accreditation and reputation Why Authentication? Sender Reputation • • • Content Filtering • • • Major improvements in last year Catch rates ~90% False positive problem persists IP-based reputation Domain-based reputation * Feedback to help senders improve * * Requires sender authentication Sender Practices • • • • • Port 25 blocking Rate limiting Publish SPF record Digital signatures Proof of work Sender ID Framework An Emerging Standard A merger and refinement of proposals SPF (Sender Policy Framework) Microsoft Caller ID for Email IETF MARID working group feedback Industry collaboration including AOL, Bell Canada, Cisco, Comcast, IBM, Interland, Port25, Sendmail, Symantec, Tumbleweed, VeriSign…. Email Service Providers Coalition, Opengroup Messaging Forum, TRUSTe…. A first step and on a fast track…. Design Goals & Tradeoffs Protection Senders can take immediate steps to protect their brand & domain names Accountability Senders can be held accountable for mail they send Ease of adoption No software changes required for most senders Openly published specification that can be broadly adopted Scalability From small businesses to largest ISPs Non-Goals Silver bullet for spam & phishing Solve all email authentication problems Zero cost What Is Sender ID? A framework of technical specifications Sender ID Framework All Mail Senders MTA Vendors & Receiving Networks SPF Record MAIL FROM Check Purported Responsible Address (PRA) Check Submitter SMTP Optimization http://www.microsoft.com/senderid How Does Sender ID Work? Message transits one or more email servers en route to receiver One time: Publish SDIF record in DNS using SPF text format No other changes required Email sent as normal Determine which domain to check; PRA or MAIL FROM Look up sender’s SPF record in DNS Compare connecting IP address to authorized list from SPF record Match positive filter input No match negative filter input PRA and Mail From Checks PRA MAIL FROM Derived from RFC2822 message headers RFC2821 “bounce” address Resent-Sender, Resent-From, Sender, From Identity most often seen by users Helps reduce phishing Easier adoption for email forwarders Helps reduce “joe jobs” Checking can begin before message data is received Headers can be spoofed Headers must be received and parsed Headers seen by users are not validated More difficult for forwarders Interpreting the Results Range of actions based on check results: Accept message Reject message Use result as input into spam filters Indicate result to end users “Pass” does not mean “good mail” Sender could be a spammer with a domain Increasing adoption will enable stricter tests Domains with no Sender ID records will have their mail subject to increased scrutiny Increase weighting in filtering algorithms Sample SPF Records example.com TXT “v=spf1 -all” This domain never sends mail example.com TXT “v=spf1 mx -all” Inbound email servers also send outbound mail example.com TXT “v=spf1 ip4:192.0.2.0/24 –all” Specify an IP range example.com TXT “v=spf1 mx include:myesp.com –all” Outsourced email service example.com TXT “spf2.0/pra ip4:192.0.3.0/24 –all” Different configuration for PRA checking SPF Record Wizard Implementation Considerations Senders Administrative (immediate): Publish DNS records identifying authorized outbound email servers On-going maintenance of same Coordination of e-mail marketing initiatives No hard costs or technical overhead Receivers Software (near term): Upgrade inbound email gateway servers to perform Sender ID checks Software (optional - medium-long term): Upgrade client software to display results of Sender ID check “Intermediaries” (forwarders, lists, etc.) Software (near term): Upgrade outbound email servers to identify their own domains in messages Sender ID Supports Outcome Over 1 million domain have published their records 19.5% of email volume, after IP blocking and BM Over 16% of the domains sending to Hotmail Top sending domains records are cached Internal tests and “training” since Nov 2004 Heuristics integrated into SmartScreen & User feedback loop Live worldwide implementation since Jan 2005 Transparent to the user ~14.5% of mail rated “good” passes Sender ID check* ~3.9% of mail rated “spam” passes Sender ID check* ~15.7% of mail fails Sender ID check No match, no PRA, nonexistent domain * Source: Participants in Hotmail Feedback Loop, as of 4/25/2005 Hotmail Sender ID Verification Benefits of Sender ID Protect senders’ brand and domain names from spoofing and phishing Rapid adoption Senders can publish SPF records today Most senders require no software upgrades A foundation for the reliable use of domain names in accreditation, reputation systems & safe lists Receivers validate the origin of mail Input into more aggressive spam filtering with reduced false positives The first step industry will need to take together – there will be more to come including signing solutions Proof, Protection & Prevention Today 3 years + Microsoft Smart Screen TM – Hotmail, Exchange & Outlook Accreditation / Reputation – Safelist / Bonded Sender Industry Accountability - Port 25 / Open proxy / Zombie Detection….. Sender ID Framework Phishing URL detection / mail / browsers Computational Cycles / Challenges Signing Solutions Take Aways No silver bullet Blended evolving threats Nailing one problem may help or expose others “Takes a village” Cooperation & collaboration Multiple players in the ecosystem Will take time New freeways do not happen overnight Summary All e-mail senders and domains should publish their SPF records today Microsoft will initiate checking by year-end Network administrators should contact ISP/MTA Vendors for Sender ID Framework integration Resources http://www.microsoft.com/senderid Specs, resources, record wizard http://www.microsoft.com/spam © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. Appendix Sender ID Scenarios Direct Delivery List Server Mobile Carrier Guest Email Service Mail Delivery Scenarios What Must Senders Do? Direct Delivery Sender Agent List Server Mobile Carrier Guest Email Service Recip. Agent alice@example.com Forwarder Sender Agent List Server Recip. Agent Forwarder bob@woodgrove.com Direct Delivery alice@example.com bob@woodgrove.com Publish outbound server records in DNS using the SPF format Optional: Transmit SUBMITTER parameter on MAIL command Direct Delivery S: C: S: S: S: S: S: C: S: C: S: C: S: C: C: C: S: C: S: 220 woodgrove.com ESMTP server ready EHLO example.com 250-woodgrove.com 250-DSN SUBMITTER extension 250-AUTH advertised in EHLO response 250-SUBMITTER 250 SIZE MAIL FROM:<alice@example.com> 250 <alice@example.com> sender ok RCPT TO:<bob@woodgrove.com> 250 <bob@woodgrove.com> recipient ok DATA 354 okay, send message RFC2821 MAIL FROM = From: alice@example.com RFC2822 From (message body goes here) . 250 message accepted QUIT 221 goodbye Mailing List List Server owner-list1@listexample.com alice@example.com 1. 2. bob@woodgrove.com Publish outbound server records in DNS Ensure “list-owner” style address is present in the message E.g. Sender: owner-list1@listexample.com Vast majority of mailing list servers do this today 3. Optional: Transmit SUBMITTER parameter on MAIL command Mailing List S: C: S: S: S: C: S: C: S: C: S: C: C: C: C: C: C: S: C: S: 220 woodgrove.com ESMTP server ready EHLO listexample.com 250-woodgrove.com SUBMITTER extension 250-SUBMITTER advertised in EHLO response 250 SIZE MAIL FROM:<owner-list1@listexample.com> SUBMITTER=owner-list1@listexample.com SUBMITTER 250 <owner-list1@listexample.com> sender ok parameter added to RCPT TO:<bob@woodgrove.com> MAIL command 250 <bob@woodgrove.com> recipient ok DATA 354 okay, send message Received By: ... From: alice@example.com Sender header Sender: owner-list1@listexample.com added to message To: list1@listexample.com (message body goes here) . 250 message accepted QUIT 221 goodbye Mail Forwarder Mail Forwarder bob@alumni.almamater.edu alice@example.com 1. 2. bob@woodgrove.com Publish outbound server records in DNS Ensure forwarding address is present in the message E.g. Resent-From: bob@alumni.almamater.edu 3. Optional: Transmit SUBMITTER parameter on MAIL command indicating forwarding address Mail Forwarder S: C: S: S: S: S: S: C: S: C: S: C: S: C: C: C: C: S: C: S: 220 woodgrove.com ESMTP server ready EHLO alumni.almamater.edu 250-woodgrove.com 250-DSN SUBMITTER extension advertised 250-AUTH 250-SUBMITTER in EHLO response 250 SIZE MAIL FROM:<alice@example.com> SUBMITTER=bob@alumni.almamater.edu SUBMITTER parameter 250 <alice@example.com> sender ok added to MAIL RCPT TO:<bob@woodgrove.com> command 250 <bob@woodgrove.com> recipient ok DATA 354 okay, send message Resent-From: bob@alumni.almamater.edu Resent-From header Received By: ... added to message (message body goes here) . 250 message accepted QUIT 221 goodbye Message is sent Transits through Sender’s email server Transits through Recipients email server Email user with enabled client composes and sends message Computational puzzle is solved taking up to 20 seconds Solution is attached to the message Receiver confirms the puzzle solved correctly If yes, the mail is delivered If not, the message is flagged