Subject: Re: [Fwd: Last Call: draft-hoffman-dac-vbr (Vouch By Reference) to Proposed Standard]

From: "J.D. Falk" <[email-masked]>
Date: Mon, 09 Feb 2009 13:16:54 -0700

Dave CROCKER wrote:

> This is being sent long-after the deadline for comments about Vouch by
> Reference (VBR), but several Discuss votes have been lodged and I am
> hoping this note provides input useful for resolving them.

Looks like I'm even later to the party, but I see the discussion was still 
going on as recently as a few days ago, so hopefully there's still time to 
be helpful.

My employer, Return Path, operates one of those potentially "evil" vouching 
services -- currently only by IP address, but we have plans in motion to 
certify entities by domain name as well.

http://www.returnpath.net/internetserviceprovider/certifiedwhitelist/

Obviously, this can only work with the full cooperation and participation of 
the operators of the mail servers which query our accreditation services. 
These operators choose to give some form of preferential treatment to 
messages from entities we've certified -- and in exchange, we strive to 
never certify any entity which might abuse that trust.  If we fail in this, 
the operators will stop using our service.

Operators also accept mail from non-accredited sources, just as they always 
have.  I'm not aware of any operator who has chosen to only accept mail from 
accredited sources, and reject the rest.  Email is still default-accept, not 
default-deny.  VBR isn't changing that, and neither are any of the 
certifiers currently in the market.

Reading through the archives, it quickly becomes clear that the arguments 
against accepting draft-hoffman-dac-vbr are actually arguments against 
potential bad decisions on the part of mail system operators.  They're 
arguments against a big ISP like AOL switching to default-deny, cutting out 
any sender whom nobody will vouch for.  But nobody's talking about actually 
doing that -- certainly not in the VBR draft.

Having a published, open standard makes it easier for operators to use 
multiple vouching services, or to switch between them.  If one starts doing 
evil things, an operator can easily switch to a competing service, or none 
at all.  This all becomes much more difficult with a proprietary system.

However, if your intent is to prevent operators from processing inbound mail 
in any way they deem appropriate...that's a political issue, and blocking 
this draft won't make any difference.

Also, frankly, blocking this draft won't make any difference to whether 
certification or other forms of vouching are used in mail systems.  There's 
a clear need, on the part of both receive-side operators and sending-side 
operators.  Thus, there are services responding to that need.

But it'd be way better for everyone if we all followed the same technical 
standard.  We already (for the most part) follow the same best practices, 
even though those aren't codified anywhere yet.

I hope this additional perspective helps with any decisions left to be made.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 10 Feb 2009 10:16:04 +0100

J.D. Falk wrote:
> Dave CROCKER wrote: [...]

> Reading through the archives, it quickly becomes clear that the 
> arguments against accepting draft-hoffman-dac-vbr are actually arguments 
> against potential bad decisions on the part of mail system operators.  
> They're arguments against a big ISP like AOL switching to default-deny, 
> cutting out any sender whom nobody will vouch for.  But nobody's talking 
> about actually doing that -- certainly not in the VBR draft.

Eh? I possibly missed them, or maybe they were on the iesg list that 
I'm currently missing, but I don't recall arguments _against_ 
accepting that draft. I've re-read that Dave's message,you quoted, and 
it doesn't look against VBR at all. Of course, some details could be 
bettered, but the "Last Call" in the subject apparently invites to 
just take it or leave it. (I'd vote the former, but then I've heard 
all and everything about voting mechanisms today, when your message 
was the only one not about TLS...)

One of the weaknesses of that default-accept is that it forces 
operators to apply content-filtering to most emails. As it is well 
known, content filters don't understand the content they filter. The 
best way to concisely describe them is to say that they may randomly 
delete or modify a message, unless it's whitelisted. Non-whitelisted 
messages are vexed and ground down so as to reduce that acceptance to 
an obscure fuzzy result, putting reliability at stake. The difference 
vs. rejecting, is that the sender thinks it sent the message all 
right. Therefore, IMHO, default-deny is preferable. It works for 
non-relay, SPF fail, some DNSBLs, and other non-fuzzy methods. And VBR 
is non-fuzzy.

As VBR lives in a header, it may seem that filtering on it is some 
kind of content filtering. Actually, that's another one of the details 
that could be possibly bettered: 1) it is not clear what sense can 
have to examine a VBR-Info header ofter some months, and 2) knowing 
beforehand that the message is not whitelisted may let the sender 
decide to use an alternative MSA. The latter (2) could be obtained by 
a suitable SMTP extension, that I exemplified in 
http://www.ietf.org/mail-archive/web/ietf/current/msg55222.html