Dave,
spam is a complex problem and email is a complex system. it is
certain that any one control mechanism we introduce will be either
limited or useless. we get to choose which.
Of course, but we aim for utility rather than making something pointless.
So we set our limits sensibly.
JK> Some people may have an interest in
JK> binding authorship and transport. We can't say that they're wrong.
maybe we can.
No. They're not wrong to have such an interest. You can say that MARID is
not the best (or correct) way to do it.
things like layer violations are a concern for good and serious
engineering reasons. also good and serious operations reasons.
Layers are tools for problem analysis. Layers can always be collapsed if
the problem space covers more than one. It's not necessarily sensible to
recast a problem to fit into a layered model which was designed for another
problem.
JK> Taking all that into consideration, I've come to believe that
allowing the
JK> publisher to identify the identities that a record applies to might
be the
JK> best way.
I'm not entirely sure what you mean by this, but it sounds quite a bit
like defining a general method of letting others define specifics. On
the average, protocols that do that do not work.
Not at all, we can specify a set of options. Write them in stone if you
like. Let a publisher choose which suit them.
JK> Or, viewed slghtly differently, we should support the publisher
JK> in making a richer description of what their "legitimate" mail looks
like.
On the average, artificial intelligence algorithms do not work well at
the core of a high volume networking service like email. Alas, that's
the technical base that would be required to implement the sort of
description-based service you (and others) are suggesting.
I'm not sure what you mean by "artificial intelligence". I'm never sure
what anyone means by the term, it's been so abused. If you mean "simple
heuristics", I agree that this is probably what's needed, but I can't see
that it would be hideously expensive. Equally, I don't know what you mean
by "at the core". I'm guessing you don't mean "in the infrastructure".