Subject: [Asrg] Accreditation Mechanism Proposal

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 17 Mar 2004 07:23:32 -0800

All,

	A proposal for an accreditation mechanism is attached. This proposal
is based on the earlier RBL scheme proposed by Vixie, and designed to be
compatible with CallerID. I will submit as an ID later on today.

	Basically the scheme returns an A record in response to a lookup. So
in order for example.com to announce that it is accredited by the class3
service of verisign the SPF or CallerID record would contain the tripple:

	"accreditation" "class3.verisign.com""DNS-A"

	I.e. this is an accreditation property, the accreditor service is at
class3.verisign.com, the protocol is a DNS A record lookup.

	We can conflate the "accreditation" and "DNS-A" components, but that
is a bad idea, the A record convention is pretty limiting, there are only 24
bits worth of data that can be returned. It would be useful to be able to
extend to use of other protocol records such as NAPTR and SRV.

	Some folk inside VeriSign suggested that we use the convention that
an unlisted domain just returns domain does not exist. 

	I believe that we should have some facility here for a description
of the accreditation service. This is because the receiver has to arrive at
an evaluation of the accreditation service before the information can
converge. The ability to use learning systems is very attractive here.
Telling the learning system basic information about the format of the data
is pretty useful, what is the basis that the info was collected on, is the
data bit field formatted or in some other form?

	I provide the start of a description language here but on second
thoughts the best approach here would be to write the data structure in XML,
stick it up on a web site and put the URL in the DNS. The format is not a
big priority for me at the moment since it only really affects the
accreditation services and the filter writers. I don't think that either
community will be particularly large (10 to 20 at most). It is not something
we need to make a priority when we are using our limited standards track
bandwidth.

			Phill

---

From: "joe" <[email-masked]>
Date: Wed, 17 Mar 2004 13:44:36 -0500

All,

While CallerID sounds like a simple solution, it may in fact cripple
popular anti-spam measures such as third party disposable email address
provider.
A sender will not be able to use a disposable email address as his or
her sender's address if the domain of the disposable forwarding server
is different from the SMTP server used for sending out the mail.

No wander, larger ISP support such a draft which cripples competition.

Joe Kern

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 18 Mar 2004 11:37:51 -0500

> an unlisted domain just returns domain does not exist. 

You mean when querying the accreditation service?
How would this interact with Verisign's publishing of wildcard
records (e.g. if the accreditation service goes out of business and
its domain name is revoked)? 

This goal of indirect identification of accreditation services seems
like a positive thing.  Has there been any attempt to analyze the
additional overhead?

Also, as with SPF et al there is the question of feedback from the
recipient: e.g. one might want to have the ability for the recipient
to publish information about what that recipient requires of a
sender.  Some unified scheme might be useful, like:

    ( Sender domain must publish SPF OR DMP
    AND Sender must be accredited by any two of {abc, def, ghi, xyz}
    AND Sender IP must publish MTAMark)
    OR  ( Sender must accept address verification probe )

but that's probably a whole nother effort.

A couple of random remarks from a very cursory reading:

>           There is no difficulty in ensuring that accreditation providers are 
>           accountable to email recipients. An accreditation authority that 
>           provides incorrect accreditation will soon be ignored.

Pretty bold assertion :-)
It hasn't held true with some DNSBL services.  Among other reasons is
the wide variety of definitions of "incorrect," as well as extremely
polar opinions about listing criteria, remedies, responsibility, et al.

>        1.3 Practices Considerations 
> 
>           As a trusted third party the actions of an Accreditation Authority 
>           are raise numerous legal issues.

syntax problem there.

>        3.2 Sender Recipient A Record 
  ...
>              
>             Bits 4-7 
>               These bits are reserved. Relying parties MUST ignore 

Red flag:  better would be "these bits are reserved and must be set
to zero."  If you don't guarantee they are zero from the outset,
it's hard to make sure you can use them in the future.

>        3.3 Other Sender Recipient Records 
>            
>           Additional information MAY be provided by means of other DNS 
>           records, for example TXT or NAPTR records.

Do you really anticipate using NAPTR?

mm

---

From: "Mark E. Mallett" <[email-masked]>
Date: Thu, 18 Mar 2004 13:29:28 -0500

On Thu, Mar 18, 2004 at 12:55:14PM -0500, Yakov Shafranovich wrote:
> Mark E. Mallett wrote:
> >>         There is no difficulty in ensuring that accreditation providers 
> >>         are accountable to email recipients. An accreditation authority 
> >>         that provides incorrect accreditation will soon be ignored.
> >
> The key difference from blacklists is that blacklists do not ask ISPs 
> whether they want to be listed. Here, the sender actively goes to a 
> provider and signs up, and then indicates his accredidation in some 
> protocol.

I don't think that's really a difference, at least not in all cases.
There will be "market forces" in play where (assuming the accreditation
system works) once enough recipients use a paricular set of
accreditors, there will be pressure for senders to be listed in at
least one of them.

Besides, the statement was about the services being accountable to the
recipients, not to the senders.  That's quite analogous to DNSBLs
being accountable to their users.  That isn't a truism, at least not
in my opinion.  "Ethical consumerism" isn't likely to be present in
consumers of DNSBLs any more than it is in people looking for any
other goods and services (like choosing an ISP), not to mention that
the "ethics" involved (aka correctness) are widely disputed.  There
are tons of people using DNSBLs without any clue about how correct
those services are.  I'm not trying to make any deep statement here
though, just a comment on the prediction.

mm

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Mar 2004 12:55:14 -0500

My issue with this is something else - if all of this becomes prevalent 
enough, aren't we essentially raising a barrier of entry for new domains 
on the Internet? Doesn't such accredidation service essentially become a 
gatekeeper for the Internet?

Yes, I read Microsoft's proposals about different types of tricks for 
different domains, for example hash cash-type puzzles for smaller 
domains in lieu of accreditation. I am still not convinced that a given 
ISP will bother with supporting both accreditation and hash cash, they 
just might take the easy way out and only support accreditation services.

Yakov

---

From: Seth Breidbart <[email-masked]>
Date: Thu, 18 Mar 2004 15:00:18 -0500 (EST)

Yakov Shafranovich <[email-masked]> wrote:

> Yes, I read Microsoft's proposals about different types of tricks
> for different domains, for example hash cash-type puzzles for
> smaller domains in lieu of accreditation. I am still not convinced
> that a given ISP will bother with supporting both accreditation and
> hash cash, they just might take the easy way out and only support
> accreditation services.

So somebody will run an "accreditation" service that says "they
answered a hash-cash request for your message".  Yes, this requires
passing the Message-ID around to prevent a DoS attack, and probably
some other tricks; but there's nothing preventing it from happening.

Seth

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 18 Mar 2004 03:18:11 -0500

> compatible with CallerID. I will submit as an ID later on today.

Is the other consent proposal being submitted as well?

> we need to make a priority when we are using our limited standards track

There has been talk in at least four forums (ASRG, SMTP-VERIFY, MXCOMP 
and main IETF list) about trust, establishing trust between two parties 
and quering third party providers of information. The SMTP-VERIFY 
subgroup is also talking about exchanging information on neutral metrics 
like MTA volume via some protocol.

All of this brings question - can these ideas be somehow unified?

Yakov