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