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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 31 Jul 2004 07:01:46 -0700

What do you mean by 'appropriate' ?

The address does not seem to be connected at the moment. It has no reverse
DNS, I can't find an SPF record.

I think it is important to accept that the Sender-Id design is intended to
be low barrier to deployment for email senders, it is not meant to be
highest possible security. Even if it only eliminates bulk spam it helps to
drain the pond.

The phishing gangs have significant technical capabilities but there is
still a value to raising the bar for new entrants. I would rather be chasing
ten gangs than a thousand.

We may well have to use more sophisticated authentication technology to
defeat the phishing gangs. But that will take some time. We cannot afford to
do what we keep doing in the security area and allow scope creep to cause us
to never deploy the good while we attempt the perfect.

> -----Original Message-----

> Last weekend a phishing attack took place against US Bank.  
> The phisher
> spoofed and connected with the appropriate IP for US Bank,
> 170.135.72.63.  How would SPF or Sender ID have managed to catch that
> attack?
> 
> Thanks,
> 
> Bill McInnis
> MessageLevel.com

---

From: "John Glube" <[email-masked]>
Date: Sat, 31 Jul 2004 12:13:48 -0400

I am having some difficulty with the analysis of this
situation.

Let me explain. 

The header which I provided earlier to the list indicates
to me a malformed "SMTP mail from address," with the SMTP
mail from address being null. 

(As an aside, the server logs found on the messagelevel.com
web site in the review of this message confirms how I read
the message header.)

What does this mean? It means the sender is directly
accessing the receiving server through his or her computer. 

I am writing this in non technical terms for a reason.

The much aligned US federal law regulating commercial email
tells us:

"Whoever, in or affecting interstate or foreign commerce,
knowingly--

(3) materially falsifies header information in multiple
commercial electronic mail messages and intentionally
initiates the transmission of such messages"

is committing a federal crime.

(see section 4 of the CAN SPAM Act of 2003. You can find a
copy of the Act at
http://www.learnsteps4profit.com/antispamus.html)

In this same section, materially is defined as follows:

"...header information or registration information is
materially falsified if it is altered or concealed in a
manner that would impair the ability of a recipient of the
message, an Internet access service processing the message
on behalf of a recipient, a person alleging a violation of
this section, or a law enforcement agency to identify,
locate, or respond to a person who initiated the electronic
mail message or to investigate the alleged violation."

It is a material falsification to spew a message into the
system with "malformed" information "that would impair"
one's ability to "identify, locate, or respond to the
person who initiated the electronic mail message."

So what you may ask? Any protocol for sender authentication
has to instruct the receiving mail server to check for
malformed "mail envelope" information and if found, reject
the message at the transport stage.

Why? This serves the basic purpose of helping to confound
the spammer's ability to spoof messages, which is the FTC's
basic premise for supporting sender authentication.

(See page 12 of the FTC's report on the feasibility of a
National Do Not Email Registry.
http://www.learnsteps4profit.com/dne.html)

Now the question becomes does the SPF or Sender-ID protocol
help to achieve this goal?

Using the original SPF algorithm, the receiving MTA first
checks the SMTP mail from address for a domain name.

If there is none, the instruction was to retrieve the
domain from the helo line.

Upon retrieving the domain from the helo line, the
receiving MTA would then check for the domain's SPF record. 

Since usbank.com has not published a sender policy
framework record, the answer would be none and therefore
under the original protocol the receiving MTA was to allow
the message to pass.

I am relying on the following draft: -
http://spf.pobox.com/spf-draft-200406.txt

This analysis exposes a potential error in the original SPF
algorithm. Let me explain.

The instruction should have been:

* First check the SMTP mail from address for a domain.

* If there is no domain to check, this means the message
mail envelope is malformed. The receiving MTA must reject
the message.

The only question I have is, "when the receiving MTA
rejects, does it send a note to the helo address (being the
return path) explaining the reason for the rejection?"

Under the SPF marid protocol document, which ties in with
the Sender-ID marid core document, I suggest this issue is
resolved. 

Since there is no domain in the SMTP mail from address, the
mail envelope is not formed properly. The instruction is to
reject the message. 

(I presume this is the intention of section 3.3 titled
initial processing as found in
http://spf.pobox.com/draft-ietf-marid-protocol-00.txt.)

If this is not the case, then I suggest the authors of the
SPF marid protocol document can easily change the initial
processing instruction to rectify this problem.

Why? Sending direct from the server, using port 25 to
bypass accessing an SMTP mail server and connecting
directly to the receiving mail server is a classic spamming
technique used to hide ones identity.

I suggest sender authentication should and can easily
defeat this technique which is used time and again to spew
messages into the system and hide identity.

Of course, I acknowledge there could be a flaw in any of my
premises or understanding of the respective protocols. 

If there is, please correct me.

John Glube 
Toronto, Canada  

The FTC Calls For Sender Authentication 
http://www.learnsteps4profit.com/dne.html

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