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:<<mailto:bob(_at_)sales(_dot_)some-company(_dot_)com>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.)
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.
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).
Recall, the EHLO is the identity of the MTA, not the identity of its
management.
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.
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
practical...
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.
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>