ietf-mxcomp
[Top] [All Lists]

RE: Can you ever reject mail based on RFC2821 MAIL FROM?

2004-04-27 09:01:19

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



<Prev in Thread] Current Thread [Next in Thread>