Re: Re: Email Forwarder's Protocol ( EFP )

At 10:22 AM 2/28/2005 +0100, Alex van den Bogaerdt wrote:

> On Sun, Feb 27, 2005 at 06:29:24PM -0700, David MacQuigg wrote:
>
> > >Please show where this explanation states that forwarders
> > >are indeed relays and not, say, a user process.
> >
> > Section 2.2 defines Relay as a very general term, including everything from
> > User Mediators ( Forwarders, Mailing Lists, etc. ) to Packet Switches.
>
> I don't see this.
>
> If you are talking about 2.2.3 then you should also have seen:
>
> "A Relay may add information to the envelope, such as with
>  trace information.  However it does not modify existing
>  envelope information or the message content semantics."
>
> It does not change envelope information.  Therefore, if
> "rfc2821.rcptto" changes, a new message was created.
OK. :>)  Looks like I was misreading this section.  Relays do *not* include 
User Mediators or Packet Switches.  The inclusion of these in section 2.2.3 
was only to illustrate that all three of these entities do 
store-and-forward, a minor point in my estimation.  I would delete the last 
sentence of paragraph 2 and the bulleted list, or just put the list in 
parentheses: "Hence, interesting email scenarios can involve three levels 
of store-and-forward: ( User Mediators, Relays, and Packet Switches )."  I 
used the term Relays, rather than "MHS Relays" to avoid the confusion that 
Relays includes ( User Mediators, MHS Relays, and Packet Switches ), where 
MHS Relays is some subset.
This raises the question why does anyone need Relays?  The only example is 
in the first paragraph of 2.2.3, a text-to-binary converter.  Seems to me 
that such a device would have to be outside the TCP/IP network.  The data 
in an IP datagram is always binary.  What would be an example of a 
legitimate use for a Relay on the public Internet?  Could such a Relay be 
used without either the Sender or the Receiver setting it up?  If we simply 
say that Relays cannot participate in an SPF authenticated exchange, do we 
limit the usefulness of SPF?  DomainKeys and other end-to-end protocols can 
use Relays with no problem.
> > >New message -> new source to new destination -> new RFC8221 MailFrom
> > >
> > >I'm interested to see if, and where, this document would allow
> > >to retain MailFrom when RcptTo changes (apart from internal
> > >rewriting of RcptTo perhaps)
> >
> > I don't think it addresses this issue at all.  The core of the problem is
> > not what some spec allows, but whether it is technically possible for a
> > Spammer to fake the Mail From address.  If this is done at any point along
>
> [snip sarcasm]
>
> The issue I addressed was the supposed SPF forwarder problem.
> There is no such problem.  Once a message is no longer directed
> to the original RFC2821.RcptTo, the message was delivered.
The fundamental problem is not changed by our clarification of the term 
Relay.  I will use *Forwarder* from now on, and mean a User-level actor 
that receives an email and re-routes it in a new transit through the Mail 
Handling System.  As long as there is an insecure *Forwarder* in the 
chain-of-trust from the original Sender to the final Receiver we have the 
possibility that the Return-Path can be faked.  Here is an example of a 
piece of spam I just sent to myself, faking the Return-Path as amazon.com:
Return-Path: 
<SRS0=BF6T=RK=amazon(_dot_)com=forged(_at_)bounce2(_dot_)pobox(_dot_)com>
Delivered-To: dave5(_at_)gainusa(_dot_)com
Received: ( **SaniMail 47655 invoked from network** ); 28 Feb 2005 15:35:36 
-0000
Received: from unknown (HELO gold.pobox.com) (208.210.124.73)
  by mail5.mailsystem.us with SMTP; 28 Feb 2005 15:35:36 -0000
Received: from gold.pobox.com (localhost [127.0.0.1])
        by gold.pobox.com (Postfix) with ESMTP id 6CFD67111A
        for <dave5(_at_)gainbroadband(_dot_)com>; Mon, 28 Feb 2005 10:42:29 
-0500 (EST)
Delivered-To: dave5(_at_)pobox(_dot_)com
Received: from gold (localhost [127.0.0.1])
        by gold.pobox.com (Postfix) with ESMTP id 4DE60710B8
        for <dave5(_at_)pobox(_dot_)com(_dot_)07422030(_dot_)000(_dot_)icgmh>; Mon, 28 Feb 2005 
10:42:29 -0500 (EST)
X-Pobox-Pass: forged(_at_)amazon(_dot_)com is whitelisted
Received: from amazon.com (unknown [216.183.71.194])
        by gold.pobox.com (Postfix) with SMTP id 51DD271180
        for <dave5(_at_)pobox(_dot_)com>; Mon, 28 Feb 2005 10:42:26 -0500 (EST)
Received: from [219.130.16.181] (helo=67.15.58.29)
        by server5.emwd.com with smtp (Exim 4.44) id 1Cxh3v-0006Ab-8W
        for cdp-design(_at_)cdp-design(_dot_)org; Sun, 06 Feb 2005 02:42:52 
-0500
FCC: mailbox://identifdep_id7(_at_)smithbarney(_dot_)com/Sent
X-Identity-Key: id1
Date: Sun, 06 Feb 2005 06:36:53 -0100
From: SmithBarney <identifdep_id7(_at_)smithbarney(_dot_)com>
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cdp-design(_at_)cdp-design(_dot_)org
Subject: Attention To AII Smith Barney CIients
Content-Type: multipart/related; x-Spamnix=checked;
        boundary="------------060705020202080904070006"
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
Message-Id: <20050228154226(_dot_)51DD271180(_at_)gold(_dot_)pobox(_dot_)com>

< Amazon's logo here >

Dear Amazon Customer:

We lost your password, and we charged your credit card $100.  Click here to 
re-enter your password and remove this charge.
As you can see the 'amazon.com' Return-Path, was propagated all the way 
from my original Mail From command to the final Return-Path.  SRS doesn't 
help.  It just retains whatever identity it got from the previous 
Forwarder.  The integrity of this identity is only as good as the weakest 
link in the chain.  This seems to be a fundamental limitation of 
IP-authentication, but one that I can live with if we have a good 
forwarding protocol. one that meets the six requirements I stated at the 
beginning of this thread.
With a good forwarding protocol, I would not need an expert to study the 
headers in the above email to find the source of the problem.  Instead, I 
would just hit the "Reject as Spam" button and this FPOS would go back the 
path it came, first to postmaster at mailsystem.us, and where it goes from 
there, I don't care.  If mailsystem.us is confident it did its 
authentication properly, it could bounce to pobox.com, and so 
on.  Eventually, the spam will get back to the postmaster responsible for 
either a) originating the spam, or b) allowing it to enter the public mail 
without proper authentication.
Here is another idea for an authentication header:

Return-Path:  mailsystem.us   pobox.com    emwd.com   china.net  amazon.com

Only the first domain in this chain-of-trust is authenticated by my 
Receiver.  The rest are only what was passed on from the previous 
forwarder, and therefore have varying levels of trust.  pobox.com is the 
forwarder I pay to handle my incoming mail.  emwd.com is a mailing list I 
manage for our homeowner's association.  china.net I've heard bad things 
about.  amazon.com is clearly not involved in this phishing scam.  If this 
spam continues even after reporting it to postmaster at mailsystem.us, I 
will probably put china.net on my personal blocklist.  I don't know anyone 
in China, so for me, blocking that domain is low risk.
The process must be quick and easy for users and everyone else 
involved.  That is the key to getting email authentication accepted.  It's 
not a question of technology.  SPF, SenderID, DomainKeys, all are 
technically capable of doing the job.  I guess if I were placing a bet 
right now on which one will be dominant a year from now, I would have to 
say SenderID.  They have an impressive list of partners signed up.  SPF 
might still make it, leveraging its open-source appeal, but they will have 
to get smart real quick on the non-technical aspects of the 
problem.  DomainKeys will probably be a small, but important supplement for 
those needing high security, end-to-end, Relays be damned.
-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com