[Top] [All Lists]

Re: Chain of Trusted Forwarders

2005-05-29 18:29:35

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:


   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.)

Yes, I know that EHLO *could* be a declaration, but that is not current 

   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.

If we are worried about 1 in 1000 forwarders reordering headers, 
we should be much more worried about the widespread misuse of the EHLO 

   CSV _does_ worry about that.

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. 

   No: that would be declaring the identity ""
(which could never pass CSV).

   Recall, the EHLO is the identity of the MTA, not the identity of its

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 

   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.

   In practice, forwarders that _don't_ reject enough suffer excessive
bounce messages related to forwarding, which are a pain to evaluate.

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

Authentication failure, on the other hand, should cause an immediate

   Again, not practical. Hard-failure of authentication is too rare;
and there's no incentive for spammers to give it to you.

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.

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.

John Leslie <john(_at_)jlc(_dot_)net>

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