Subject: [domainrep] DKIM 101 for me (was Re: I-D.*-reputation-*.01 (was: A document about reputation data meta-issues))

From: Nathaniel Borenstein <[email-masked]>
Date: Wed, 9 Nov 2011 12:26:13 -0500

On Oct 31, 2011, at 12:32 PM, John R. Levine wrote:

>> If DKIM authentication says a message came from x@y, ...
> 
> Please report immediately for self-criticism and re-education.  DKIM
> doesn't do that.

Ouch. s/x//.  My intention was more like: "?@domain.example" -- I used x as a variable and y as a placeholder and I am an enemy of the people.)

Also I'm old, I sometimes confuse variable frames of reference, and I've typed "x@y" way too often in my life.   Enough self-criticism?  -- N

---

From: Douglas Otis <[email-masked]>
Date: Wed, 09 Nov 2011 15:16:54 -0800

On 11/9/11 9:26 AM, Nathaniel Borenstein wrote:
> Ouch. s/x//.  My intention was more like: "?@domain.example" -- I used 
> x as a variable and y as a placeholder and I am an enemy of the people.)
>
> Also I'm old, I sometimes confuse variable frames of reference, and 
> I've typed "x@y" way too often in my life.   Enough self-criticism?  -- N
Be more exacting about what a valid DKIM implies.  Don't use terminology 
like 'from' or 'sent'.   A valid signatures simply says d=domain signed 
a portion of a message.   It says nothing about who sent the message or 
to whom.  That difference matters when holding d=domain accountable for 
spam based upon valid signatures that have been reported or received in 
a spam trap.  This is because d=domain may not have actually sent the 
message to recipients that had no desire in receiving these messages.

-Doug

---

From: Nathaniel Borenstein <[email-masked]>
Date: Thu, 10 Nov 2011 08:26:05 -0500

I'll be more careful.  I didn't intend to resurrect my arguments about the meaning of "sent" on a list where people are trying to do real work.  Whenever people object to my usage and I don't object to theirs -- i.e. when the battle is long since lost -- it's obvious who should change.  -- Nathaniel

On Nov 9, 2011, at 6:16 PM, Douglas Otis wrote:

> Be more exacting about what a valid DKIM implies.  Don't use terminology like 'from' or 'sent'.   A valid signatures simply says d=domain signed a portion of a message.   It says nothing about who sent the message or to whom.  That difference matters when holding d=domain accountable for spam based upon valid signatures that have been reported or received in a spam trap.  This is because d=domain may not have actually sent the message to recipients that had no desire in receiving these messages.
> 
> -Doug
> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep

---

From: Douglas Otis <[email-masked]>
Date: Thu, 10 Nov 2011 10:55:17 -0800

> I'll be more careful.  I didn't intend to resurrect my arguments about the meaning of "sent" on a list where people are trying to do real work.  Whenever people object to my usage and I don't objec…
Nathaniel,

Agreed.  There appears to be optimism at establishing domain reputations 
based upon weak (if any) correlation with domain actions.

What recommendations should be made for handling challenges and 
repeating issues?

After all, when using DKIM as a basis, reports and spam trap data may 
not correlate with domain actions.  Lack of correlation may prove highly 
disruptive.

In such a case, who should change and how?

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 Nov 2011 02:54:36 +0100

On 10 November 2011 19:55, Douglas Otis wrote:

> After all, when using DKIM as a basis, reports and
> spam trap data may not correlate with domain
> actions.  Lack of correlation may prove highly
> disruptive.

A "reputation provider" using DKIM or SPF would look
for good signatures (DKIM) or PASS (SPF).  Some DKIM
signed or SPF passing mails will be spam, and other
mails with the same DKIM or SPF "identity" will be
ham.  That is enough to report a 0..1 value for this
"identity", e.g., 0 = no spam, 1 = only spam.  Add
number of observed mails and period of observation,
and that's it, in a nutshell.

Weak points are not enough observations for a given
"identity", or long observation periods stretching
back to the last time when the "identity" managed to
produce lots of observed spam.

-Frank

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 11 Nov 2011 22:28:11 +0100

> and that's it, in a nutshell.

What if the 'reputation provider' used DNSSEC successfully to retrieve 
the public key or the SPF TXT record, could that add to the confidence 
metric?

/rolf

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 11 Nov 2011 16:59:35 -0500

On Nov 10, 2011, at 1:55 PM, Douglas Otis wrote:

> What recommendations should be made for handling challenges and repeating issues?
> 
> After all, when using DKIM as a basis, reports and spam trap data may not correlate with domain actions.  Lack of correlation may prove highly disruptive.
> 

When using anything as a basis for identity, there will be failures and edge cases with the consequences you describe.  The next step, I think, is a framework that allows you to coherently combine multiple approaches to identity.  The best way to address recurring issues is to prevent them, and the best way to deal with the bad consequences of any one approach is to make sure it is intertwined with the others, so they can correct each other's mistakes.  

And I believe the REPUTE work is a prerequisite to doing that, which is why I'm here.  A successful protocol's worst flaws may never be fixed -- they're often design points -- but they can be mitigated by the things we build around them.  -- Nathaniel

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 11 Nov 2011 23:13:19 +0100

On 11 November 2011 22:28, Rolf E. Sonneveld wrote:

>> A "reputation provider" using DKIM or SPF would
>> look for good signatures (DKIM) or PASS (SPF).
>> Some DKIM signed or SPF passing mails will be
>> spam, and other mails with the same DKIM or SPF
>> "identity" will be ham.
[...]

> What if the 'reputation provider' used DNSSEC
> successfully to retrieve the public key or the SPF
> TXT record, could that add to the confidence
> metric?

Maybe I miss your point, but for the decision what
is or what is not a DKIM signature (or an SPF PASS)
you MUST retrieve the key (or evaluate the policy).

Obviously it makes no sense to attach some kind of
reputation to a DKIM or SPF "identity" if the mails
in question had no valid DKIM signature or SPF PASS.

In fact an SPF FAIL almost guarantees that the mail
is abuse by an unauthorized third party, and that's
useless for any kind of "SPF reputation".

-Frank

---

From: Chris Lewis <[email-masked]>
Date: Fri, 11 Nov 2011 18:01:03 -0500

> you MUST retrieve the key (or evaluate the policy).

If I understand the question, he's essentially asking if the reputation 
provider applies the SPF or DKIM check, or, perhaps, at least queries 
the SPF text record to find out whether, for example, it's an -all or 
~all.  The querier _already_ has had to do the SPF check itself to 
formulate the REPUTE query in the first place.

This gives the reputations server the opportunity to apply further 
heuristics to a domain that they don't necessarily know about, but it 
forces the provider to do more work.

It might be better to have the client simply supply that info.
One might consider looking at the queries differently - the querier 
sends the domain name PLUS a indication of what authentications have 
been performed, and how strong they were.  IOW: the querier provides a 
confidence parameter that contains things like 'DKIM pass', 'SPF -all 
pass', 'SPF ~all fail', 'No SPF record', 'No DKIM present', etc.

The latter may be more powerful, and give the reputation agency more 
room for heuristically based return values.

Yes, this potentially extends REPUTE to non-authenticated identities. 
Is this necessarily a bad thing?

> useless for any kind of "SPF reputation".

A SPF -all FAIL is rather different than an SPF ?all FAIL, so I think 
providers would want to factor that in.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 11 Nov 2011 15:26:45 -0800

On 11/10/11 5:54 PM, Frank Ellermann wrote:
> > After all, when using DKIM as a basis, reports and spam trap data
> > may not correlate with domain actions. Lack of correlation may
> > prove highly disruptive.
>
>  A "reputation provider" using DKIM or SPF would look for good
>  signatures (DKIM) or PASS (SPF). Some DKIM signed or SPF passing
>  mails will be spam, and other mails with the same DKIM or SPF
>  "identity" will be ham. That is enough to report a 0..1 value for
>  this "identity", e.g., 0 = no spam, 1 = only spam. Add number of
>  observed mails and period of observation, and that's it, in a
>  nutshell.
>
>  Weak points are not enough observations for a given "identity", or
>  long observation periods stretching back to the last time when the
>  "identity" managed to produce lots of observed spam.

Frank,

DKIM's "weakness" of not capturing actual sources or intended recipients 
can (and likely will) be heavily exploited.  At any time, some number of 
compromised systems will have access to DKIM signing MTAs.  Currently, 
most email acceptance is predicated upon being sourced from non-abusive 
IP addresses where TCP offers a weak form of source authentication.  
Source authentication allows rate limits and the disabling of accounts 
returning too many "recipient unknowns" to be effective at defending 
reputation.

Once acceptance becomes based upon DKIM signatures, a malefactor with 
access to a compromised system will be motivated to send themselves an 
innocuous series of signed messages that can then be replayed at 
unlimited rates to dubious recipients likely based upon harvested email 
address lists.   In addition, malefactors could subscribe to newsletters 
as hired agents and replay these messages in the same manner to thwart 
the communications of competitors.

Providers and companies may then discover their DKIM signatures are 
refused because of abuse well beyond their control, and there is 
unlikely any non-disruptive intertwining of authorization methods able 
to mitigate rejections for messages traversing mailing lists, forwarded 
to aliased accounts, or passing through LSNs.

Even when SPF has been obtained using DNSSEC, no conventions restrict 
every email element that might be used to discover SPF records.  Since 
SPF records are public, malefactors can use them to determine which 
authorize shared resources, where it is not uncommon to find thousands 
sharing a common resource.

As such, there should be considerations for reputations damaged by the 
lack of authentication of the transmitting domains.  As it stands, is 
seems the likely reaction will be to whitelist domains considered too 
big to block, and to reset reputations at the first complaints.  Dealing 
with complaints of this nature is likely to eventually prove highly 
frustrating, ineffective, expensive, and perilous when ignored.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 00:05:30 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
> Sent: Friday, November 11, 2011 1:28 PM
> To: Frank Ellermann
> Cc: [email-masked]
> Subject: Re: [domainrep] DKIM 101 for me (was Re: I-D.*-reputation-*.01
> 

The reputation provider is not the one receiving the mail in question, so it's not the one doing the SPF queries, with or without DNSSEC.

Rather, it's the entities reporting data to the reputation providers that do both, and convey that information.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 00:06:21 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Ellermann
> Sent: Friday, November 11, 2011 2:13 PM
> To: Rolf E. Sonneveld
> Cc: [email-masked]
> In fact an SPF FAIL almost guarantees that the mail is abuse by an
> unauthorized third party, and that's useless for any kind of "SPF
> reputation".

We shouldn't be considering fail cases, only pass cases.  There are lots of legitimate reasons why DKIM or SPF can fail, and they only pollute the data here.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 00:08:43 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Lewis
> Sent: Friday, November 11, 2011 3:01 PM
> To: [email-masked]

Yes, that's the vision I have too.  The reputation provider might, for some reason, get a different view of the subject domain's data than the message receiver does.  It's the latter that really matters.

> Is this necessarily a bad thing?

I don't think so.  And the current "vocab-identity" draft covers that case already.   Scott had suggested maybe we don't need that, so now I guess we really do have something to discuss.  :-)

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 12 Nov 2011 12:42:53 +0100

On 12 November 2011 00:01, Chris Lewis wrote:

> IOW: the querier provides a confidence parameter
> that contains things like 'DKIM pass', 'SPF -all

> The latter may be more powerful, and give the
> reputation agency more room for heuristically
> based return values.

> Yes, this potentially extends REPUTE to non-
> authenticated identities. Is this necessarily a
> bad thing?

I fear it's necessarily snake oil, and all involved
parties could save bandwidth with a random number
generator... ;-)

Example, you are the proverbial Bob, and you got a
MAIL FROM alice@paypal.  If it's a FAIL just reject
it, the "reputation" of MAIL FROM @paypal doesn't
enter the picture.

If it's a PASS and you don't know this "identity",
i.e., MAIL FROM @paypal is not in your white list,
you'd ask your snake oil provider what they think
about it.

An answer in the direction of 99.99% "MAIL FROM
@paypal" is spam/malware/phishing doesn't help you,
you are only interested in the 0.01% PASS details.

The same example would work for "DKIM-signed mail
with a paypal signature":  You don't want to know
how many "wannabe-paypal" mails have an invalid
DKIM signature, a signature by somebody else, no
signature, or a broken signature, let alone any
SPF results not limited to PASS.

Only "valid paypal signature" matches your query,
anything else your snake oil provider claims to
know about "wannabe-paypal" is irrelevant for your
query.

In fact you have no idea how "wannabe-paypal" is
defined, if it is not based on "valid signature"
or "SPF PASS".  What is your snake oil provider
doing, a popularity contest for domain names?  In
that case "anything paypal" would be very popular.

As a special case your query for SPF PASS @paypal
cannot be answered by "most paypal-DKIM-signed
mails are ham", or vice versa.  It's possible that
the "SPF reputation" and the "DKIM reputation" are
different, e.g., DKIM is designed to survive many
forwarding scenarios, and SPF is designed to give
you precise results only at the "MX-border".

> A SPF -all FAIL is rather different than an SPF
> ?all FAIL, so I think providers would want to
> factor that in.

They SHOULD NOT.  The "?" results mean NEUTRAL, and
by definition that means "sorry for wasting your
time looking for a PASS or FAIL, all I dare say is
DUNNO".

MAIL FROM @gmail is an example for publishing only
PASS or DUNNO, and a complete waste of your time if
you are interested in "FAIL or else".  But for the
purposes of REPUTE this kind of SPF policy is fine.

-Frank

---

From: Chris Lewis <[email-masked]>
Date: Sat, 12 Nov 2011 13:08:46 -0500

Meta: I'm a co-chair on this WG.  But occasionally want to say something 
less co-chairly ;-)

I'm going to try to differentiate the two by writing either [Chair] or 
[!Chair] in my remarks.

[!Chair]

> it, the "reputation" of MAIL FROM @paypal doesn't

I'd be confident with that if paypal.com published "-all" (I've beaten 
on one of their lead email infrastructure guys twice, in person, and he 
couldn't explain why it isn't), but it doesn't.  It publishes ~all. 
Which (theoretically at least - it could just be foot dragging) 
indicates that even they aren't confident enough yet of their own 
infrastructure and/or consequent implications (eg: forwarding) to be 
that assertive.

Many infrastructures aren't, and won't be for the forseeable future.

> you are only interested in the 0.01% PASS details.

If you forwarded along, say, an indication of "SPF ~all PASS" or SPF 
~all FAIL" (or even "SPF not checked" or "SPF returned processing 
error"), a reputation provider could put an observed "99.99% of 
paypal.com email is malicious" observation to good use.

> time looking for a PASS or FAIL, all I dare say is

Probably should have said "~all" instead of "?all" in my example.

It's useful information for heuristic based filtering.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 12 Nov 2011 20:20:09 +0100

On 12 November 2011 19:08, Chris Lewis wrote:

> occasionally want to say something
> less co-chairly ;-)

Tnx for info, the day before yesterday
<http://tools.ietf.org/wg/repute/>
was still work in progress, now it's up and running.
I looked for it in a "Gmail best guess" discussion:
<http://www.google.com/support/forum/p/gmail/thread?tid=2ba6c96da4cf017d>

 [Paypal's SOFTFAIL]
> I'd be confident with that if paypal.com published
> "-all" (I've beaten on one of their lead email
> infrastructure guys twice, in person, and he
> couldn't explain why it isn't), but it doesn't.

Yes, it is a kind of insider joke.  Some years ago
Doug found an even stranger SPF policy, after tons
of PASSing CIDRs and more convoluted PASS constructs
the policy ended with "all" (= PASS for the rest of
the world).

> It publishes ~all. Which (theoretically at least -
> it could just be foot dragging) indicates that
> even they aren't confident enough yet of their own
> infrastructure

Their recent include: zoo is certainly complex, but
nobody needs five years to figure their own "ADMD"
border out...

> and/or consequent implications (eg: forwarding)

...that's more plausible.  For receivers it's not too
bad, they could "help in debugging" (= the official
idea of a SOFTFAIL) with a reject or a bounce, even a
"helpful" copy to abuse@paypal can be in the spirit
of this debugging theory.  Or they can map this known
SOFTFAIL to their ordinary FAIL / NEUTRAL processing.

> If you forwarded along, say, an indication of "SPF
> ~all PASS" or SPF ~all FAIL" (or even "SPF not
> checked" or "SPF returned processing error"), a
> reputation provider could put an observed "99.99%
> of paypal.com email is malicious" observation to
> good use.

Dunno, but I begin to understand why Murray defines
"SPF" _and_ "MAILFROM" as different terms.  What you
suggest sounds like unspecific MAILFROM observations
not limited to SPF PASS.

-Frank (fondly remembering a nana* cancel cancel ;-)

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 12 Nov 2011 21:33:22 +0100

> Rather, it's the entities reporting data to the reputation providers that do both, and convey that information.

Excuse me for using the term 'reputation provider'. What I wanted to 
bring into the discussion is: what if the reporting entities determine a 
SPF/DKIM result using DNSSEC, should that add to the level of confidence 
or does it make no difference at all.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 14:13:05 -0800

> Sent: Saturday, November 12, 2011 10:09 AM
> To: [email-masked]

My mind immediately goes to the forwarder use case (e.g., I sign up for PayPal using an alumni association email address which I ensure always points to where I really get my mail).  If PayPal wants to accommodate those, they can't use "-all".

> paypal.com email is malicious" observation to good use.

This is an interesting point.  It means developing a reputation on SPF might need to be predicated on, or track, changes to the posted policy.  That is, the reputation could well change when some domain changes from a "~" rule to a "-" rule.  Or, maybe this means for developing reputation on entities based on flexible policy mechanisms like SPF, it's really important to age out your data.

Good input to our BCP-like document.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 14:18:37 -0800

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Saturday, November 12, 2011 12:33 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> bring into the discussion is: what if the reporting entities determine
> a SPF/DKIM result using DNSSEC, should that add to the level of
> confidence or does it make no difference at all.

Ah, that's a more interesting question.  Not having thought about it too much yet, I'd say that it doesn't need to be part of the report; if the domain owner doesn't secure its DNS, then if people start managing to get bogus signatures on abusive mail, the reputation degrades; when the domain owner figures it out and tightens up its operation, the reputation rebounds.

However, it would also not be a bad thing to do what you suggest and base confidence, at least in part, on knowledge of how trustworthy the SPF/DKIM evaluation is (and, for that matter, how trustworthy the reporting entity is, but that's another discussion altogether).

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Nov 2011 07:58:30 +0800

> Rather, it's the entities reporting data to the reputation providers that do both, and convey that information.

How about:

      The confidence value is a coarse measure. The basis for determining the 
value will be varied and chosen by the agency setting the value.

This is both an accurate statement and it avoids having this specification deal 
with any of the underlying issues that affect the choice.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 16:40:29 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Saturday, November 12, 2011 3:59 PM
> To: [email-masked]
>       The confidence value is a coarse measure. The basis for
> determining the value will be varied and chosen by the agency setting
> the value.
> 
> This is both an accurate statement and it avoids having this
> specification deal with any of the underlying issues that affect the
> choice.

Fine with me, so long as that's not in conflict with the need for reputations to be portable across providers.

That is: Do we require all parts of the answer to be portable, or only the actual reputation value?

This goes back to whether or not the units of the "sample size" part of the answer also have to be standardized, or even revealed.

---

From: "David F. Skoll" <[email-masked]>
Date: Sat, 12 Nov 2011 21:44:29 -0500

Just a question that may seem strange or naive at this stage, but:

Who decided that a domain name is an appropriate identity for reputation
with respect to email?

I don't consider a domain name very useful for that purpose.  It's
certainly far less useful than the sending SMTP relay's IP address.

Now it's true that certain very specific cases (for example, a
paypal.com message with an SPF "pass") are strongly correlated with
valid email, but outside of those cases or recipient-specific cases
[eg, the vendors and customers *I* deal with], I don't believe the
sending domain is a useful indicator of valid or invalid email and
hence isn't a useful identity for reputation purposes.

Regards,

David.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 13 Nov 2011 11:07:49 +0800

> Who decided that a domain name is an appropriate identity for reputation

s/identity/identifier/

> hence isn't a useful identity for reputation purposes.

As you point out, a domain name can be an appropriate identifier. It 
would be helpful to clarify when it is and is not appropriate.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 19:16:52 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of David F. Skoll
> Sent: Saturday, November 12, 2011 6:44 PM
> To: [email-masked]
> Subject: [domainrep] Appropriate choice of identity (was Re: DKIM 101
> for me (was Re: I-D.*-reputation-*.01)
> 

Those are the specific cases I'm envisioning: The domain name evaluated by DKIM or SPF, when a "pass" is the result, is a prime target for reputation development.  They, like the IP address of the SMTP client, have been vetted in some way with respect to the delivered message.

A domain name that hasn't undergone some kind of verification process is probably not a good subject for reputation, which is why it's been suggested that those be removed from the "vocab-identity" draft.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 19:18:11 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: Saturday, November 12, 2011 7:08 PM
> To: David F. Skoll
> Cc: [email-masked]
> Subject: Re: [domainrep] Appropriate choice of identity (was Re: DKIM 101 for me (was Re: I-D.*-reputation-*.01)
> 
> > Who decided that a domain name is an appropriate identity for
> > reputation with respect to email?
> 
> s/identity/identifier/

Well, darnit.  I guess that's something to keep in mind if/when this draft becomes a WG item (it's now "*-vocab-identity", although it's really the text inside that matters and not the filename).

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 13 Nov 2011 11:21:41 +0800

> Well, darnit.  I guess that's something to keep in mind if/when this draft becomes a WG item (it's now "*-vocab-identity", although it's really the text inside that matters and not the filename).

IMHO "identity" is one of those amorpous terms that's overloaded. My 
co-author on RFC 6125 convinced me to stop using it. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 19:28:31 -0800

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Saturday, November 12, 2011 7:22 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

The dictionary seems to agree with you.  For the sake of this work though, we probably can focus on describing and selecting things that qualify as reliable identifiers, without having to get into what an identity is.  I like it.

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 13 Nov 2011 11:29:05 +0800

>> Who decided that a domain name is an appropriate identity for reputation

+10

d/

-- 

   Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 13 Nov 2011 15:58:30 +0100

On 13 November 2011 04:21, Peter Saint-Andre wrote:

> IMHO "identity" is one of those amorphous terms
> that's overloaded. My co-author on RFC 6125
> convinced me to stop using it. :)

That still yields 159 "identif" vs. 127 "identit"
in RFC 6125.  Ignoring case it's 170:196 with a
clear winner [Ii]dentit, but that includes 57 page
headers and the document title with an "Identity".

-Frank

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 13 Nov 2011 14:12:10 -0500

On 11/12/2011 05:13 PM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Chris Lewis Sent:
>> Saturday, November 12, 2011 10:09 AM To: [email-masked]
>> I'd be confident with that if paypal.com published "-all" (I've
>> beaten on one of their lead email infrastructure guys twice, in
>> person, and he couldn't explain why it isn't), but it doesn't.  It
>> publishes ~all. Which (theoretically at least - it could just be
>> foot dragging) indicates that even they aren't confident enough yet
>> of their own infrastructure and/or consequent implications (eg:
>> forwarding) to be that assertive.
>>
> My mind immediately goes to the forwarder use case (e.g., I sign up
> for PayPal using an alumni association email address which I ensure
> always points to where I really get my mail).  If PayPal wants to
> accommodate those, they can't use "-all".

I'd argue they can. Since the forwarder is an agent of the receiver the 
receiver should arrange not to check SPF for forwarded mail, but that 
can degenerate into an entire additional set of arguments that are 
almost certainly not relevant for the topic.

>> If you forwarded along, say, an indication of "SPF ~all PASS" or
>> SPF ~all FAIL" (or even "SPF not checked" or "SPF returned
>> processing error"), a reputation provider could put an observed
>> "99.99% of paypal.com email is malicious" observation to good use.
>
> This is an interesting point.  It means developing a reputation on
> SPF might need to be predicated on, or track, changes to the posted
> policy.  That is, the reputation could well change when some domain
> changes from a "~" rule to a "-" rule.  Or, maybe this means for
> developing reputation on entities based on flexible policy mechanisms
> like SPF, it's really important to age out your data.
>

SPF has a limited number of results: pass, fail, neutral, none, 
softfail, temperror, and permerror.  I think trying to assert more 
granularity that would be a mistake.  I don't think the terminating 
mechanism is relevant for reputation tracking (it's also very easy to 
make it difficult to determine what it really is, so to the extent it 
can affect results, it can also be gamed).

Scott K

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 13 Nov 2011 07:31:19 -0500

++1

Five years ago, the ITU-T attempted to deal with the
subject. It consumed countless meetings and emails.
The "overloading" went on and on. Governments
intervened claiming we were infringing on the personal
zeitgeist of citizens, and individual activist groups argued
that human identity is for each individual to determine and
control. Ultimately, the group ended up sticking the
following definition into an international standard known
as Rec. X.1250, and produced the attached visualization:

> 3.2.12 identity: The representation of an entity in the form of one or 
> more information elements
> which allow the entity(s) to be sufficiently distinguished within 
> context. For IdM purposes, the term
> identity is understood as contextual identity (subset of attributes), 
> i.e., the variety of attributes is
> limited by a framework with defined boundary conditions (the context) 
> in which the entity exists
> and interacts.
> NOTE – Each entity is represented by one holistic identity, which 
> comprises all possible information
> elements characterizing such entity (the attributes). However, this 
> holistic identity is a theoretical issue and
> eludes any description and practical usage because the number of all 
> possible attributes is indefinite.

May domainrep be more fortunate.

--tony

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 17 Nov 2011 23:59:30 +0100

> The dictionary seems to agree with you.  For the sake of this work though, we probably can focus on describing and selecting things that qualify as reliable identifiers, without having to get into…

was this one of the topics under item 7 of the agenda 
(http://www.ietf.org/proceedings/82/agenda/repute.txt) of the WG 
meeting, yesterday? I believe we decided, due to time constraints, to 
discuss the topics of item 7 further on the list.

David Skoll started this thread with the question why _domainname_ was 
chosen as identifier for reputation. From the discussion that followed 
and from agenda item 7, it seems there are more identifier candidates 
that can be subject to reputation within the e-mail 'application'. Like:

- domainname
- IP address (optionally split up into IPv4 and IPv6)
- 5321.MailFrom?
- 5322.From?
- others?

Although domainname and IP address may seem to be more logical choices 
for reputation, I would not like to exclude beforehand other types of 
identifiers, although each of them will have its own challenges 
regarding the way they are authenticated. But _as authentication of the 
reputation identifier is out of scope_ I see no reason to stick to only 
one or two types of identifiers. Identifiers like 5321.MailFrom and 
5322.From may prove to be useful to discriminate between identifiers 
within 'too big to block' domains like gmail.com and hotmail.com.

And if we decide there is room for multiple identifiers within the 
application 'email', the next step is: this will have impact on the http 
and dns/udp query mechanisms. As for the http query protocol we will 
need an extra 'identifier type' in the template or in the uri 
definition. And for the DNS query, we may need additional namespaces for 
the various identifiers. IPv6 may provide its own challenges here with 
respect to the subnetting options 
(http://en.wikipedia.org/wiki/IPv6_subnetting_reference).

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Nov 2011 15:02:27 -0800

Hi Rolf,

> Sent: Thursday, November 17, 2011 3:00 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [domainrep] Appropriate choice of identity
> 

The current "-vocab-identity" draft supports all of those (other than the generic "others", of course).  The focus of my own implementation has been on domain names verified with DKIM.  It's certainly possible to do it based on other things; the SPF-verified domain name is the next obvious choice to me since it's a verified identity.  And the IP address is known to be useful, because DNSBLs are based on it (though they obviously use a different query mechanism).

The others are less obvious, because they aren't vetted, and nobody's tried to develop reputation on them yet to see if it's successful.  There's some tension in this kind of work between going out with a standards track document that enables a bunch of things that might be useful, or one that enables only what's known to work but leaves the framework extensible for further R&D.

Is anyone interested in building a reputation system based on one of the other identities to see if it's worth supporting?

> application 'email', the next step is: this will have impact on the
> http and dns/udp query mechanisms. As for the http query protocol we
> will need an extra 'identifier type' in the template or in the uri
> definition. And for the DNS query, we may need additional namespaces
> for the various identifiers. IPv6 may provide its own challenges here
> with respect to the subnetting options

The mechanism is there already in the URI templates stuff (or, if people think that's too complex, we can roll back to fixed-format URIs) to include that as a parameter to the query.  We just have to specify how it would be encoded.

In the case of the "-vocab-identity" draft, we do already have provisions to include that information in the reply.

-MSK

---

From: Chris Lewis <[email-masked]>
Date: Fri, 18 Nov 2011 20:20:40 -0500

> Is anyone interested in building a reputation system based on one of the other identities to see if it's worth supporting?

[!Chair] others to consider, which already have "existence proofs" ;-)

reverse DNS - ("Enemies List", aka EL)
HELO - (alternate use of EL plus others)

Note also, considerations should also be given to "unauthenticated 
domains", including full host names.  While it can be hard to generate 
strong positive reputations on unauthenticated names, when the rubber 
hits the road, high negative reputations can be extremely useful, 
authenticated or otherwise.  While this does imply an avenue for 
poisoning someone else, this is a game that's already well understood by 
the relevant parties already in the fray, and reputation providers 
should be allowed to continue to innovate in this area.

> In the case of the "-vocab-identity" draft, we do already have provisions to include that information in the reply.

I'm going to come up with "a" (perhaps not the only) use case set with 
existing reputation-ish mechanisms, and this should help here.