Rough consensus reached. Let's move on.

I sense a rough consensus that all of the following, applied together, 
will be more useful than all but any one of them:
1)HELO checks
2)MAIL FROM checks  (The C-ID folks admit this is not a bad idea.)
3)From: (and other 2822) checks (The longstanding LMAP folks admit this 
would be nice, but hard, and insist 1) and 2) are essential.)
4)Maybes: MTAMARK, spamhaus's cool .mail proposal! and CBV
5)DNSRBL, DNSRWL, Bayesian Filtering, etc that is already in widespread use.
6)RHSRBL, RHSRWL.
7)Accreditation marks for WL.
8)SRS &| VERP

There hasn't been any consensus movement toward or strong argument for 
elimination of 1, 2, or 3.  Agreed?
And I think the problem is hard enough that we should assume use of ALL 
of them:
I'm hopeful, but not yet confident that all 8 of the above, even if 
widespread and applied together, will cause a drastic *long term* 
reduction of abuse!
So, MARID should provide the info to support at least 1,2,3,6 
(implicitly), and 7.
Does anyone want to assume this consensus and move on?  It's not May '04 
yet, but I think it's time to move to step two. Let's start thinking 
about how one might code this, which will likely inform more exactly 
what MARID records need to provide?  In other words, I'd like to
We will be doing this NOT to make it part of the spec's *requirements*: 
we don't want an RFC that tells people they MUST filter or tag in a 
particular way, but I think we need not shy away from saying how people 
MAY, and in some clear-cut cases SHOULD tag/filter* if they want to use 
the info MARID records in a sensible/BCP way.
It would be a great thing to have pseudocode that supports all of the 
above, and be able to look at it and say 'This looks like it'll handle 
the whole abuse problem so well we don't need the following stuff in 4 
and 5: ______, which will make adoption faster.  I noticed that the 
media (Network World front page!; dumb article on our "Anti-Spam" 
"Crusade") think we're aiming to tackle the mail abuse problem using MTA 
authorization, and I think that's our goal, even if it isn't stated in 
the charter.)
It would even be a great thing to have pseudocode that supports all of 
the above, and be able to look at it and say 'This looks like it won't 
handle the spam problem very well in the long term; anyone have a better 
idea?
*Probably best to call it "classify", and say that action based on that 
classification might be tagging, filtering, prioritizing, bouncing, 
dropping, etc, under a policy known to, and preferably defined by the 
recipient.
Who wants to collaborate on an LMAP receiving MTA pseudocode (or code) 
draft?