Re: CSV, NBB

Dave, John, Doug:
Have you considered and rejected or not considered adding the NBB idea 
that I threw out a while back to the CSV spec? 

For convenience:

The NBB idea is:
Take CSV, and add 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, let's be up front. Fundamentally 
it breaks (for a very small subset, as I'll show!) what I think is an 
oft-broken requirement: no mail be destroyed (or it could specify that 
such mail goes to postmaster, like double-bounces, 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.