[Top] [All Lists]

Re: Chain of Trusted Forwarders

2005-05-29 02:35:44

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:


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


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.


   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.

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