CSV (Crocker's draft) good! (evaluation, big suggestion)

I think CSV can protect 2822.From, and with a major tweak, prevent 
joe-job damage, while being much easier to implement broadly than SPFing 
, and accomplish the goal of tying email better to a responsible party, 
bringing us much closer to a realistic near-FUSSP.
Dave Crocker (2822 author):

> Breaking legitimate functionality of a system that has been in use for
> 30 years and is currently relied on by 1 billion people obligates
> those doing the breaking to be very clear and careful about defining
> and defending the breakage.  That is not happening about this topic.
>  
Some old RFC said:

>   this REALLY IS a Request for Comments.  Comments,
>   questions, position papers are solicited.  There are, I'm sure, bugs
>   in the protocol specified here, and I hope that readers will point
>   them out via RFC as they discover them.
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 some 
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.

CSV (crocker-marid-smtp-validate): ties things as follows:
Can a spammer set up a domain and rDNS with records under the spec and 
spoof From: yes, for all the extant I-Ds, including this one, and C-ID, 
BUT not for long - the domain will get blacklisted PDQ.
Is a spammer forced to use a domain set up with records that specify its 
authorized MTAs: yeah.
Are forwarders or remailers's systems broken, requiring new software: no 
for Crocker/CSV, yes for SPF.
Are users forced to send through MTAs authorized for the domain they use 
in outgoing mail: no for Crocker/CSV, yes for SPF, C-ID, Y!DK (even 
stricter!).
MTA admins just need to ensure that they are sending appropriate HELO 
strings, which nearly all already are, and create DNS records. Wow, 
that's not a lot of systems that need touching, relatively speaking! 
(Around 2 orders of magnitude fewer than SPF+SRS).
ALL the other proposals so far don't accomplish significantly more than 
Crocker's CSV, and yet do impose significantly larger costs.
It ties to domain owner info, instead of the less accurate IP space 
owner info.  Nice, but both are often false.
It's bloody hard to read!  An intro that explains what it does 
specifically but briefly in the real world would be great. (I'd be happy 
to give it a shot.)
It needs more flexibility and extensions in specifying authorized IPs - 
stuff that SPF and FSV have added.
Y!DK is even more restrictive (and disruptive), as the keys can only be 
placed on a much smaller subset of machines than SPF could authorize, 
the only benefit being it defends against use of bogon or hijacked IP 
space better.
That anti-M$ screed forgery proved a point rather well:  No proposal 
with an I-D listed in the charter would have completely prevented the 
forgery from making it to the list.  So if they can't give the 
list-managment software the tools it needs to prevent the forgery, what 
does all the additional adoption headache they cause buy us over 
crocker-marid-smtp-validate?  In fact, there's an argument to be made 
that CSV will do a better job preventing the forgery; it goes like this:
Because CSV has a much lower implementation cost, it will get 
implemented sooner.     After broad adoption, this will be tough: the 
forger will have just two major options: use an un-blacklisted domain he 
runs on an MTA he runs (losing anonymity), or free rein over these 
things run by someone who controls them well enough to keep the domain 
off BLs (an increasingly hard thing to find).  The problem with this 
argument is that CSV lacks the early adopter self-interest motivation of 
SPF: preventing joe-jobs.   Early on, a spammer can use any SMTP server 
to send From: or MAIL FROM forgeries of an early adopter's domain.  If 
CSV can be tweaked to provide this early adopter self-interest 
motivation, it becomes a killer proposal.  One (not great) way to do 
this would be to combine it with SPF, but that comes with SRS, and 
adding something that makes adoption much harder in order to make it 
more compelling for early adopters is a tough bargain. 
I think I've found a better way. How 'bout this:
No SRS required, but a new requirement: mail that has failed (as in 
there is a MARID record AND the sending IP isn't there AND there's no 
?all) a 2821.FROM check MUST NOT be bounced; instead it MUST either be 
refused at SMTP time, or accepted and destroyed.   In other words, DON'T 
require SRS, but DO require that mail that goes via non-SRS systems not 
lead to bounces to  systems that didn't originate the original message.
What will this requirement break?  Well, fundamentally it breaks (for a 
small subset!) that all mail must be delivered (or it could specify that 
such mail goes to postmaster, but that's a broadly violated requirement 
already(e.g. some major ISPs dump mail they think is spam into 
/dev/null.)   It doesn't break SRS-compliant forwarders AND it doesn't 
break non-SRS forwarders, except if the final recipient decides it wants 
to bounce or refuse a message, that bounce or refusal won't get back to 
a sender IF she has MARID records.  It doesn't break mailing lists or 
greeting card sites or require that they change. 
Unlike SPF, it DOESN'T require that every end user use an MTA authorized 
for the 2822.From they're using!  If a legitimate user uses an 
unauthorized MTA, her mail will still get through, but any email that 
she sends to invalid addresses (eg. typos) or that bounces for some 
other reason won't get back to her. A further enhancement would be that 
SMTP servers that are unable to get a message a trusted user sends out 
for any reason would be allowed to bounce the message back to the user.  
If everyone implements SRS, it breaks nothing, and if no one does, the 
stuff it breaks is, I argue, not critical.
PS Yes, my views on the criticality of MARID directly and fully 
protecting 2822.From have changed - I didn't see that there was an 
alternative way to protect it.
PPS, I know Andrew just posted that we should do 2821, then 2822.  The 
details of how and why people will adopt MARID I think suggest strongly 
that we not go down that road.
--
Matthew