Subject: [ietf-dkim] DKIM and VBR tester available

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Oct 2006 17:21:57 -0700

Greetings again. The Domain Assurance Concil has created a test 
server that will send out messages for people to use when testing 
their DKIM and VBR message receivers. The system requires a login to 
prevent spam or mail-bombing. The messages also include VBR-Info 
headers (<http://www.domain-assurance.org/protocol-overview.phtml>) 
that will resolve, for those of you wanting to test the VBR protocol.

If you are interested, please contact me directly for an account. The 
service is free to anyone, not just DAC members.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 10 Oct 2006 21:39:16 -0400

Wonderful!

2 plus years hammering out IETF public standard specs for DKIM and we
now we get proprietary non-standard non-IETF workgroup half baked ideas?

Why didn't you atleast write an IETF draft? and try to get a working
group going?  Come on.  Waste people's time with this stuff.  Who says
this VBR thing works?  You?  Where is the Threat Analysis and
engineering behind it?

What? Are you know telling receivers?

    DKIM SANS VBR -->  NO TRUST
    DKIM WITH VBR -->  TRUST?

Does that give us permission now to DUMP SANS VBR messages?

What makes you think it isn't going get abused in the same way (NO VBR
headers)?  Oh, you only care about the GOOD NEEDLE in the haystack?

Whats makes you think its not the same issues related to SSP? This is
the same thing, its just not SSP - but VBR!!   Same thing!

---
HLS

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Oct 2006 02:17:09 -0700

On Tue, 2006-10-10 at 21:39 -0400, Hector Santos wrote:
> Why didn't you at least write an IETF draft? and try to get a working

There is still work required.  There is no simple way to differentiate
replay abuse caused by a competitor from abuse caused by the domain
being vouched.  That is unless the signing domain can be associated with
the SMTP Client.  The DOSP draft provides an approach that helps solve
that issue.

Those attempting to vouch for a domain will need to establish procedures
and requirements.  The requirements will likely mean this approach is
limited to bulk senders where SMTP Client association does not represent
a significant problem.

While VBR states that this scheme does not affect Sender-ID, the reverse
is not true.  Sender-ID represents a very serious threat to DNS, and
MUST NOT be used to associate a signing domain with that of the SMTP
Client.

When trust is established by the recipient, rather than by some vouching
service, there is still a need to understand which messages should be
trusted based upon just the domain, and which email-addresses are valid.
Again DOSP helps solve those issues as well, along with allowing the
designation of signing domains.  Designation does not alter how VBR
works, as VBR is based upon the signing domains.  Designated sub-domains
can be established for individual customers or types of use.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2006 15:10:59 +0100

Hector,

> now we get proprietary non-standard non-IETF workgroup half baked ideas?

I don't see anything wrong with Paul mentioning this (whatever it is) in
tandem with something useful to the WG.

If he started to bombard us with details then you'd have a point,
Stephen.