[Top] [All Lists]

Re: Chain of Trusted Forwarders

2005-05-30 12:41:50


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, 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
>    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 "" 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, 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, 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
> meaning the last two pieces of the EHLO name are the declared ID.

   No: that would be declaring the identity ""
(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

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

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.

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

<Prev in Thread] Current Thread [Next in Thread>