Re: Chain of Trusted Forwarders

At 08:59 PM 5/28/2005 -0400, John Leslie wrote:
> David MacQuigg <david_macquigg(_at_)yahoo(_dot_)com> wrote:
> >
> > I would establish three levels of compliance for servers wanting to be
> > listed as Public Mail Servers:
> >
> > 1) Servers that will declare their ID, and provide a DNS record to
> > authorize the use of that ID.
>
>    This is, in fact, what CSV does.
Tell me what is the declared identity for the following:

   EHLO  building7.bigforwarder.com
   MAIL 
FROM:<<mailto:bob(_at_)sales(_dot_)some-company(_dot_)com>bob(_at_)sales(_dot_)some-company(_dot_)com>

Each of the methods, including CSV, *uses* an identity.  None of them 
*declare* an identity.  A declaration is an affirmative statement, made by 
the sending MTA.  "This is <ID> sending to you from <IP>".  An MTA 
declaring a fake ID should be the legal equivalent of a radio broadcaster 
using fake call letters.
Imagine you are a border guard not allowed to ask for an ID.  You must go 
through each person's bag, checking whatever IDs you might 
find.  Furthermore, it is common practice for travelers to carry lots of 
IDs, most of which are not theirs, and none of which *must* be theirs.
It seems strange to me how hard it is for techies to grasp this 
concept.  Maybe we should add a course in law, along with literature, 
history, etc.
Yes, I know that EHLO *could* be a declaration, but that is not current 
practice.  If we are worried about 1 in 1000 forwarders reordering headers, 
we should be much more worried about the widespread misuse of the EHLO 
identity.
If we could extend the EHLO syntax, we might almost have it.  Maybe 
something like
   EHLO building7.bigforwarder.com.2

meaning the last two pieces of the EHLO name are the declared ID.  This 
might run into some opposition from SPF and SenderID, but at least it gives 
us an unambiguous declaration, until someone comes up with an excuse to 
append a digit for some reason other than declaring an ID.
> > 2) Servers that will capture the IP address and any ID declared by the
> > previous sender, and prepend that information in a standard authentication
> > header.
>
>    This, while interesting, is not useful.
It would allow the final receiver to authenticate the ID, assuming of 
course, that the forwarder is lazy, but still trusted.
> > 3) Servers that will perform an authentication check on the declared ID,
> > using any widely-accepted method, and prepend the result of that check.
>
>    This is the "chain of trust" idea. It is easy to ridicule any chain
> of trust, which is never stronger than its weakest link; but if we follow
> a prepending model, we have some genuine hope of reaching that strength.
> To paraphrase Thornton Wilder's Matchmaker, "The difference between a
> little trust and no trust at all can shake the world."
As a receiver, the only part of the chain I care about is the last few 
links.  That will include my forwarder, and perhaps one designated by the 
sender, if it has a good rating.  We rate the ID at that point, and I don't 
care about any prior links.  I expect lots of spam will arrive with A-rated 
names, then an unknown forwarder, then my forwarder.  That unknown 
forwarder will be getting many spam bounces.
> > Servers which only originate, and do not forward mail from other domains,
> > need only reach Level 1.
>
>    Exactly.
>
>    And, in fact, level 3 is merely a nice-thing, not an essential.
> Reputation services could perfectly well rate forwarders on how well
> they do at rejecting bad-reputation sending MTAs.
Rejection by a forwarder, based on reputation, should be done only by prior 
arrangement with the final receiver.  In general, a forwarder won't know 
what the receiver's policy is.  Authentication failure, on the other hand, 
should cause an immediate reject.  This depends on the authentication 
method delivering an unambiguous PASS or FAIL, something we don't have now, 
even with CSV.  With an ID declaration, and a DNS record that calls for a 
CSV check, then we have it nailed.
Exception:  Depending on what the future is like, we may want to have some 
widely accepted policy of forwarders rejecting mail from D-rated 
IDs.  These would be known spamming domains.  My crystal ball says there 
won't be many of these, and spammers will be using mostly C-rated (unknown) 
IDs, and an occasional hijacked A or B-rated name.  I look forward to 
getting maybe one piece of spam per week.  I will drop what I'm doing, read 
it carefully to make sure it isn't some friend spoofing me about p3nis pilz 
from Nigeria, and try to be the first to report a leak in the system.
>    What this _does_ buy us is the ability to pass on useful reputation
> information, to be evaluated later in the forwarding chain.
Again, let's leave reputation assessment to the final receiver.  What we 
need is a format for trusted forwarders to pass on *authentication* results.
--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *