IP Addresses in Email Clients - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

IP Addresses in Email Clients

Description:

Received: from faked.msn.com ([80.81.82.83) by hotmail.com ... Multiple domains with sharing (MSN front end servers and Hotmail backend) ... – PowerPoint PPT presentation

Number of Views:116
Avg rating:3.0/5.0
Slides: 23
Provided by: josh9
Category:

less

Transcript and Presenter's Notes

Title: IP Addresses in Email Clients


1
IP Addresses in Email Clients
  • Joshua Goodman Microsoft Research

2
Overview
  • Background IP addresses Received Headers
  • IP addresses are very useful for stopping spam
  • Blacklists (RBLs, Habeas)
  • Safelists (Bonded Sender, Habeas)
  • Anti-Spoofing (e.g. SenderID)
  • Trivial or Easy for a server to find the IP
    address
  • Impossible for an email client to consistently
    find the IP address
  • Surprising seems like all the information you
    need is there in the headers
  • Algorithm that knows when it knows
  • Solutions
  • Consider new standards for propagating IP address
    from server to client
  • Consider solutions that dont use IP address

3
BackgroundReceived Headers
  • As each mail server receives mail from the
    previous one, it prepends a received from line
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com

spammer.com
4
BackgroundReceived Headers
  • Spammer can start with fake lines
  • Spammer can use a fake HELO
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from hotmail.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    hotmail.com

spammer.com
5
Using IP Addresses
  • Find last external IP address
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from hotmail.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    hotmail.com
  • Not worried about mailing lists, or forwarders,
    or other legitimate reasons to add received lines
  • Theres no way in general to reliably detect
    these

6
Why are IP Addresses so Important
  • IP address gives you the identity of the sender
    in a way that cannot be faked
  • Useful for Blacklists
  • Useful for Safelists
  • Useful for AntiSpoofing (SenderID)

7
Blacklists
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com
  • If 90.91.92.93 is on a list of known spammers,
    reject all mail
  • Habeas Sender Warranted program keeps a list of
    known violators. If 90.91.92.93 on list of
    violators, reject mail, or ignore Habeas Haiku

8
Safe Lists
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from microsoft.com (90.91.92.93) by
    a.xampl.com
  • If 90.91.92.93 is on a list of known good
    senders, accept all mail
  • Ironports Bonded Sender program
  • Habeas

9
Anti-SpoofingSenderID
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from relay.msn.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com
  • From user_at_msn.com
  • SenderID is for anti-spoofing (preventing fake
    From lines)
  • RMX, CallerID, SPF all very similar
  • Use SenderID protocol to find list of IP
    addresses that msn.com sends from
  • If 90.91.92.93 is not on this list, from is fake,
    so reject mail or warn user

10
Easy for Servers to find IP Address
  • Know that they are the edge server
  • Know list of inbound addresses (1.2.3.4)
  • Know number of steps to edge
  • None of these work for email clients
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com

user_at_xampl.com
a.xampl.com 1.2.3.4
spammer.com
11
Heuristics client might useFind first external
to their domain
  • Works in this example
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com

user_at_xampl.com
spammer.com
12
Heuristics client might useFind first external
to their domain
  • Fails in this example
  • Can try forward DNS lookups to verify HELOs but
    internal mail servers sometimes not entered in
    DNS
  • Received from x.msn.com (1.2.3.10) by
    mail.msn.com
  • Received from a.msn.com (1.2.3.4) by x.msn.com
  • Received from lie.msn.com (90.91.92.93) by
    a.msn.com
  • Received from faked.msn.com (80.81.82.83) by
    lie.msn.com

user_at_msn.com
spammer.com
13
Heuristics client might useFind first external
to their domain
  • Fails in this example
  • Received from x.hotmail.com (1.2.3.10) by
    mail.hotmail.com
  • Received from a.msn.com (1.2.3.4) by
    x.hotmail.com
  • Received from lie.msn.com (90.91.92.93) by
    a.msn.com
  • Received from faked.msn.com (80.81.82.83) by
    lie.msn.com

user_at_msn.com
spammer.com
14
Heuristics client might useFind first MX Record
  • MX record contains list of IP addresses that
    mails comes into
  • Received from x.msn.com (1.2.3.10) by
    mail.msn.com
  • Received from a.msn.com (1.2.3.4) by x.msn.com
  • Received from spammer.com (90.91.92.93) by
    a.msn.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com

user_at_msn.com
spammer.com
15
Heuristics client might useFind first MX Record
  • MSN.com uses a load balancing router
  • Received from x.msn.com (1.2.3.10) by
    mail.msn.com
  • Received from a.msn.com (1.2.3.4) by x.msn.com
  • Received from q.msn.com (90.91.92.93) by
    a.msn.com
  • Received from edge.msn.com (1.2.3.5) by
    q.msn.com
  • Received from faked.amazon.com (80.81.82.83) by
    edge.msn.com

a.msn.com 1.2.3.4
Edge.msn.com Load balancing router MX record
here 1.2.3.5
b.msn.com
user_at_msn.com
spammer.com 90.91.92.93
c.msn.com
16
Why its hard
  • Need to think about complex configurations
  • Multiple domains hosted on one system (XBOX and
    Microsoft)
  • Multiple domains with sharing (MSN front end
    servers and Hotmail backend)
  • Load balancing routers
  • Mail takes different paths depending on the
    sender or the load
  • Need to think about common (mis)configurations
  • Incorrect HELO information
  • No DNS info for internal-only servers
  • Need to think about active spammer attacks
  • Algorithm may work today, but can spammers beat
    it?

17
The Best I can do Today
  • Have an algorithm that knows when it knows, knows
    when it doesnt know
  • Idea sometimes we can be sure were still
    internal to organization
  • IP address is an internal only address (private
    internet, e.g. 192.168.x.x)
  • HELO matches users domain and forward DNS lookup
    of HELO matches IP address
  • Find an IP that matches MX record, know that next
    one is external to org.
  • Sometimes we just dont know

18
Recommendations
  • Consider alternatives to IP address information
  • Public key signing protocols instead of IP
    address protocols (SenderID)
  • But Public key signing has its own problems
  • Consider doing all work on servers
  • But often need client cooperation, e.g. to notify
    when SenderID mismatch
  • Consider new standards that communicate from
    servers to clients

19
New Standards
  • Somewhat difficult need some way for server to
    communicate to client that client can trust, but
    cant just add a new header
  • Spammers can add new headers
  • Idea 1 modify top Received line with a comment
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com

20
New Standards
  • Somewhat difficult need some way for server to
    communicate to client that client can trust, but
    cant just add a new header
  • Spammers can add new headers
  • Idea 1 modify top Received line with a comment
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com (LastExternalIP90.91.92.93)
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com

21
New StandardsIdea 2 (Bob Atkinson)
  • Put list of external IP addresses in a special
    DNS name record, e.g.
  • external.xampl.com name record contains 1.2.3.4
  • Received from x.xampl.com (1.2.3.10) by
    mail.xampl.com
  • Received from a.xampl.com (1.2.3.4) by
    x.xampl.com
  • Received from spammer.com (90.91.92.93) by
    a.xampl.com
  • Received from faked.msn.com (80.81.82.83) by
    spammer.com

22
Conclusion
  • IP addresses are a critical part of many
    standards today
  • Anti-Spoofing (SenderID)
  • IP safelists (BondedSender, Habeas)
  • IP blacklists (RBL, Habeas violators)
  • But email clients cannot reliably detect them
  • Abandon IP addresses in email clients? (no!)
  • Abandon IP addresses? (no!)
  • Extend standards yes
Write a Comment
User Comments (0)
About PowerShow.com