Re: a grand unified theory of MARID (blame me!)

On 6/20/04 9:35 PM, Greg Connor sent forth electrons to convey:

> --Matthew Elvey <matthew(_at_)elvey(_dot_)com> wrote:
>
> > Hello from a regular MARID poster!
>
>
> Hi Matthew!  Good to see you.
Thanks!  See my reply to Simon, please.

> > Meng's latest SPF plan (in which he has borrowed my idea of CSV 
> > semantics
> > using SPF records) was influenced by, among other things, a group of us
> > pushing strongly for HELO to always be checked.  SPF already required
> > that the HELO be valid, so the change from saying that it MAY be checked
> > to it MUST be checked is not an issue, with respect to senders having to
> > comply with a new requirement.
>
>
> I think the HELO aspect of CSV makes a good union with SPF.  I'm sure 
> you agree too.  What I didn't like about CSV is that it doesn't go far 
> enough, in my opinion.
> The "unification theory" is about using the same tool set to check 
> many different identities.  It's not about checking HELO and that's it.
Right.

> LMAP proposals are many things to many people.  For me in my role as a 
> domain owner, I would like to be able to protect against ALL phony 
> uses of my domain, whether in HELO, MAIL FROM, From:, Sender:, or any 
> header that users may see and think it came from me.  That is the 
> essence of unification to me, that ANY identity can be checked.
> If you are only checking HELO, what would you propose... 
I'm only checking HELO?   I didn't say that.   I'm saying we do things 
the 'Unified SPF' way.
> to do that would stop someone from using a machine on comcast's 
> network that HELO's as something ending in comcast.net, and uses my 
> domain nekodojo.org in MAIL FROM and Sender:?
Well, there's what you quote immediately below, for one.  There was 
discussion of a flag for persistent joe-job/phishing victims to use; you 
could use that.  (If it's not in the spec, I'm still going to bet that 
it will be.)
> > Remember, whatever the source for the domain that MARID validates,
> > blacklists and reputation services will be an integral part of the 
> > system.
> > A domain with a MARID record used in email with malicious forged 
> > From: is
> > gonna get in an RHSBL lickety-split: If you get word of From: forgery,
> > you're gonna be motivated to do a little work to get the spammer's 
> > domain
> > blacklisted, for example by putting him in your RHSDRBL (Right Hand Side
> > Distributed RBL), which will stop the forgery and phishing.
>
>
> I agree that reputation systems will be important, but I think they 
> should not be the only weapon we have against forgery.  I.e. if you 
> get a passing result from one identity, that's a great place to hook 
> in a reputation system... for example I believe AOL is planning to do 
> something similar with its whitelisting approach.  However, if the 
> sender is not known to you and 100% trusted, you would be silly to 
> stop before checking all the other identities.  A PASS result means 
> that I can hold the domain owner accountable for the behavior of the 
> MTA, but a FAIL result should always be questionable.
> Put another way, if the reputation is snow-white, or you trust the 
> sender, go directly to accept.  If the reputation is black or the 
> thing is clearly forged, go directly to reject.  If it's in the wide 
> gray area in between, keep going and check the next identity...  am I 
> right?
Yes, that's right.  See the slide from the slideshow in my post to Simon.

> OK Thanks for the note... I am hopeful that we'll all come to some 
> kind of agreement, and I think we're closer now than ever. 
:)