Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
On Fri, 2004-10-01 at 22:53, John Leslie wrote:
It's all too easy to argue over which word to use, only to end up
with everyone agreeing which word, but disagreeing what they mean
when they use it. I'd rather not start down that lane.
I'm afraid we're suffering from a related problem: regardless of
whether we call a service "reputation" or "accreditation", people assume
we're talking about the same thing. :^(
On Fri, 2004-10-01 at 12:50, John Leslie wrote:
I'm still not convinced it makes sense to partition our work along
these lines. The DNA portion of CSV is _quite_ minimalist: merely
_allowing_ a standard method for listing of accreditation service(s)
which favorably rate the (EHLO) domain...
I'm going to try calling this "accreditation" service a "sending
SMTP client accreditation service" (SSCAS for short, when I get tired
of typing in in a particular message).
Beyond the real-time rejection issue, I think reputation information
_is_ necessary. Besides, real system administrators _will_ be using
reputation information -- or they'll face DoS by sheer volume of spam.
And I'm going to try calling this a "receiving SMTP server reputation
reporting service" (RSSRRS for short, if the occasion demands).
(In working up the initial CSV spec, we kept stumbling over which
function we were talking about until we agreed to use the longwinded
"sending SMTP client" and "receiving SMTP server" terms. Hopefully by
the time we reach last-call we'll have come up with terms for these
services which are _only_ three or four words long; but for now, please
refrain from trying to shorten these terms.)
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
With respect to the details of DNA, you know I am interested. : )
Indeed. Doug and I have been batting this around. I agree with most
of his thoughts on what a reputation report to a receiving SMTP client
should look like. I just don't agree that such reports should be within
the scope of CLEAR.
Are you suggesting to move DNA out of CLEAR?
I was suggesting that the "receiving SMTP server reputation reporting
service" may not belong within the CLEAR charter. This sort of service
needs to report on "all" domains found in EHLO strings, and will worry
about getting sued by disgruntled sending domains.
The "sending STMP client accreditation" report format is necessary,
IMHO. This has no need to report on any domains except those who have
accepted a contract for the conditions of listing. The RSSRRS's _need_
to access these accreditation reports as _part_ of their evaluation
process.
(We'd also, IMHO, be poorly advised to try to nail down a "solution"
to any particular "spam" problem through accreditation standards.)
I see accreditation useful for bulk emailers wishing to differentiate
themselves.
Doug is talking about the "sending SMTP client accreditation service"
here. I agree it's useful for (legitimate) bulk emailers -- whether or
not the receiving SMTP server queries the SSCAS directly.
It is difficult to know, looking at content or volume to know when
these mailers are following an opt-in only policy.
This is one of the things a SSCAS should report, IMHO. But it doesn't
rise to the level of a MUST in DNA, because we won't be able to enforce
a particular meaning for "opt-in only policy". (I'm willing, BTW, to
discuss whether we should extend DNA to make something like this a
SHOULD.)
Having a class/state assertion rather than a quality assertion makes
for a simpler solution. Allowing a flag that indicates an affiliation
to a group that assures BCP regarding the sending of mail seems like
a good way to go, hence the term accreditation.
Doug makes a reasonable case for this extension. Dave, I think, is
less enthusiastic. How do others feel?
--
John Leslie <john(_at_)jlc(_dot_)net>