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

[ned+ietf]

Apologies for the lateness of this comment. I only recently found the time to
review this draft.

Althogh I share Chris Newman's concerns about possible uses of this draft and
support the addition of the paragraph he recommends in his DISCUSS vote,  I
also believe the mechanism defined by this draft will provide very useful
functionality in a variety of circumstances and standardization is therefore
entirely appropriate.

My concerns with this draft revolve around the defined set of message types and
the mc field that's part of the vbr-info header field. Possible message type
values are "all", "list", or "transaction". The draft also states that the mc
value is self-asserted by the sender and is intended to be used for auditing
purposes.

My first issue with this is that I don't quite get how message type information
is supposed to be used during certification validity checking. If successful
the DNS lookup produces a list of message types the certifier is willing to
vouch for. But how is message supposed to be checked to see if it is of an
allowed type? The obvious thing to do is to see if the mc field value in the
message is on the list, and the example at the end of section 5 implies that
you're supposed to do such a check. It isn't stated explicitly as a
requirement, however.

If this check is supposed to be done, you're using the mc field as a label, not
simply for auditing purposes as the draft states. And if such a check isn't
performed, I'm not sure I see much point in having message type information as
part of this scheme.

My second issue with message types is the lack of any discussion about 
additional possible message type values. Is this initial set of three value are
that are  allowed now and forever? If so this seems a little shortsighted. If
not there needs to be more discussion of the extensibility model.

My third issue is while I see how the "all" value makes total sense in a DNS
entry, I don't see how it makes sense as an mc value. This also brings up the
issue of how you'd compare mc values to the DNS entries. I would think "all"
would act as a sort of wildcard and match any other value.

Finally, I note that we have already defined something similar to the message
type construct: RFC 3458's message-context. While the list of defined values of
the two typing mechanisms are quite distinct at present, as are the intended
purposes of the field (message-context is intended as an aid to message
processing) I could easily see an argument for a mc value of "fax" or "voice"
having validiity, and given how message-context is used in practice it would
make quite a bit of sense to define a list-message message context value that
would closely parallel the "list" mc value.

Again, given the differences in intended use of these fields there is not
necessarily any conflict between them. That said, it is not exactly unheard of
for "scope creep" to occur. If vbr-info becomes popular I can easily see
email-based applications using the mc value in exactly the way message-context
is currently used, irrespective of what the specifications say.  Such a usage
overlap could prove somewhat problematic given message-context's present use
for things like divvying up mailbox quotas between, say, voice mail and regular
email.

Mind you, I'm not going to go so far as to say the VBR mechanism should drop
the mc field and use message-context instead, but I think the potential
overlaps between these two typing mechanisms needs to at least be looked at.

Ned
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Alessandro Vesely]

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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[J.D. Falk]

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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[SM]

At 02:47 06-02-2009, John Levine wrote:

I'm not Dave, but I cannot imagine where you got the idea that he
expects the "community providing professional email operation" to
deploy 100% of anything.


I'll quote the last part of the message from Dave ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg55204.html ) 
about who will implement VBR and who will deploy it:


  "Anyone operating an outbound or inbound email border MTA is 
typically a candidate for using one or more assessment 
mechanisms.  As noted above, this is already 100% of the professional 
email operations market.  All of that market currently relies on IP 
Addresses for identification, but industry movement towards using 
domain names is progressing nicely.  Everyone who uses domain names 
for identification can be expected to need a mechanism like VBR.


Consequently, implementation is expected to be by all major 
developers of email sending and receiving software.  It is equally 
expected that it will be deployed by 100% of the community providing 
professional email operations, both on the sending and the receiving sides."



The idea that big mail systems will form a cartel and lock out people
who won't pay is just silly to anyone who remembers the history of
e-mail.  There used to be lots of closed commercial email systems,
including AOL, Compuserve, and MCI Mail where Dave worked.  Without
exception, they all were swept away by Internet mail which was cheap,
universal, and unmetered, even though in some ways it was technically
inferior to those systems.  Some of them, like AOL, morphed into ISPs,
others like MCI Mail just died.


I am not aware of any consortium of independent organizations 
providing mail services formed to limit competition or to lock out 
people who won't pay.  I did not equate the "community providing 
professional email operation" with big mail systems or infer that 
they will form a cartel.



Is there any possibility that you are confusing threats that are easy
to imagine with threats that are likely?  Because this one isn't likely.


The gist of my comments was about the impact of your proposed 
specification if the technology is widely deployed.  My opinion is 
based on operational experience and not on market theories.


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Alessandro Vesely]

John R. Levine wrote:
The other thing I don't understand is why you minimize the expected 
VBR effect. (If that's meant as an apotropaic stance, I have no 
objection. Otherwise,) I wonder why we shouldn't push VBR as hard as 
we can, if it can stop spam.


Could you point out where anyone, anywhere has claimed that VBR would 
"stop spam"?  It's a technology to whitelist mail from people you trust.


...I trust as not being spammers, you mean. Isn't that the same thing?

Self-referencing DNS based techniques are out there already, and have 
been criticized claiming that it is actually easier for spammers to 
comply than it is for legitimate users. Hence a third party is 
required. Reverse DNS and whois databases unfortunately are not apt. 
Ergo, VBR.


Dave CROCKER wrote:

What I don't understand is your certitude about specific impact.


It's not certitude, it's hope. OTOH, do we have anything better? 
(We're not allowed to use nuclear weapons, are we ;-))



Anyone who is certain of the second- and third- and fourth- order effects of 
adopting a particular protocol is ignoring the pattern of surprise that 
accompanies real-world developments for anything with a social component.

The reality of VBR is that it is almost entirely subject to social forces. 


Strongly agreed! It will only work if all the people will like it, and 
agree on a restricted set of vouch-for operators, and use it. Likely?


--
Imagine all the people
Sharing all the world
You may say I'm a dreamer
But I'm not the only one

John Lennon, 1971

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dave CROCKER]

Alessandro Vesely wrote:

John Levine wrote:
The other thing I don't understand is why you minimize the expected VBR 
effect. 



What I don't understand is your certitude about specific impact.

There is a considerable difference between having a large effect -- which is 
what any proponent of an IETF standard hopes for -- versus having a *particular* 
impact.


Anyone who is certain of the second- and third- and fourth- order effects of 
adopting a particular protocol is ignoring the pattern of surprise that 
accompanies real-world developments for anything with a social component.


The reality of VBR is that it is almost entirely subject to social forces.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John R. Levine]

The other thing I don't understand is why you minimize the expected VBR 
effect. (If that's meant as an apotropaic stance, I have no objection. 
Otherwise,) I wonder why we shouldn't push VBR as hard as we can, if it can 
stop spam.


Could you point out where anyone, anywhere has claimed that VBR would 
"stop spam"?  It's a technology to whitelist mail from people you trust.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Alessandro Vesely]

John Levine wrote:

If some group wanted to build a closed pay-to-play mail system, they
could do it with the tools they already have, using SMTP AUTH or
STARTTLS with a private signing cert or VPNs or whatever.  The reason
they don't is that it makes no sense, and a tiny tweak like VBR isn't
going to change that.


I didn't imply that any of the big 4 wants their users to pay for an 
email account. However, they are defining a mail system, which is 
possibly slightly different from the IETF definition, and flags spam 
abatement as a major advantage. Very roughly, that system is around 
one half of the total existing mailboxes[1]. That is to say, any one 
of the big 4 can expand its share better by acquiring users from minor 
MTAs than from direct competitors. This is not the same as a full 
blown cartel, but it tends to relegate minor MTAs to 2nd class.


The other thing I don't understand is why you minimize the expected 
VBR effect. (If that's meant as an apotropaic stance, I have no 
objection. Otherwise,) I wonder why we shouldn't push VBR as hard as 
we can, if it can stop spam.


Finally, I'd remark that, IMHO, such considerations are exactly what 
the IETF is for: not inventing mere rocket techniques, but do internet 
technology in its broadest meaning, including any economic, social, or 
political facet that may be relevant for the task.


--
[1]
Microsoft webmail properties: 256.2 million users
Yahoo: 254.6 million users
Google: 91.6 million users
AOL webmail properties: 48.9 million users
http://www.email-marketing-reports.com/metrics/email-statistics.htm

Internet users: 1,018,057,389 (2005)
https://www.cia.gov/library/publications/the-world-factbook/geos/xx.html#Comm

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dave CROCKER]

SM wrote:

At 06:55 04-02-2009, Dave CROCKER wrote:
Macroeconomic analysis -- especially predictions about the directions 
an economic process will develop towards -- is a poorly understood 
topic of expertise, even among experts... as we are unfortunately 
seeing demonstrated in the global economy.


One of the characteristics of Internet Mail is it doesn't require prior 
arrangement between senders and receivers.  If email certification is 
widespread, it can have an impact on the model.



Adding a small technical correction, since John L's response covers the rest:

"without prior arrangement" is a phrase that is used about most Internet 
protocols.  It refers to prior arrangement *between the two participants*.


All sorts of other arrangements are common, for using the Internet, such as 
getting an IP Address and a domain name.


Nothing about VBR encourages a change in being able to send mail between two 
parties without prior arrangement... between those two parties.


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John Levine]

>If the technology is deployed by 100% of the community providing 
>professional email operations, both on the sending and the receiving 
>sides, as Dave expects, ...

I'm not Dave, but I cannot imagine where you got the idea that he
expects the "community providing professional email operation" to
deploy 100% of anything.

The idea that big mail systems will form a cartel and lock out people
who won't pay is just silly to anyone who remembers the history of
e-mail.  There used to be lots of closed commercial email systems,
including AOL, Compuserve, and MCI Mail where Dave worked.  Without
exception, they all were swept away by Internet mail which was cheap,
universal, and unmetered, even though in some ways it was technically
inferior to those systems.  Some of them, like AOL, morphed into ISPs,
others like MCI Mail just died.

If some group wanted to build a closed pay-to-play mail system, they
could do it with the tools they already have, using SMTP AUTH or
STARTTLS with a private signing cert or VPNs or whatever.  The reason
they don't is that it makes no sense, and a tiny tweak like VBR isn't
going to change that.

Is there any possibility that you are confusing threats that are easy
to imagine with threats that are likely?  Because this one isn't likely.

R's,
John

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[SM]

At 06:23 04-02-2009, Alessandro Vesely wrote:
Also in more mature markets, not all of the existing companies and 
universities running their own mail servers will be eager to spend 
$5000/year on a vouch. In addition, the


The cost for email certification starts at around $1200 (950 Euros) a year.

At 06:55 04-02-2009, Dave CROCKER wrote:
Macroeconomic analysis -- especially predictions about the 
directions an economic process will develop towards -- is a poorly 
understood topic of expertise, even among experts... as we are 
unfortunately seeing demonstrated in the global economy.


One of the characteristics of Internet Mail is it doesn't require 
prior arrangement between senders and receivers.  If email 
certification is widespread, it can have an impact on the model.


What is the IETF track record that should give us any faith in this 
community's ability to make such predictions.  Absent that track 
record, we are creating the risk that we will refuse technologies erroneously.


That's where operational experience come into play.  It's easier to 
assess a technology based on that.  A specification sometimes contain 
guidance about the technology, for example, a note about trusting 
third parties with operational decisions.


If the technology is deployed by 100% of the community providing 
professional email operations, both on the sending and the receiving 
sides, as Dave expects, the rest of the world can either follow the 
practice or else bear the consequences.  As the IETF community does 
not have any track record on its ability to make economic 
predictions, should it restrict itself to a assessment of a 
technology without looking at whether the benefits outweigh the costs 
which may only affect a fringe of the Internet community?  The cost 
of deployment has been taken into consideration in the design of some 
specifications published on the Standards Track.


Regards,
-sm  


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John Levine]

>> What about senders from small emerging market countries having a very 
>> hard time getting any widely accepted assurance group to vouch for them?
>
>Also in more mature markets, not all of the existing companies and 
>universities running their own mail servers will be eager to spend 
>$5000/year on a vouch.

Sheesh.  The point of having a standard is to make it easy to
interoperate.  That means that anyone who wants to set up a VBR
vouching service can do so, and anyone who wants to use your vouching
service can also do so by adding a line to a config file.  I certainly
have no intention of paying anyone $5000 to get mail from my tiny
system delivered.

Like Dave, I don't see any reason to expect one economic model or
another to predominate, and no reason at all to expect there to be
only a small oligoply set of providers.  Although I think that VBR is
a swell idea, it also seems rather a stretch to expect that it would
ever become so popular that you couldn't get mail delivered without
it.

In the near term, the most likely usage I see is for phish resistance.
If organizations like the FDIC were to publish a VBR list of the
domains of their genuine member banks, that would make it easier to
have a mail system put a flag on suitable signed incoming mail to say
"this is really from a bank."

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dave CROCKER]

SM wrote:

At 11:40 01-02-2009, Dave CROCKER wrote:
 1.  Macroeconomic effect from email filtering:  Monopolistic 
pressures


There wasn't any comments on the Last-Call about the implications to 
individual or small companies, particularly ones in small emerging 
market countries.  It's refreshing to see such a question being brought 
up during an IESG evaluation.



Good that we care?  Sure.  Good that we base formal approval on it?  Maybe not.

Macroeconomic analysis -- especially predictions about the directions an 
economic process will develop towards -- is a poorly understood topic of 
expertise, even among experts... as we are unfortunately seeing demonstrated in 
the global economy.


What is the IETF track record that should give us any faith in this community's 
ability to make such predictions.  Absent that track record, we are creating the 
risk that we will refuse technologies erroneously.


The IETF defines technologies, not markets.

d/

---

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Alessandro Vesely]

SM wrote:
What about senders from small emerging market countries having a very 
hard time getting any widely accepted assurance group to vouch for them?


Also in more mature markets, not all of the existing companies and 
universities running their own mail servers will be eager to spend 
$5000/year on a vouch. In addition, the semantics of vouching is even 
less specified than mc types. What kind of checks would a vouch-for 
service operator carry out? I hope it will not be something similar to 
getting a server TLS certificate... Will organizations like, say, 
spamhaus.org issue _vouch records for free?


Dave CROCKER wrote:

Modern email receiving software includes a Handling Filter module that juggles 
a potentially rich array of assessments and attributes, associated with the 
message, before deciding whether to deliver it.


While that describes current practices correctly, it is at odds with 
the concept of reliable mail transmission that the SMTP model (5321) 
describes. In facts, mail sent to (some) giant ESPs may pass unnoticed 
through recipients' mailboxes, if the sender didn't take care to 
ensure deliverability by some obscure ESP-specific procedure. VBR 
makes that behavior explicit. However, it provides no means to find 
out which vouch-for operators a given recipient trusts, except by 
manually searching in a giant ESP's web site for policies or 
statements referring that.


The "obvious solution" for those 2nd class senders is to use one of 
the giant ESPs as a submission agent, so as to delegate the handling 
of outgoing email to a transmitter with plenty of clout. This 
distinction between 1st class senders and smaller MTAs might remind 
the ADMD/PRMD classification. We may be better off providing a 
protocol method for verifying in advance what is going to happen with 
a given message. For example,


  C:  VHLO example.com VBR:mv=operator1:operator2:operator3
  S:  551 we only accept VBR:mv=operatorA:operatorB:operatorC

  lets the client know that its mail is not going to be delivered in 
the recipient's primary folder. That way, a client can be configured 
to attempt regular MX delivery first, and resort to its preferred 
giant MSA only if necessary. (Who'd write such extension? Please, send 
any specific follow-up to a more specific list.)

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[SM]

At 11:40 01-02-2009, Dave CROCKER wrote:
Based on the Discusses that have been lodged (including those 
resolved) concerns focus on:



 1.  Macroeconomic effect from email filtering:  Monopolistic pressures


There wasn't any comments on the Last-Call about the implications to 
individual or small companies, particularly ones in small emerging 
market countries.  It's refreshing to see such a question being 
brought up during an IESG evaluation.


Does the IETF community believe that the following text (see IESG 
Evaluation) is appropriate:


 "If a recipient selects one or more vouch-for domains, and uses the
  results of vouching to adjust spam scores on incoming email, that
  recipient is placing a great deal of operational trust and power
  in the selected vouch-for service operators.  Recipients are strongly
  encouraged to select such services with care.  Further, recipients
  are strongly encouraged to select more than one vouch-for service to
  avoid a single-point-of-failure and to avoid placing excessive trust
  and power in a single vouch-for service operator."
What about senders from small emerging market countries having a very 
hard time getting any widely accepted assurance group to vouch for them?


Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Dave CROCKER]

The IESG has received a request from an individual submitter to consider
the following document:

- 'Vouch By Reference'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2





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.




Background
--

As Internet mail has been subjected to increasing abuse, services have developed 
to assist email receiving operators in determining how likely it is that a given 
piece of email is safe to deliver.  One type of service evaluates content and 
makes heuristic assessments.  Another type uses a validated identifier that is 
associated with the message and assesses the owner of that identifier.  Modern 
email receiving software includes a Handling Filter module that juggles a 
potentially rich array of assessments and attributes, associated with the 
message, before deciding whether to deliver it.


Historically, the only validated identifier that was available was the IP 
Address of the last-hop sending SMTP engine. Although quite useful for this, an 
IP Address has a number of limitations for this application, particularly by 
virtue of being tied to network topology, rather than organizational boundaries. 
 To align better with the attributes of an organization, rather than the 
attributes of a network, domain names are generally considered a superior 
choice.  Hence there has been a range of efforts to associate a validated domain 
name with email, including SPF, Sender-ID, DomainKeys and the recent IETF 
Proposed Standard DKIM.


No matter how the domain name is obtained, its utility is not in the fact of 
being validated, but in serving as a basis for making an assessment of its owner.


As part of the DKIM working group, a Deployment document is under development 
and I've suggested it include the following diagram, primarily derived from a 
conversation with Mike Adkins, of AOL, when he noted that the module that comes 
after verification is the real target of DKIM.


We are finding that it greatly clarifies the systems view of the role of a 
validated identifier:


  +--+--++--+--+
  |   Author||  Recipient  |
  +--+--++--+--+
 |  ^
 |  |
 |   +--+--+
 |-->|  Handling   |<--
 |-->|   Filter|<--
 |   +-+
 |  ^
 V  |
  +-+  Responsible Identifier+--+--+
  | Responsible |...>|  Identity   |
  |  Identity   ||  Assessor   |
  +--+--++-+
 | ^ ^
 VDKIM Service | | Query Service
+---+  | |
| +--+--+  +-+  |  | |  +-+
| | Identifier  |  |  Identifier +--|--+ +--+ Assessment  |
| |   Signer+->|  Validator  |  |   | Databases   |
| +-+  +-+  |   +-+
+---+

Although tailored for DKIM, the gist of this diagram is independent of the means 
by which the domain name is obtained and verified.


At base it notes that the goal is for the owner of a domain name to have the 
name used by a receive-side assessment module, such as for determining the 
reputation the owner has as a Good Actor.


Once the use of such a domain name that is has been validated, there needs to be 
some means of using it to assess its owner. This tasked is marked as "Query 
Service" in the diagram.


This is the need that Vouch by Reference (VBR) satisfies.

Since a validated domain name is useless without the assessment step, 
standardizing a mechanism for querying assessment information is a natural and 
necessary activity, in developing common Internet capabilities for 
distinguishing legitimate email from abusive email.




VBR History
---

VBR was developed by an ad hoc industry consortium, primarily comprising 
independent services offering reputation analysis of email senders.  That is, 
competitors collaborated to define a common mechanism.  Seven companies formed 
the core, with assistance from a few more. See:


   

The specifica

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

[marc]

I support this draft on the standards track.

We look forward to companies starting to use it and already have
implementations for it.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-04.txt


hi,

seems to be a broken link , just found this one:

http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-05.txt

regards

Marc

--
Les Enfants Terribles - WWW.LET.DE
Marc Manthey 50672 Köln - Germany
Hildeboldplatz 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: m...@let.de
jabber :m...@kgraff.net
IRC: #opencu  freenode.net
PGP/GnuPG: 0x1ac02f3296b12b4d
twitter: http://twitter.com/macbroadcast
web: http://www.let.de

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).


Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Tony Hansen]

I support this draft on the standards track.

We look forward to companies starting to use it and already have
implementations for it.

Tony Hansen
t...@att.com

The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Vouch By Reference'
> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2008-11-24. Exceptionally, 
> comments may be sent to i...@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-hoffman-dac-vbr-04.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15717&rfc_flag=0
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[SM]

Hi John,
At 09:13 07-11-2008, John Levine wrote:

I think you're talking past each other here.  I read SM's message
as adding VBR-Info: to the list of known mail header lines here:

http://www.iana.org/assignments/message-headers/perm-headers.html


Thanks, that's what I meant.

Regards,
-sm 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

At 5:13 PM + 11/7/08, John Levine wrote:
> >>The IANA Considerations section is missing.  I suggest registering
>  the header as specified in RFC 3864.
>>
>>We purposely did not make this extensible in this document.
>
>I think you're talking past each other here.  I read SM's message
>as adding VBR-Info: to the list of known mail header lines here:
>
>http://www.iana.org/assignments/message-headers/perm-headers.html
>

 That's right, I misread SM's message. We'll include this in the next 
draft. Oh, and also fix the misspelling he found.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[John Levine]

>>The IANA Considerations section is missing.  I suggest registering
  the header as specified in RFC 3864.
>
>We purposely did not make this extensible in this document.

I think you're talking past each other here.  I read SM's message
as adding VBR-Info: to the list of known mail header lines here:

http://www.iana.org/assignments/message-headers/perm-headers.html

That seems reasonable.  I agree (having talked to the same companies)
that there is no point in making the header itself extensible at this
point.

R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[Paul Hoffman]

At 10:35 PM -0800 11/6/08, SM wrote:
>The IANA Considerations section is missing.  I suggest registering the header 
>as specified in RFC 3864.

We purposely did not make this extensible in this document. From talking to 
many of the companies that would be certifiers, there was no interest in making 
the list extensible. One option is to litter the IANA web site with yet another 
registry that lists the values from the RFC that created the registry and 
nothing else, as is all too common. Instead, we thought it was better to leave 
out the registry; if someone has a good reason for adding a new value, they can 
write an RFC for it and create the registry at that time.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

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

[SM]

At 14:17 27-10-2008, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:

- 'Vouch By Reference'
as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the


In Section 5:

  "Verifiers MUST check that the TXT record conists of strings of"

That should be "consists".

The IANA Considerations section is missing.  I suggest registering 
the header as specified in RFC 3864.



IANA Considerations

   IANA is requested to register the VBR-Info header field in the Message
   Header Fields Registry ([RFC3864]) as follows:


Header field name:
 VBR-Info

  Applicable protocol:
 mail (RFC 5822)

  Status:
 standard

  Author/Change controller:
 IETF

  Specification document(s):
  (Note to RFC Editor: the RFC number of this document if approved)

  Related information:
 none

Regards,
-sm


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf