Re: CSV, NBB

On 6/20/04 2:47 PM, Roy Badami sent forth electrons to convey:

> If I implement NBB on *my* MTAs, it does nothing to make *my* life
> better, but I make a very small step towards making *everyone else's*
> life better.  Once when enough people do likewise, my like gets a lot
> better.
>  
Not true.  If recipients of x %, e.g. 90% of the mail out there 
implement NBB, then as soon as you publish MARID records for your 
domain, you'll get around x %, e.g. 90% fewer joe jobs. 

Meng's latest SPF plan (in which he has borrowed my idea of CSV 
semantics using SPF records) makes it much easier to implement SPF than 
the plan in the current RFC draft.  Implementation of SPF by nearly all 
legit senders will be much more feasible soon. Yay! 

Anyway, if SPF  doesn't advocate NBB, then at least in the case of 
post-SMTP SPF implementations, the SPF-Received header will show a fail, 
and the would-be joe job victim can potentially detect and take that 
into account when deciding the disposition of the resulting bounce.  But 
in the (hopefully more common) case of SMTP+SPF receivers, there may not 
be a way to tell that the bounce was the result of an SPF "fail".  
Perhaps that can be remedied, e.g. a via a fixed (grep-able) string 
included in all exp replies.  

BTW, you are not accurate when you say SPF 'endorses' SMTP rejection.  
The spec says "An SPF email system MAY choose to reject or discard email 
on the
  basis of local policy." It also says "MTAs MAY reject the message 
using a permanent
    failure reply code.  (Code 550 is RECOMMENDED. ...)"  That's MAY, 
not SHOULD or MUST.
I would be interested to hear what others think - should SMTP+SPF 
receivers reject or discard messages that SPF "fail" (e.g. hit -all, not 
"error" or "unknown")?  (Perhaps it makes sense to reject for a while by 
default and then sunrise discard as the default.)