Subject: RE: How would SPF or Sender Id caught this one?

From: "Daryl Odnert" <[email-masked]>
Date: Fri, 30 Jul 2004 17:10:38 -0700

Well, I think the idea is that SPF and/or Sender ID significantly raise the
bar in terms of how difficult it is to spoof sender's identity.  Today, just
about anyone can send a spoofed message by changing some settings in their
email client application.  If tomorrow, it becomes necessary to spoof a TCP
session to do the same thing, I think that's significant progress.
 
If you really want to trust that the contents of a email message was
authored by the person who claims to be the author, you need to use a
digital signature based authentication mechanism (e.g. S/MIME).  Many
financial institutions and online retailers are considering that option
together with other authentication and anti-spam/anti-phishing strategies.
 
Daryl Odnert
Tumbleweed Communications
Redwood City, California
 
-----Original Message-----
From: Bill McInnis [mailto:[email-masked]]
Sent: Friday, July 30, 2004 4:50 PM
To: 'Daryl Odnert'; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

Thanks for the reply,
 
I read that and that was my understanding as well.  So does this make it a
solution that works fine for mailing lists, but not for financial
institutions, online retailers, and pretty much anyone transacting dollars
online?  
 
The example was not made up.  We are seeing that scenario more and more
where I am sitting.    

Bill McInnis
MessageLevel.com
 
 -----Original Message-----
From: Daryl Odnert [mailto:[email-masked]] 
Sent: Friday, July 30, 2004 7:44 PM
To: Bill Mcinnis; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

> How would SPF or Sender ID have managed to catch that attack? 

I think the answer is: they cannot.  If the phisher successfully 
spoofed the an SMTP over TCP session, there is nothing that SPF 
or Sender ID can do about that. 

You might want to look at section 6.2 of draft-ietf-marid-core-02.txt. 

Regards, 
Daryl Odnert 
Tumbleweed Communications 
Redwood City, California

---

From: "Bill McInnis" <[email-masked]>
Date: Fri, 30 Jul 2004 20:58:32 -0400

What keeps an spoofer from sending the non-S/MIME message and it still
reaching the end user?  
 
Bill McInnis
MessageLevel.com
 
-----Original Message-----
From: Daryl Odnert [mailto:[email-masked]] 
Sent: Friday, July 30, 2004 8:11 PM
To: Bill Mcinnis; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

Well, I think the idea is that SPF and/or Sender ID significantly raise
the bar in terms of how difficult it is to spoof sender's identity.
Today, just about anyone can send a spoofed message by changing some
settings in their email client application.  If tomorrow, it becomes
necessary to spoof a TCP session to do the same thing, I think that's
significant progress.
 
together with other authentication and anti-spam/anti-phishing
strategies.
 
Daryl Odnert
 
-----Original Message-----
From: Bill McInnis [mailto:[email-masked]]
Sent: Friday, July 30, 2004 4:50 PM
To: 'Daryl Odnert'; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

Thanks for the reply,
 
I read that and that was my understanding as well.  So does this make it
a solution that works fine for mailing lists, but not for financial
institutions, online retailers, and pretty much anyone transacting
dollars online?  

Bill McInnis
MessageLevel.com
 
 -----Original Message-----
From: Daryl Odnert [mailto:[email-masked]] 
Sent: Friday, July 30, 2004 7:44 PM
To: Bill Mcinnis; IETF MARID WG
Subject: RE: How would SPF or Sender Id caught this one?

Regards, 
Daryl Odnert

---

From: "Larry Seltzer" <[email-masked]>
Date: Fri, 30 Jul 2004 21:27:36 -0400

authored by the person who claims to be the author, you need to use a
digital signature based authentication mechanism (e.g. S/MIME). 
 
S/MIME isn't necessary to address this scenario, which does demonstrate
the basic flaw of any IP-based solution. Domain Keys would have stopped
it though. 

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 30 Jul 2004 18:57:55 -0700 (PDT)

> the basic flaw of any IP-based solution. Domain Keys would have stopped

At a cost of loosing legitimate email if you rely on and if intermediate
systems (mailservers, forwarders, etc) do not support DK. On the other 
hand, s/mime is designed to be end-end system that works no matter what 
intermediate system does with email. 

If we're to build mail server signature insertion system (which is not a 
bad idea since neither s/mime nor pgp are used widely by end-users, so
so we must "help" them out by having mail servers sign email instead and 
verify it), then such system should should be similar to real email 
signatures and be end-end capable, meaning you don't have to be the next
hop in email transmission to be able to verify the signature safely.

One such proposal paper is available at
http://www.elan.net/~william/asrg/mta_signatures.htm

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "John Glube" <[email-masked]>
Date: Sat, 31 Jul 2004 01:41:26 -0400

I happen to have received the US Bank “phish” email.

Since I live in Toronto, Canada and don’t do business with

US Bank, I recognized it for what it was.

Because I felt the message was a problem, I made a copy of

the email header, along with a report. 

So everyone can see what we are talking about, I am

forwarding a copy of the message header.

For privacy reasons, I have made the following changes to

the header:

* I have changed the domain information as found in the

header information concerning existing domains within

Canada or the United States.

I am now showing the spammed email address as

[email-masked]

The various addresses, domains and the final address have

been altered, with the ultimate recipient address being

shown as [email-masked]. 

I have left the return path as originally shown, being

Return-Path: <[email-masked]>

* I have altered each of the related IP addresses slightly,

except that of the one which is shown below as

([220.168.12.3]).

(A “who is” inquiry through DNS & stuff shows this IP

address is assigned to Chinanet, being the Hunan province

network with offices in Beijing.)

* All other information in the header has not been changed.

According to the header, it seems the phisher made a direct

connection from the IP address assigned to Chinanet to the

MX server of the spammed email address. 

Of course, if this was a legitimate bank message, it would

not have been sent in this fashion. Also, it was sent with

low importance.

Given the header information, I am curious to know how this

particular message header would have been treated, based on

the presumption the spammed domain has published an SPF

record (compliant with Sender –ID) and the receiving MX

server associated with the spammed email address is set up

to check for either SPF or Sender ID records? 

If anyone wishes an original of the header for personal

analysis, please email me and I will send it on.

John Glube

Toronto, Canada

The FTC Calls For Sender Authentication

http://www.learnsteps4profit.com/dne.html

--------------- Header ---------------

Return-Path: <[email-masked]>

Received: from toip1.bigisp.net ([209.220.175.84])

          by tomts38-srv.bigsip.net

          (InterMail vM.5.01.06.10 201-253-122-130-110-20040306)
with ESMTP

          id
<[email-masked]>

          for <[email-masked]>; Mon, 26 Jul 2004 06:30:03
-0400

Received: from erato.host2u.net (216.70.64.161)

  by toip1.bigisp.net with ESMTP; 26 Jul 2004 06:30:02 -0400

Received: from 66.79.231.191 ([220.168.12.3])

            by erato.host2u.net (8.11.6/8.11.6) with SMTP id
i6QATuo17389

            for <[email-masked]>; Mon, 26 Jul 2004 05:29:57
-0500

Message-Id: <[email-masked]>

X-Mozilla-Status: 0001

X-Mozilla-Status2: 00000000

FCC: mailbox://[email-masked]/Sent

X-Identity-Key: id1

Date: Mon, 26 Jul 2004 14:25:49 +0300

From: U S Bank <[email-masked]>

X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0;
uuencode=0

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

X-Accept-Language: en-us, en

MIME-Version: 1.0

To: [email-masked]

Subject: Important notification

Content-Type: multipart/related;

 boundary="------------010705020107040506040001"

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004