Mike Wolf | 4 Jan 01:21
Picon

intro to IAR group from Mike Wolf

Hi,

I just joined the IAR subgroup.

I work for PeerConnect, a small company specializing in developing
applications for the Electronic Postmark in the email space.

I am interested in building reputation systems that can "embrace and extend"
the work done by the DKIM group and come up with draft standards for
reputation systems.
I also participated in the work done by the Universal Postal Union to create
an XML standard for the Electronic Postmark itself, back when I worked for
AuthentiDate, which operates the Electronic Postmark service for the USPS.
The EPM standard is really a non-repudiation web service protocol that
builds on digital signatures and time stamps and positions the post as a
trusted third party.

One of my goals is to get the posts involved in email authentication,
possibly by acting as a reputation / accreditation authority.

I am curious who else is in this group and what their goals are - who else
is active on this group?

Regards,

Mike Wolf

CTO

PeerConnect, Inc.
(Continue reading)

John R Levine | 6 Jan 05:33

Some projects for IAR

I'm pleasantly surprised to see signs of life on the IAR list.  In the
next few messages I'll send out some suggestions about projects upon which
people might want to work.

-- reputation semantics

-- reputation lookup conventions

Regards,
John Levine, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

John Levine | 6 Jan 06:21

Reputation semantics

Over in DKIM land everyone's been saying that DKIM will eventually
be lashed up to reputation systems.  That's fine, but what does that
mean.

A reputation system will look something up.  The input is a domain
name, or maybe an e-mail address or an IP address.  The output is,
well, what?  A single bit saying yes or no (like the typical use of a
DNSBL?)  A score?  Multiple scores?  A little essay or the merits and
flaws of the reputee?

I don't know what the answer is, but it seems hard to start to build
these things if we don't even know what the inputs and outputs are.

Perhaps a reasonable way to start would be to survey what existing
systems like the various DNSBLs and SIQ do.

R's,
John

John Levine | 6 Jan 06:28

Reputation lookup conventions

One of the things that has made DNSBLs so successful is that there is
a consistent interface to all of them.  That means if you use one and
decide you don't like it, switching to another involves only a change
to a config file, not code changes to your MTA.

What should the interface to a reputation system look like?  SIQ is OK
but it seems kind of special case, and its UDP round trip isn't
fundamentally any cheaper than a DNS round trip.

We all know how to use a DNSBL to map an IP address into either a
number (an A record) or a string (a TXT record) or both.  It's
straightforward to do the same thing with domain names as an rhsbl,
again returning a number or a string.  Is that adequate?  Are there
implementation problems?  (The abuse.net domain lookup makes every
name a wildcard that covers subdomains, easy enough to do with my
special purpose server, probably OK in BIND-ese at the cost of
doubling the size of the zone.)

If we're willing to make the leap to TCP, the obvious way to do a
lookup is HTTP, e.g. if the service is called virtuousness.org and
you want to look up its opnion about sleazy.biz, do an HTTP lookup
on http://virtuous.org/sleazy.biz and you get back the usual HTTP
MIME package.  Seems like overkill to me but who knows, it might be
what you need to get the documentation behind the DNS encoded summary.

R's,
John

Petru Paler | 6 Jan 09:33

Re: Reputation lookup conventions

On 6 Jan 2006 05:28:13 -0000, "John Levine" <johnl <at> taugh.com> said:
> What should the interface to a reputation system look like?  SIQ is OK
> but it seems kind of special case,

I'm not sure I understand what you mean by "special case" :)

> and its UDP round trip isn't fundamentally any cheaper than a DNS
> round trip.

We tried using DNS before we made another protocol, but gave up
realizing that we'll need a lot of hacks to shoehorn a domain+IP pair
into a DNS request.

> If we're willing to make the leap to TCP, the obvious way to do a
> lookup is HTTP, e.g. if the service is called virtuousness.org and you
> want to look up its opnion about sleazy.biz, do an HTTP lookup on
> http://virtuous.org/sleazy.biz and you get back the usual HTTP MIME
> package.

Well, SIQ already has a HTTP query method, useful if you can't fit the
data in an UDP packet, are worried about spoofing, or want to do
authentication of clients (HTTP Auth) and/or secure transmission
(SSL/TLS).

We are looking for feedback on the SIQ protocol, so if you see any
way in which it could be made better, we're very interested to
hear about it.

Petru

(Continue reading)

Anthony Howe | 6 Jan 11:10
Gravatar

SIQ feedback for I-D 03 (was Re: Reputation lookup conventions)

Petru Paler wrote:
> We are looking for feedback on the SIQ protocol, so if you see any
> way in which it could be made better, we're very interested to
> hear about it.

Current I-D:
http://www.ietf.org/internet-drafts/draft-irtf-asrg-iar-howe-siq-02.txt

I'm in the process of preparing SIQ Internet-Draft 03. I suggest the 
discussion of semantics and conventions remain separate threads for the 
moment from discussions about SIQ itself. I can always merge the outcome 
of those discussions into a future SIQ revision.

--

-- 
Anthony C Howe                                 +33 6 11 89 73 78
http://www.snert.com/       ICQ: 7116561         AIM: Sir Wumpus

Sendmail Anti-Spam Solutions           http://www.snertsoft.com/
                                             We Serve Your Server

Anthony Howe | 6 Jan 11:02
Gravatar

Re: Reputation semantics

John Levine wrote:
> Over in DKIM land everyone's been saying that DKIM will eventually
> be lashed up to reputation systems.  That's fine, but what does that
> mean.
> 
> A reputation system will look something up.  The input is a domain
> name, or maybe an e-mail address or an IP address.  The output is,
> well, what?  A single bit saying yes or no (like the typical use of a
> DNSBL?)  A score?  Multiple scores?  A little essay or the merits and
> flaws of the reputee?
> 
> I don't know what the answer is, but it seems hard to start to build
> these things if we don't even know what the inputs and outputs are.
> 
> Perhaps a reasonable way to start would be to survey what existing
> systems like the various DNSBLs and SIQ do.

For those who do not know about SIQ, the I-D can be found here:

http://www.ietf.org/internet-drafts/draft-irtf-asrg-iar-howe-siq-02.txt

--

-- 
Anthony C Howe                                 +33 6 11 89 73 78
http://www.snert.com/       ICQ: 7116561         AIM: Sir Wumpus

Sendmail Anti-Spam Solutions           http://www.snertsoft.com/
                                             We Serve Your Server

April Lorenzen | 6 Jan 14:56

Re: Reputation semantics

John Levine wrote:
> A reputation system will look something up.  The input is a domain
> name, or maybe an e-mail address or an IP address.  
Input that includes any full email addresses would I think be a serious 
privacy issue and should be avoided in a query to a non-local reputation 
service. Although individual email addresses such as hotmail addresses 
used to send 419 spam could be put into a reputation server, I suggest 
that existing full address blacklist methods that do local look ups / 
updated from remote sources are more efficient and less of a privacy issue.

> The output is,
> well, what?  A single bit saying yes or no (like the typical use of a
> DNSBL?)  A score?  Multiple scores?  A little essay or the merits and
> flaws of the reputee?
>   
In creating the original (pre-Internet-Draft) SIQ protocol, Petru Paler 
pointed out to me that there are only a few possible actions that a mail 
server can take regarding a message, such as accept, reject or tempfail. 
To each of these you could add "and do some other processing" or "don't 
do any other processing." In practical application we "accept and tag 
PASS" or "accept and tag FAIL", which meant inserting a header that can 
be read by later sorting to a bulk folder or further local processing. 
At least one other case was needed: ERROR. What to do in case no 
response is received from the reputation server, or a malformed response 
is received.

So the original design was "dumb very lightweight query client", where 
resource intensive decisions were made in the reputation server, and the 
inbound mail server clients need not be disturbed (put at risk/ consume 
sysadmin resources with updates). As Petru suggested, the email 
(Continue reading)

Dave Crocker | 6 Jan 18:11

Re: Reputation semantics

Folks,

In discussing semantics -- and, therefore, the basic nature of particular 
reputation services -- I find it helpful to copy the model used in the credit 
industry.

When you buy something at a retail store and write a check or use a credit card, 
the verification event is an "approval" query.  The service that is queried says 
yes or no.

When you buy a house, the loan organization does a query that produces a great 
deal of detailed information about your credit-related behavior.

So the difference between "approval" and "report" suggests the different goals 
of the querying client.  For approvals, the client is lightweight.  For reports, 
the client is heavier-weight and wants to do its own analysis.

I had originally assumed that this distinction was essential for mail assessment 
services, but it was pointed out to me that most receiving smtp servers that do 
queries are already performing complex analyses.  Hence, their queries are for 
reports, not approvals.

That makes it worth asking for substantiation that a lightweight client query 
service really is needed.

d/

--

-- 

Dave Crocker
(Continue reading)

Dave Crocker | 6 Jan 18:13

Re: Reputation lookup conventions

> What should the interface to a reputation system look like?  SIQ is OK
> but it seems kind of special case, and its UDP round trip isn't
> fundamentally any cheaper than a DNS round trip.

an exemplar for assessment queries is at:

   <http://mipassoc.org/csv/draft-ietf-marid-csv-dna-02.html>

d/

--

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>


Gmane