Re: Chain of Trusted Forwarders

John,

I think the root of our misunderstanding is our different expectations for 
the future.  You seem to be assuming everyone will be using CSV.  While I 
would certainly prefer that outcome over what I see developing, I can't 
just assume it will be true.
Let's work through the example below, assuming you are bigforwarder.com, 
and I am the receiver.  Let's say it is 2007, and CSV is the only method 
blessed by the IETF.  Unfortunately, nobody is listening to 
them.  Microsoft has just won its court battle with SPF over re-definition 
of SPF1 records, and *SenderID*(TM)/spf now has 40% market share.  CSV is 
at 20% and the other 40% are either not participating, using some other 
method, or have old useless SPF1 records that they never bothered to update.
At 09:29 PM 5/29/2005 -0400, John Leslie wrote:
> David MacQuigg <david_macquigg(_at_)yahoo(_dot_)com> wrote:
> > 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:<bob(_at_)sales(_dot_)some-company(_dot_)com>
>
>    The EHLO _is_ a declaration of the identity of the sending MTA. Thus
> CSV treats "building7.bigforwarder.com" as the declared identity. (We
> then try to match it to a declaration of authorization; failing that, it's
> not a _useful_ identity.)
I have no prior relationship with bigforwarder.com, so I don't know that 
you are using CSV.  My setup is to try SenderID first, since that method is 
the most prevalent.  If I find a PRA record, I run the SenderID check and 
don't bother with any others.  I would prefer CSV, but I must do whatever 
is quickest to keep my costs down.
If you are bigforwarder.com, how are you going to signal me that CSV is 
available?  Will you also offer SenderID?  Many of the 40% using it do not 
use any other method.  You don't know if I am one of those.
As a receiver, I cannot assume a sender is using CSV.  Without some prior 
arrangement, there is no way to tell what identity, if any, the sender is 
prepared to authenticate.  Even if we could assume the EHLO identity is 
always compliant with RFC-2821, it still is not an identity acceptable to 
the other methods.  Without the kind of compromise I am proposing, we are 
in for a long and wasteful battle.

> > Yes, I know that EHLO *could* be a declaration, but that is not current
> > practice.
>
>    Au contraire! It always _is_ a declaration of identity: it's just not
> always a useful identity in current practice. CSV declares it to be a
> useful identity if it matches a declaration of authorization.
I would say CSV "uses" the EHLO identity, and it "hopes" it will be a 
useful identity, but it certainly doesn't "declare" anything.  Methods 
don't declare.  They are not "actors", to use Dave Crocker's email 
architecture terminology.  Sending MTA's could "declare", but they 
typically just "state" or "show" or "pass on", maybe at best "reveal" 
various identities.
I hope I'm not being unreasonable in my insistence that we use the verb 
"declare" properly.  There is a vital distinction involving intent and 
deniability.  The sending MTA's declaration must be an explicit, formal, 
unambiguous assertion of the exact identity authorizing a transfer.  A 
false declaration must not be excused by the fact that an identity has 
never been checked before, has frequently been misused in the past, or may 
even have a definition that many people feel is contrary to its use as a 
sender's identity.

> > 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.
>
>    CSV _does_ worry about that.
>
> > 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.
>
>    No: that would be declaring the identity "building7.bigforwarder.com.2"
> (which could never pass CSV).
I'm talking about what *could* be done to salvage the EHLO identity without 
breaking existing MTAs.  I'm sure you could think of many alternatives.
>    Recall, the EHLO is the identity of the MTA, not the identity of its
> management.
This is a limitation that will make its use as a Sender's Identity 
unacceptable to other methods.

> >>> 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.
>
>    Agreed. The shorter the chain, the more likely that the level of
> trust will be useful.
>
> >> 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.
>
>    Au contraire! Rejection (at SMTP time) is a matter of forwarder
> policy. So long as that policy is well-documented, the forwardee has
> no legitimate complaint.
If you take on this responsibility as a forwarder, you will have to 
implement different policies for different receivers, and will need some 
mechanism to rapidly change policies in response to customer requests.  At 
one time, I might be waiting for some mail from my sister in Baghdad, and 
want to send all C-rated mail to a special mailbox.  At another time, I 
might decide to have you reject it all.
>    In practice, forwarders that _don't_ reject enough suffer excessive
> bounce messages related to forwarding, which are a pain to evaluate.
No evaluation is necessary, other than making sure they are legitimate 
bounces, not backscatter.  As a Trusted Forwarder, you will be getting Spam 
Bounces.  Your responsibility is to immediately bounce them upstream.  You 
may also want to aggregate some statistics from all of your receivers, and 
file your own spam reports on any that look like widespread abuse.  In the 
case of outright mail bombing, you may want to take the extreme action of 
blocking selected IPs.  This should only be done if the owner of the IP is 
unresponsive.
> > In general, a forwarder won't know what the receiver's policy is.
>
>    Absolutely true! It would be nice to simply collect enough information
> and let the final receiver make the decision. Alas, it doesn't look
> practical...
I think it *will* be with an effective authentication standard in place, 
but I'll admit, my crystal ball is a little cloudy that far into the future.
> > Authentication failure, on the other hand, should cause an immediate
> > reject.
>
>    Again, not practical. Hard-failure of authentication is too rare;
> and there's no incentive for spammers to give it to you.
Let's not get too hung up on current operational problems.  Again, this is 
crystal-ball stuff, but I see the "softfails" and other interim 
complexities eventually falling away, and almost everything, including spam 
will be PASS.  Authentication failure will be like a broken communications 
link, something to be fixed quickly without bothering the user.
> > This depends on the authentication method delivering an unambiguous
> > PASS or FAIL, something we don't have now, even with CSV.
>
>    There are entirely too many clueless folks out there running MTAs
> for us to ever hope for 100% of email to have unambiguous PASS/FAIL.
The clueless will hire someone to help them get set up, just like they do 
now for setting up their routers.  They cannot operate a Public Mail Server 
until they get their authentication setup working.  More crystal ball, I know.
> > With an ID declaration, and a DNS record that calls for a
> > CSV check, then we have it nailed.
>
>    I can't agree, alas, though in fact CSV _does_ have all that.
Only if we assume the whole world will be using CSV.

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