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

At 01:42 PM 2/28/2005 -0800, you wrote:

> > >  This raises the question why does anyone need Relays?
>
> For administrative control, traffic aggregation and routing 
> control.  These are the same reasons that packet-switches, such as IP 
> Routers, are used at the network layer.
Wow!!  And I thought all this routing, traffic cop stuff was taken care of 
at in the Network layer.  This raises the possibility that SPF could fail 
even on what appears to be a single "hop".  If there are Anonymous Relays 
between the Sender and Receiver, the one piece of info vital to 
IP-authentication, the Sender's IP address, is not preserved all the way to 
the Receiver.
I've been assuming all along that these Relays were Forwarders, under the 
control of either the Sender or the Recipient.  Recipient's Forwarders we 
can trust to authenticate properly (not now, but in the future).  Sender's 
Forwarders, if not explicitly authorized by the Sender, I've been assuming 
are not legitimate.
This adds a whole new twist to the challenge of IP-based 
authentication.  These Relays will have to identify themselves, add a 
Received header, do SPF correctly, basically become Forwarders.
> >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.
>
> However the default data encoding at the email layer is not binary.  It is 
> a modified 7-bit ASCII.
Are these text-to-binary Relays needed anywhere in the public part of the 
Internet?  Seems to me once the data is packaged at the Source in an IP 
datagram, there can't be any messing with it on the way to the IP Destination.
> >  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.
>
> yup.
>
> >  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.
>
> This assessment would be more comfortable to make if there were examples 
> of high-quality chain-of-trust systems that operated on the scale of the 
> Internet and with anything like the underlying administrative model.  The 
> only examples of related models I can think of involve governmental 
> oversight and/or legal contracts.
The chain-of-trust I am counting on goes back only a hop or two.  I would 
trust my own ISP, and a Forwarder of my choosing, (maybe pobox.com once 
they get their act together) I would trust those two to authenticate 
properly.  Anything prior to that is just a domain name wanting access to 
my Inbox.  If its a spam domain, it hardly matters whether the spammer 
calls it a Sender or a Forwarder.  In fact, I would assume all Forwarders 
prior to my own don't even exist.  They are just headers added by the 
spammer to make it look like a legitimate chain-of-trust.
The ideal protocol I have in mind would involve a list of trusted 
forwarders for each Recipient.  I have three ( pobox.com, ieee.com, 
emwd.com ).  If an email for me comes from pobox.com, I really can't send 
that name to my spam filter.  My ISP must authenticate pobox,com, then go 
one hop back for the real domain name.  The domain that pobox.com 
authenticates is the one I should use in my spam filter.  pobox.com is in 
effect my ISP for incoming mail.
-- Dave MacQuigg

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