ietf
[Top] [All Lists]

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

2009-02-10 10:41:18
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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>