I agree with most of what Phillip wrote here, but I want to focus
on just one issue:
Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
It is a simple fact that any mail system administrator of any system
of any size is required to spend a considerable amount of time
negotiating to have their email accepted.
I will not detail what it took to get jlc.net off Verizon's blacklist;
suffice it to say it indeed took "a considerable amount of time".
At present those relationships are bilateral. The emergence of
mediated multilateral agreements in the near future is inevitable.
Bi-lateral does NOT scale!
It is considerably cheaper and more convenient for an email
administrator to establish their bona-fides affirmatively with a
single reputable agency...
I believe that the accreditation issues themselves are outside the
scope of MARID, how that information is published is not the concern
of this group.
Agreed; but read on...
Natural prudence suggests that MARID should support some form of
extensibility mechanism, the simplest possible of which being a list
of attribute value pairs...
The simplest possible form of accreditation protocol support in MARID
would be a statement in the profile record that informs the client
that there is a third party accreditation record which may be verified
by the specified protocol. something like:
example.com MARID 10.2.1.2/24 smtp.example.com ACCRED=class3.bondsman.com
I do NOT want to discuss syntax.
But I do want to emphasize the major benefit of having a way for
the sending domain to suggest reputation services (plural, please)
for the receiving MTA (or MUA, for that matter) to check.
Please understand, there CANNOT be a single reputation service which
serves all needs. There will be a considerable number of receiving admins
that trust only senders which promise to do something which will turn out
to be illegal in some country most people don't even know how to spell.
Thus, there will need to be a negotiation process to find a reputation
service acceptable to both receiver and sender (if such a thing exists).
At first blush, it would seem reasonable for this negotiation to
start with a error message from receiver to sender. However, that puts
the primary burden on the receiver, which would have to check the
reputation of the sender on _every_ reputation service it supports
before returning the error. Thus receivers would tend to minimize the
number of services they support. (Can you say, zero?)
If we instead select a design where the sender starts the negotiation,
the incentives work much better. Senders would tend to support a greater
number of services; but receivers would never have to check more than one.
I believe there is consensus here that reputation services will be
necessary (or, at least, inevitable); but that we don't want to touch
the issue of how they would operate. For all I care, they could be a
web-cam showing the entrails of some recently-sacrificed animal for
do-it-yourself divination. ;^)
But, IMHO, the _useful_ reputation services will be those to which
both sender and receiver voluntarily subscribe. I want no part of any
"certificates" which might be involved; but I would like to offer this
minimal help to senders and receivers searching for common ground.
(I will be perfectly happy, BTW, if our first published standard
includes none of this, so long as it leaves room for the expansion.)
--
John Leslie <john(_at_)jlc(_dot_)net>