ietf-mxcomp
[Top] [All Lists]

Caller ID and phishing

2004-04-13 11:59:59

There have been a couple of questions about phishing and how Caller ID
attempts to deal with it, so I'd like to collect them here under a new
topic and try to address them below.  

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of wayne
Sent: Sunday, April 11, 2004 6:35 AM
To: IETF MXCOMP
Subject: Re: Microsoft submitting Caller ID as draft RFC


In 
<9156B81DAA29204989AD43E88688FAAB01373AD8(_at_)df-lassie(_dot_)dogfood> 
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:

2.  Better protection against "phishing":  With SPF, a 
spammer could 
register their own domain name and publish an outbound IP 
address, yet 
still spoof the 2822 From.  With Caller ID, these message 
headers get 
checked.  Furthermore, Caller ID provides an extra measure of 
protection for senders who only transmit mail directly to 
recipients 
and never to mailing lists.

I'm probably just not understanding the C-ID spec, but how do 
you distinguish between the mailing-list case and the 
email-forwarder case?  If I understand the spec correctly, 
the "directOnly" flag would cause both to fail.

-----Original Message-----
From: Matthew Elvey [mailto:matthew(_at_)elvey(_dot_)com] 
Sent: Monday, April 12, 2004 11:16 PM
To: Harry Katz; IETF MXCOMP
Subject: What to check? (was Re: Caller ID and ease of adoption


On Mon, 12 Apr 2004 13:28:34 -0700, "Harry Katz"
<hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> said:

wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):

... RFC2821 checks will likely not
effect very many mailing lists. 

It is not so clear to me whether large numbers of mailing lists 
would not changing in order to comply with C-ID.  If I understand 
the C-ID spec correctly, the "responsible domain"
is found by checking the following headers, in this order: 
Resent-Sender:, Resent-From:, Sender:, and From:.

C-ID has no advantage over 2821-only checking if this is the 
case, because phishers will quickly adapt and send spam like:
Resent-Sender: foo(_at_)spammerWithValidC-ID(_dot_)dom
From: service(_at_)paypal(_dot_)com
and the first header won't be visible in most clients, right?

Harry, you said we need to check against what the user will see.
Clients generally don't display "Resent-Sender:", yet C-ID allows it?
Doesn't make sense to me.

In fact, I'm not aware of a single client that displays Resent- today.
As I've noted elsewhere, we believe that this value will eventually need
to be shown to end users if that's the domain that's validated.  Whether
this is done by the MUA, or by the MTA doing something fancy with the
display name on the From line, or some other mechanism is an
implementation detail I won't delve into here.  

The reason we have the Resent- headers to our list (even though they're
not visible today) is for ease of adoption.  We think it'll be easier
for forwarders to just insert this header than to adopt SRS or VERP and
then start handling the bounces coming back.  I know ... I'm repeating
myself.  

You're correct that a spammer could just as easily insert a forged
Resent- header as forge an RFC2821 MAIL FROM.  I don't know that a
complete mitigation for this exists in any scheme.  Which is one reason
why displaying the verified identiy to the user is important.  

We added the directOnly element into our schema to help in the most
serious phishing cases.  

The directOnly attribute lets sending domains to declare that they don't
*knowingly* send mail via mailing lists.  Obviously the sending side can
have no certain knowledge about whether or not mail to any given address
is *actually* sent through a mailing list or forwarding service.  So
directOnly is, if you will, a statement of intent by the sending domain.
The main purpose is to protect against spammers inserting a Resent-
header that spoofs such a domain.  

On the receiving side, then, an additional check is prescribed whenever
there's a difference between the purported responsible domain of the
message and the RFC2822 From domain.  If the directOnly attribute is
found, further action can be taken.  We have not specified what action
should be taken other than to suggest "significantly perjorative
penalties."  We think this should be a local implementation decision
because a certain amount of judgement needs to be exercised here.  For
example, others on this list have noted that users typically know what
lists they're subscribed to and what forwarding addresses they've set
up.  If a user has placed those forwarded email addresses on a safe list
then the message may be deemed legitimate even though there's a
discrepancy between the purported responsible domain and the RFC2822
From domain.


<Prev in Thread] Current Thread [Next in Thread>