----- Original Message -----
From: "Alex van den Bogaerdt" <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
I guess he was thinking that under normal MAIL operations, you will have
headers in the message. Go figure.
That may be because his MTA adds a "From: " header ?
Right. It did and the MTA added it based on the 2821.MFROM address.
Otherwise he would never be able to reply.
But PRA's logic is so messed up, it failed to consider all the
possibilities.
Imagine this:
Email domain "spammer.com" is a spammer. A bad guy!
IP Address: 1.2.3.4 (spammer machine)
and he has a SPF1 and SPF2 record for spammer.com
V=SPF1 IP4:1.2.3.4 -all
SPF2.0/PRA IP4:1.2.3.4 -all
Lets supports go is going to send mail to bill(_at_)hotmail(_dot_)com so he
connects
to the hotmail.com host and starts a transaction:
SMTP transaction:
HELO mail.spammer.com
MAIL FROM: <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
RCPT TO: <bill(_at_)hotmail(_dot_)com>
DATA
Date: .....
From: spammer(_at_)spammer(_dot_)com
(2 meg MIME attachment)
.
QUIT
The SMTP receiver will receive the DATA block and create a temporary storage
that will include the trace information:
Return-Path: <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
Received: from mail.spammer.com
(mail.spammer.com [1.2.3.4])
by mx4.hotmail.com.com .....
Date: ......
From: spammer(_at_)spammer(_dot_)com
According to MS, they will not check the MAIL FROM but will instead check
the PRA in the temporary 2822 data block..
In this case, we get:
PRA=spammer(_at_)spammer(_dot_)com
IP = 1.2.3.4
and the SPF1 or SPF2 lookup passes the test.
But it is clear this is a spoofed transaction. The spammer used your
address for the return path and it was never checked.
The MS solution is that the SMTP received automatically added a high
priority header, like Sender: so that the 2822 header now looks like this:
Return-Path: <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
Received: from mail.spammer.com
(mail.spammer.com [1.2.3.4])
by mx4.hotmail.com.com .....
Sender: <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
Date: ......
From: spammer(_at_)spammer(_dot_)com
Now we have:
PRA=alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net
IP = 1.2.3.4
which according to what we see today in DNS, is a SPF NONE policy (You don't
have a SPF record).
So for PRA to work here, the MAIL FROM had to have an SPF record. If mail
from was my address:
Mail from: spf-discuss(_at_)winserver(_dot_)com
and the PRA check would of trapped this spoof.
The difference?
PRA required you to do a higher bandwidth payload transfer of 2 megs before
it can determine the result which was possible at the 2821.Mail from state
point before the wasteful 2 megs was needed.
If PRA is adopted across the world, it will not take too long for hackers,
spammers to figure out that they can frustrate systems by bombarding them
with higher than normal payloads creating new scalability problems across
the board.
When I mentioned this concern to Microsoft and others during MARID, the
response I got from Harry was basically:
"Any payload increase will be insignificant compared to
the benefits of SenderID/PRA."
That's when I basically said:
"Yeah, that's the same attitude that got MS Windows
in trouble with its relaxed security in the name of OLE
technology."
This is when the SUBMITTER idea came along as a way to get the PRA at the
2821 level and avoid accepting the payload.
In my view, SUBMITTER is an acceptable idea for SPF, not spoof-proof, but it
was better than having to deal with the unreliable 2822 PRA higher payload
considerations to address the forwarding problem.
The only problem I have with SUBMITTER is that it exposes too much user
information. A user privacy concern for legitimate authorized users who use
aliases addresses. SUBMITTER only needs the responsible domain. Not the
complete address exposing information the user did not want to do.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com