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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]