1. 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

2. Evolving SPAM Attacks VirusWorm Scams Spyware Trojans Identity Theft Identity Theft Data Leakage/Theft Data Leakage/Theft DDoS Extortion DDoS Extortion Frauds Frauds Software Piracy Software Piracy Illegal Downloads Illegal Downloads

3. Education & Enablement Industry Collaboration & Partnerships Govt Partnerships Strong Laws Strong Laws & Enforcement & Enforcement e-mail user Prevention Agents Attack detection Sender reputation Outbound filtering Proof: Identity & Evidence “Sender ID” Computational Cycles Certificates Sender Safelists Protection Filters SmartScreen At gateway, server & desktop Update Service Microsoft Anti-Spam Strategy

4. Technology Strategy Build an integrated, distributed system of inter- connected 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

5. Content Filtering Major improvements in last year Major improvements in last year Catch rates ~90% Catch rates ~90% False positive problem persists False positive problem persists Why Authentication? Sender Reputation IP-based reputation IP-based reputation Domain-based reputation * Domain-based reputation * Feedback to help senders improve * Feedback to help senders improve * Sender Practices Port 25 blocking Port 25 blocking Rate limiting Rate limiting Publish SPF record Publish SPF record Digital signatures Digital signatures Proof of work Proof of work * Requires sender authentication

6. 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….

7. 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

8. What Is Sender ID? A framework of technical specifications Sender ID Framework All Mail Senders MTA Vendors & Receiving ReceivingNetworks SPF Record Purported Responsible Address (PRA) Check Submitter SMTP Optimization MAIL FROM Check http://www.microsoft.com/senderid

9. One time: Publish SDIF record in DNS using SPF text format One time: Publish SDIF record in DNS using SPF text format No other changes required No other changes required Email sent as normal Email sent as normal Determine which domain to check; PRA or MAIL FROM Determine which domain to check; PRA or MAIL FROM Look up sender’s SPF record in DNS Look up sender’s SPF record in DNS Compare connecting IP address to authorized list from SPF record Compare connecting IP address to authorized list from SPF record Match  positive filter input Match  positive filter input No match  negative filter input No match  negative filter input Message transits one or more email servers en route to receiver Message transits one or more email servers en route to receiver How Does Sender ID Work?

10. PRA and Mail From Checks PRA MAIL FROM Derived from RFC2822 message headers Resent-Sender, Resent-From, Sender, From Identity most often seen by users RFC2821 “bounce” address 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

11. 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

12. 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

13. SPF Record Wizard

14. 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

15. Sender ID Supports

16. 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

17. Hotmail Sender ID Verification

18. 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

19. Sender ID Framework Sender ID Framework Proof, Protection & Prevention Signing Solutions Computational Cycles / Challenges Today 3 years + Microsoft Smart Screen TM – Hotmail, Exchange & Outlook Accreditation / Reputation – Safelist / Bonded Sender Industry Accountability - Port 25 / Open proxy / Zombie Detection….. Phishing URL detection / mail / browsers

20. 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

21. 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 Resourceshttp://www.microsoft.com/senderid Specs, resources, record wizard http://www.microsoft.com/spam

22. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

23. Appendix Sender ID Scenarios Direct Delivery List Server Mobile Carrier Guest Email Service

24. Mail Delivery Scenarios What Must Senders Do? alice@example.com bob@woodgrove.com Direct Delivery List Server Mobile Carrier Guest Email Service Forwarder List Server Forwarder SenderAgentRecip.Agent SenderAgent Recip.Agent

25. Direct Delivery Publish outbound server records in DNS using the SPF format Optional: Transmit SUBMITTER parameter on MAIL command alice@example.com bob@woodgrove.com

26. S: 220 woodgrove.com ESMTP server ready C: EHLO example.com S: 250-woodgrove.com S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: From: alice@example.com C: (message body goes here) C:. S: 250 message accepted C: QUIT S: 221 goodbye Direct Delivery SUBMITTER extension advertised in EHLO response RFC2821 MAIL FROM = RFC2822 From

27. Mailing List  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  Optional: Transmit SUBMITTER parameter on MAIL command bob@woodgrove.com alice@example.com owner-list1@listexample.com ListServer

28. Mailing List S: 220 woodgrove.com ESMTP server ready C: EHLO listexample.com S: 250-woodgrove.com S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=owner-list1@listexample.com S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Received By:... C: From: alice@example.com C: Sender: owner-list1@listexample.com C: To: list1@listexample.com C: (message body goes here) C:. S: 250 message accepted C: QUIT S: 221 goodbye SUBMITTER extension advertised in EHLO response SUBMITTER parameter added to MAIL command Sender header added to message

29. Mail Forwarder 1.Publish outbound server records in DNS 2.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 bob@woodgrove.com alice@example.com bob@alumni.almamater.edu MailForwarder

30. S: 220 woodgrove.com ESMTP server ready C: EHLO alumni.almamater.edu S: 250-woodgrove.com S: 250-DSN S: 250-AUTH S: 250-SUBMITTER S: 250 SIZE C: MAIL FROM: SUBMITTER=bob@alumni.almamater.edu S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Resent-From: bob@alumni.almamater.edu C: Received By:... C: (message body goes here) C:. S: 250 message accepted C: QUIT S: 221 goodbye Mail Forwarder SUBMITTER extension advertised in EHLO response SUBMITTER parameter added to MAIL command Resent-From header added to message

31. 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 Message is sent Transits through Sender’s email server Transits through Recipients email server

32. Sample fill color PowerPoint Guidelines Font, size, and color for text have been formatted for you in the Slide Master Use the color palette shown below See next slide for additional guidelines