MARID is an authentication system (title mistake aside).
Access Control = Authenctication + Authorization.
Right. There's no authorization mechanism available yet for
Caller-ID, which is what I meant when I said I didn't see the value.
MARID, SPF and CallerID are composed in two parts
NORMATIVE: Syntax for describing outgoing edge MTAs
SUGGESTIVE: Rules for senders to interpret above
I don't believe that this group has any business telling receivers
what to do with the bits they receive. Hence I make zero distinction
between MARID, SPF and CallerID at the normative level beyond syntax.
I didn't mean the whitelist_from rules (which whitelisted
based on the
From address alone) - I meant all of the negative scoring rules. It
became a meta rule if you're writing a heuristic spam filter: "never
have non-spam rules"
It is very obvious that spammers attempt to game filters. The purpose of
MARID is to provide recipients with data that cannot be gamed. Therefore
the spamassasin experience is obsolete.
It is just as big a mistake to blindly whitelist domains that have
SPF records.
SPF is clearly designed with different aims in mind. It's a rejection
mechanism not an acceptance mechanism.
I see no difference, the data is what the data is. There is no difference
between the decision power possible if the originator configures their
mail servers in SPF, CALLER or MARID syntax. The set of information thaqt
can be deduced is precisely and exactly the same.
Accreditation is out of scope here, but MARID is a component of a
spam solution not a complete solution in itself.
Today MARID + Spam filter = improved spam situation
Future MARID + Accreditation = The end of spam
My question then, if the MARID you propose is a whitelisting
mechanism,
is what is the difference between "Spam filter" and "MARID + Spam
filter"?
Accuracy.
MARID + Spam filter will eliminate 100% of false positives in the case
that the sender can be authenticated AND authorized.
Authorization = Accreditation + local heuristics.
Local heuristics can be very powerful. For example I whitelist
hkatz(_at_)microsoft(_dot_)com, the authorization engine might then induce
a rule provisionally whitelisting *.microsoft.com.
Harry talks about barriers to acceptance with SPF (breaking
forwarding), but if the *value* of accepting Caller-ID is
effectively a
"short" (a gamble on a potential future gain), I can't help but feel
this is a larger barrier.
The pain point for mail admins is management of whitelists when
senders get blocked wrongly. There is a huge cost for the sender
(getting onto the whitelist) and the receiver (listening to the
arguments).
That process can be automated very easily and at very low cost
relative to the current cost.
Phill