Subject: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)

From: "John R. Levine" <[email-masked]>
Date: 21 Jun 2010 15:00:15 -0400

As threatened, here's an I-D that says how one would publish a list of 
domains for which it makes sense to discard unsigned mail.

Since I'm a big fan of running code, you can find such a list at 
drop.services.net of domains that (in my opinion at least) sign all their 
mail with DK or DKIM, and for whom it makes sense to drop unsigned mail.

R's,
John
---------- Forwarded message ----------
Date: Mon, 21 Jun 2010 10:55:49 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Subject: New Version Notification for draft-levine-dbr-00

A new version of I-D, draft-levine-dbr-00.txt has been successfully submitted by John Levine and posted to the IETF repository.

Filename:	 draft-levine-dbr
Revision:	 00
Title:		 Discard by Reference
Creation_date:	 2010-06-21
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
Domains can authenticate their outgoing mail using DKIM or other
techniques.  In some cases where miscreants frequently use a domain
without authorization in the Author address in e-mail messages, it
may be prudent for recipient mail systems to discard unauthenticated
mail as likely to be fraudulent.  This specification defines an
extension to Vouch by Reference (VBR) that allows a certifier to
identify such domains, and that recipients can use either in
conjunction with or independently of VBR.

The IETF Secretariat.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Franck Martin <[email-masked]>
Date: Tue, 22 Jun 2010 08:33:20 +1200 (FJT)

dig txt paypal.com._drop.services.net

does not give me anything...

----- Original Message -----
From: "John R. Levine" <[email-masked]>
To: "DKIM List" <[email-masked]>
Sent: Tuesday, 22 June, 2010 7:00:15 AM
Subject: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 21 Jun 2010 18:05:36 -0400

> does not give me anything...

Right, because that's not the syntax of VBR.  Try this:

paypal.com._vouch.drop.services.net

R's,
John

> mail with DK or DKIM, and for whom it makes sense to drop unsigned mail.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Jun 2010 16:24:40 -0700

On 6/21/10 12:00 PM, John R. Levine wrote:
>  As threatened, here's an I-D that says how one would publish a list
>  of domains for which it makes sense to discard unsigned mail.
>
>  drop.services.net of domains that (in my opinion at least) sign all
>  their mail with DK or DKIM, and for whom it makes sense to drop
>  unsigned mail.
John,

What motivates using two domains in a query, which still excludes the 
relationship between the author-domain and third-party service?  The 
tpa-label scheme is informative of a specific relationship between 
author-domain and third-party service, thereby allowing responses for 
specific threats and requirements of the author domain.  Why not allow a 
means for domains to indicate they don't use some social network, 
without making the third-party service unusable for any other domain?

A vouching (reputation) service that protects against spoofing using the 
vbr structure will likely confront difficult to resolve administrative 
problems.  Thresholds for blocking a domain will likely cause collateral 
losses for other domains not normally phished when other domains are 
being heavily phished.  Because DKIM signatures can be replayed, 
including ancillary conditions, such as requiring an List-ID or Sender 
header, better isolates poorly vetted messages without users seeing 
different email domains used.  Of course, these headers depend upon the 
relationship between the third-party service and the author-domain.  The 
tpa-label scheme allows selective inclusion of other header requirements 
based upon the author-domain.  This information allows recipients to 
depend upon these headers when sorting messages having different levels 
of vetting.  If these specific relationships are not met, the message 
would be refused.

IMHO, it would be less problematic to use the tpa-label mechanism to 
make this type of query. The tpa-label scheme has been improved by 
isolating the hash labels.

Unlike vbr, the tpa-label has less of an impact on the usable domain 
name.  Allowable maximums are not reduced by the size of vouching domain 
and _vouch label.  With tpa-labels, a vouching service can handle a 
domain size up to 241 characters. When a domain provides their own vbr 
vouching service, the maximal domain size may be a maximum length of 122 
characters.  This smaller size may not work well for international 
domain names.  The added reference size of vbr also displaces 
information bound by a DNS response limit, and results in more of cache 
being consumed as well, while still omitting information specific to the 
third-party service and the author domain.

With tpa-labels, a signer can utilize a vouching service by delegating 
their _tpa zone, or by using DNAME at this node.  Domains can also self 
publish their own exception criteria in a manner transparent to recipients.

In addition, except for the indirection and extra transaction, there 
does not appear to be a significant difference between discard by 
reference and ADSP dkim=discardable?

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 22 Jun 2010 10:46:33 -0600

> domains for which it makes sense to discard unsigned mail.

Looks like a good start, and almost shockingly simple.  Any MTA/MFA support yet?  *grin*

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 22 Jun 2010 12:07:17 -0600

On Jun 22, 2010, at 11:28 AM, Michael Thomas wrote:

> On 06/22/2010 09:46 AM, J.D. Falk wrote:
> I still don't get why it's ok for John Levine to publish a list which
> says that it's ok to discard unsigned mail from paypal.com, but st00pid
> for paypal.com to publish the same thing. That is the essence of his
> jihad against adsp.

Because presumably verifiers will trust John's process for compiling this list more than they'd trust any random schmoe with the ability to create TXT records.

(If paypal were representative of all domains, this wouldn't be a concern.)

Personally, I think we'll need lists like this for a while in order to gain more experience and determine best practices, and THEN we can decide whether to change (or even scrap) ADSP to reflect those practices.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Jun 2010 10:28:23 -0700

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Jun 2010 11:29:04 -0700

> (If paypal were representative of all domains, this wouldn't be a concern.)

Well that's pretty ironic because paypal.com is listed in his database
as being discardable even after he got done telling them they were incompetent
for setting their ADSP record to discardable since they mix users and transactional
mail all in the same sub domain. So it seems that John isn't any more competent
than paypal.com by his own competency test.

> Personally, I think we'll need lists like this for a while in order to gain more experience and determine best practices, and THEN we can decide whether to change (or even scrap) ADSP to reflect th…

Who watches the watcher?

I'm very dubious that John can do that without explict bidirectional human correspondence.
Which is no different than paypal.com publishing their ADSP record since
the people who put up the ADSP record are extremely likely to be the same people
telling John's list that they want to be set to discardable. What the value add for
the middle man is here -- besides faithfully copying errors -- is a mystery.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Jun 2010 11:32:24 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Thomas
> Sent: Tuesday, June 22, 2010 10:28 AM
> To: J.D. Falk
> Cc: DKIM List
> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00 (fwd)
> 

In the context of VBR, it's the same programming logic as him (or anyone) vouching for a particular domain as having trustworthy transactional or other mail.  He's just asserting ADSP on someone else's behalf in this case.

You can choose to trust his assertions (by querying his list on verification failures) or ignore them (by not querying him in the first place).  At least that's the theory, I believe.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jun 2010 12:04:58 -0700

> Looks like a good start, and almost shockingly simple.  Any MTA/MFA support yet?  *grin*
If only it was simple.  How do you envision the VBR scheme offering 
protection for phished domains?

ADSP imposes a specific Author Domain policy related to DKIM.

Whereas, the VBR-Info header might apply against _ANY_:
  i) DKIM signature domain, or
  ii) Return-Path, or
  iii) PRA. (from, sender, resent-*, etc.)

Except for Author Domains, these other domains are typically not visible.

Vouching information from a service selected by a vbr-info header can 
now include a discard recommendation, in addition good/bad ratings used 
to adjust spam scores.

Without a DKIM signature, the vbr-info header can include anything, and 
make use of recycled domains in any of a number of invisible domains, 
such as the return-path, resent-sender, etc.

How would vbr-info header and an additional discard status mitigate 
abuse when it can be based on many invisible domains?

How will discard be different from returning extremely negative ratings?

The duration of domains used to phish is often measured in hours, where 
an arbitrary use of path registration will not protect phished domains.  
Wack-a-Mole does not work very well.

What protection will a Resent-Sender header offer when mitigating a 
phishing problem?

Isn't vouching and reputation outside the DKIM WG?

BTW, does MFA mean Mail Forwarding Agent?

-Doug

---

From: <[email-masked]>
Date: Tue, 22 Jun 2010 14:40:21 -0400

adsp is an assertion by a sender. John's list is a reputation of the sender's adsp assertions (WAG)

---

From: John Levine <[email-masked]>
Date: 22 Jun 2010 22:50:42 -0000

>Looks like a good start, and almost shockingly simple.  Any MTA/MFA support yet?  *grin*

Give me another week.

R's,
John

---

From: John Levine <[email-masked]>
Date: 22 Jun 2010 23:08:20 -0000

> You can choose to trust his assertions (by querying his list on
> verification failures) or ignore them (by not querying him in the
> first place).  At least that's the theory, I believe.

Exactly.  This is a scalability issue.  You can afford to spend a fair
amount of effort investigating the reliability of a VBR service before
you decide whether to use it, just like you do investigating the
reliability of a DNSBL, because you'll never use more than a handful
of either.

R's,
John

---

From: John Levine <[email-masked]>
Date: 23 Jun 2010 00:07:33 -0000

>adsp is an assertion by a sender. John's list is a reputation of the sender's adsp assertions (WAG)

Not quite, it's a third party's assertions that are somewhat but not really
like ADSP

As far as I know Amazon doesn't make any ADSP assertions, but it is my
impression that they sign all their transactions with DK or DKIM, and
they're certainly a phish target, so it would be reasonable to drop
unsigned Amazon mail anyway.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jun 2010 17:12:00 -0700

> On Jun 22, 2010, at 2:29 PM, Michael Thomas wrote:
The vbr scheme will not help to mitigate a phishing problem, since it 
allows the "authentication" of any number of other domains.  As such, it 
will not help deal with ADSP issues caused by mailing lists either.

The discard vbr represents roughly the same feature as ADSP 
dkim=discardable, but introduces other types of "authentication/"  
Allowing more ways to authenticate might allow a small number of emails 
to be delivered that might have been rejected when a signature is 
damaged in transport, but this is unlikely, and unlikely to help with 
mailing lists.

Path registration schemes largely depend upon the treatment of headers 
and parameters holding domains other than the Author Domain.  Any domain 
that uses VBR and a provider handling many other domains might confront 
a problem caused by treating _authorization_ as being "authentication."  
Just because something is authorized, does not mean that its origination 
has been authenticated.  In an era where many legitimate accounts are 
being compromised, DKIM provides a margin of safety where servers 
commonly carry email for many different domains.  The additional 
protection afforded by DKIM is lost when depending upon discard vbr. :^(

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jun 2010 17:37:26 -0700

> unsigned Amazon mail anyway.
What happens when Amazon has a service using a parent signature?  As a 
result of a third-party vouching service, their messages might be 
discarded, and they won't become aware of the issue until damage is wide 
spread.   TINLA, but it seems having a service advocating for the 
discard of someone elses's email could be a liability.  How does one 
determine whether a vouching service is authoritative for the domain in 
question?  Please don't say use another vouching service, because the 
issue is _who_ should decide whether a message must have a valid 
Author-Domain signature or be discarded.

-Doug

---

From: [email-masked]
Date: Wed, 23 Jun 2010 13:09:30 +0000

Since Amazon set it up in the first place, wouldn't they be keenly aware of the service signing issues?

Mute point if they understand what they are doing. 

Regards,
Damon Sauer. 

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Douglas Otis <[email-masked]>
Sender: [email-masked]
Date: Tue, 22 Jun 2010 17:37:26 
To: <[email-masked]>
Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-00
 (fwd)

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 24 Jun 2010 12:32:18 +0100

> of the service signing issues?

Well, if they're using ADSP, then they have a chance. But it's going to be 
difficult for them to keep track of the third party assertions made about 
their services.

I think it's worse to drop mail because Amazon are no longer doing what 
some third party thought they were doing, than it is to drop mail because 
Amazon published incorrect records.

I might find some value in a list that asserts "You can trust the ADSP 
records for these domains...." than a list that asserts "These domains 
always sign their email..."

>> Not quite, it's a third party's assertions that are somewhat but not
>> really like ADSP
>>

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: John Levine <[email-masked]>
Date: 24 Jun 2010 14:49:35 -0000

>difficult for them to keep track of the third party assertions made about 

Are you making the assumption that all third party lists would be equally
credible?  That's no more likely than all DNSBLs being equally credible.

In both cases, the good ones will make sure their data is correct,
maybe by backchannels to the underying providers (see the Spamhaus PBL
for an example of that) or by some kind of feedback watching the mail
they make assertions about.  The bad ones won't do that, and won't be
useful.  (See any number of useless poorly run DNSBLs for an example
of that.)

I'm not attempting to invent a way to ensure that all assertions are
correct.  It's a way to collect assertions into small enough groups
that it's practical to do manual checks of the credibility of each
group.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jun 2010 08:21:50 -0700

On 06/24/2010 07:49 AM, John Levine wrote:
  Are you making the assumption that all third party lists would be equally
> useful.  (See any number of useless poorly run DNSBLs for an example

Any service that doesn't have an *explicit* guarantee from the mail
domain itself that it signs all mail is worse than incompetent,
it's harmful. A third party can *never* prove the negative that the
domain in question doesn't have sources of unsigned mail that they
don't want discarded. The domain in question without a thourough
audit probably doesn't have a clue itself if it's even vaguely
largeish.

So why does a domain that performs that painful audit and
remediation need to then tell John's drop list that it's OK to
drop unsigned mail? It doesn't. It can just publish an ADSP
record and be done with it. No need to count on some unreliable,
unaccountable point of failure to mediate their business.

Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jun 2010 08:43:08 -0700

> unaccountable point of failure to mediate their business.

The problem is that it's not possible to distinguish based solely on
self-published data the domain that's done all that work, and actually
understands the implications from the domain that's just published
an ADSP record because they'd heard it was a good idea, with no
understanding of the effect that would have on their email.

Even paypal, who are one of the main forces driving ADSP, didn't
think through the most basic implications, and caused a lot of
legitimate email that was from their domains, yet not DKIM signed 
to be received. If recipient use of ADSP were widespread then
that would have been a business failure rather than just an
embarrassment.

Given that, the odds that any given ADSP-discardable record is
something that it makes operational sense to use is pretty low.
And no competent mailbox operator will want to allow untrusted
third parties to control the service they provide to their customers -
delivery of email.

A similar argument applies to third party lists, including those
run by John, ReturnPath and Spamhaus, with the critical difference
that each of those lists is a single entity, rather than the ADSP-discardable
pseudo-list, which is run by as many different people as their are
domains, so their accuracy can be tracked
over time, and their data only used once it's demonstrated itself to
be accurate enough to have operational benefits.

Cheers,
  Steve

---

From: Martijn Grooten <[email-masked]>
Date: Thu, 24 Jun 2010 16:45:46 +0100

> unaccountable point of failure to mediate their business.

What if it publishes an ADSP record but doesn't understand the implications? Because, for instance, they send a lot of email to mailing lists. Or because to some emails, an MTA adds some blurb to the body after the DKIM signature has been computed. Or because they forget that in some (rare) cases they do not sign their email. (The latter happened to GMail who, without having published an ADSP record, had said that all of their email was DKIM-signed. Some of it wasn't. At least one commercial spam filter used GMail's claim to block unsigned email coming from GMail.)

So my view of the service being discussed here isn't one where some guy in upstate NY claims to have full knowledge of which domains DKIM-sign all their outbound email. Rather, it's a service where the manager of the service uses claims made by the sender about whether they sign all of their email and then only lists those domains that know what their doing.

Just my two cents.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 24 Jun 2010 10:28:38 -0600

> unaccountable point of failure to mediate their business.

Why do you keep assuming that John's proof-of-concept drop list is the only way a drop list can ever operate?

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jun 2010 09:34:15 -0700

> So my view of the service being discussed here isn't one where some guy in upstate NY claims to have full knowledge of which domains DKIM-sign all their outbound email. Rather, it's a service where…

Maybe we need an ADSP flag that says "I think I sign all my outbound mail, and if a trusted third party vouches that I'm not entirely clueless about DKIM then you should trust them and treat this as "dkim=discardable", but otherwise don't pay too much attention to this and treat it as "dkim=unknown"".

Or maybe that's what "dkim=all" already means.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Jun 2010 09:36:43 -0700

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, June 24, 2010 8:43 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] New Version Notification for draft-levine-dbr-
> 00(fwd)
> 

I don't think it's guaranteed that this is the case even if you go to the site and personally interview the people that work there.  I agree it increases your chances, but it's not a bulletproof solution either.  And over time, any such guarantee you do manage to eke out could easily (and perhaps is likely to) erode.

If the intent is to find something that works all the time, we should give up now.

If we're okay with approximations, I'm not sure self-publication should be so easily disqualified.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jun 2010 09:39:20 -0700

> understanding of the effect that would have on their email.

Sure. And it's a bad idea to set your MX records to 127.0.0.1 because
you heard it stops spam cold too.

> that would have been a business failure rather than just an

If people actually deployed ADSP receivers, there'd be a big incentive
for the publishers to get clue too.

> third parties to control the service they provide to their customers -

That's a bizarre use of "third party". The From sending domain isn't a
"third party" under any definition I can think of.

> be accurate enough to have operational benefits.

A single entity that the domain in question has absolutely no idea
about, and certainly no control over. Considering that their listing
is exactly as accurate as the domain in question's own due diligence
in the best case, and completely wrong in the average case, why would
anybody trust it over the domain's own assertion?

This looks to me like a business in search of a vict^H^H^H^Hcustomer.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jun 2010 09:52:44 -0700

> What if it publishes an ADSP record but doesn't understand the implications? Because, for instance, they send a lot of email to mailing lists. Or because to some emails, an MTA adds some blurb to t…

There are an infinite number of ways to shoot yourself in the foot.
They could also stop signing with DKIM on weekends so they can give
their DKIM signers some well earned rest and relaxation too.

> So my view of the service being discussed here isn't one where some guy in upstate NY claims to have full knowledge of which domains DKIM-sign all their outbound email. Rather, it's a service where…

In this instance, not even the guy in upstate NY can keep things straight with his
own small database.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jun 2010 09:57:29 -0700

> If we're okay with approximations, I'm not sure self-publication should be so easily disqualified.

Right. If there's some value here, it would be a "clueless" service instead of
a "drop" service. Ie, "they say they know what they're doing, but don't". But
even that runs afoul of proving a negative because if the listed domain ever
screwed up for any reason, the "clueless" list could latch on to that and never
let go... how is it to know that the transgression has been remediated?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jun 2010 10:07:33 -0700

On 06/24/2010 09:28 AM, J.D. Falk wrote:
>> don't want discarded. The domain in question without a thorough

So what is incorrect about what I wrote?

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jun 2010 13:03:41 -0400

> [email-masked]] On Behalf Of Michael Thomas
> Sent: Thursday, June 24, 2010 12:53 PM
> To: Martijn Grooten
> Cc: [email-masked]
> Subject: Re: [ietf-dkim]New Version Notification for draft-levine-dbr-
> 00(fwd)
> 
> > What if it publishes an ADSP record but doesn't understand the
> implications? Because, for instance, they send a lot of email to
mailing
> lists. Or because to some emails, an MTA adds some blurb to the body
after
> the DKIM signature has been computed. Or because they forget that in
some
> (rare) cases they do not sign their email. (The latter happened to
GMail
> who, without having published an ADSP record, had said that all of
their
> email was DKIM-signed. Some of it wasn't. At least one commercial spam
> filter used GMail's claim to block unsigned email coming from GMail.)
> 
> > So my view of the service being discussed here isn't one where some
guy
> in upstate NY claims to have full knowledge of which domains DKIM-sign
all
> their outbound email. Rather, it's a service where the manager of the
> service uses claims made by the sender about whether they sign all of
> their email and then only lists those domains that know what their
doing.
> 
> In this instance, not even the guy in upstate NY can keep things
straight
> with his

I come in to the fray on the side of Michael. +1

If an organization doesn't understand the implications of publishing
ADSP (or doing anything else for that matter) then the basic damage done
is to themselves and their users. Their domain, their problem.

The case where a domain owner contracts with 3rd parties such as eCert,
Authentication Metrics, Return Path, Truedomain or others means that the
3rd party is acting on their behalf. If the 3rd party gets it wrong in
this case then it is a contractual issue between the sending domain and
the organization they contract with.

When random 3rd parties start publishing about domains that is a real
problem. If a random list publisher tells people to drop unsigned mail
by a particular domain - particularly in the absence of an ADSP record -
there is the possibility of them getting sued. This is a significantly
different case then something like SPAM and RBLs. 

Mike

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jun 2010 11:00:28 -0700

> is to themselves and their users. Their domain, their problem.

... and the problem of the recipients of their mail, and a support issue for the ISP of those recipients.

When an ISP starts dealing with complaints about the quality of their service[1] they will make the obvious operational decision and cease using ADSP to discard email.

They might well continue discarding non-DKIM signed mail from some subset of ADSP publishers.

I think that's a perfectly reasonable operational result, but I don't think it's the one that those signing with ADSP intended.

Cheers,
  Steve

[1] silently dropping mail that's wanted by the recipients is about the worst failure of an email provider, and ADSP is likely to be applied mostly to mail that the sender believes is important and wanted by recipients, as if the mail itself didn't have perceived high value then phishes based on it wouldn't be of high value either.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Mark Delany" <[email-masked]>
Date: 24 Jun 2010 10:10:33 -0700

> guy in upstate NY claims to have full knowledge of which domains
> DKIM-sign all their outbound email. Rather, it's a service where the
> manager of the service uses claims made by the sender about whether
> they sign all of their email and then only lists those domains that
> know what their doing.

Why not have a negative service then?

John's list can refute an ADSP of "at risk" domains by including a
link of an exemplar unsigned email (ironically provable via SPF if
necessary...)

Sortof assume ADSP competence until shown otherwise rather than
assumed incompetent until judged otherwise?

That list would then be quite valuable as a way of letting such
domains know that they are vulnerable *and* where their leak is.

dig paypal.com._whatever... txt

atRisk=y; claimsADSPAll=y; counterExample=http://....

Conceivably "at risk" domains would first submit themselves to such a
service and ask it to discover and publish (and/or feedback) counter
examples.

Since all you need is one counter example, getting 20 or 30 large,
trusted mail providers to participate in identifying such emails and
domains should be able to know pretty quickly when something has gone
awry with their IT audit.

John's list then simply becomes a focal point of discovery rather than
a judgment call.

Mark.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 24 Jun 2010 14:37:14 -0400

> Sent: Thursday, June 24, 2010 2:00 PM
> To: DKIM List
> ... and the problem of the recipients of their mail, and a support
issue
> for the ISP of those recipients.
> 

Form response... (I'm putting it tersely) "You need to go speak with the
folks at example.com as they are the ones creating the problem". If
enough receiving domains stood their ground on this it would quickly
become a non-issue. This is no different than receivers blocking MTAs
that are open relays. THAT doesn't seem to be much of a topic for
conversation these days.

> When an ISP starts dealing with complaints about the quality of their
> service[1] they will make the obvious operational decision and cease
using
> ADSP to discard email.

Nothing in the ADSP spec says that the ISP has to silently drop the
mail. For all you know the ISP may choose to automatically send a notice
to the intended recipient indicating that they dropped mail from
example.com based on the published request from example.com and that if
the enduser has any questions they should contact
[email-masked].

I LOVE hypotheticals. For every seemingly reasonable hypothetical you
come up with I'm sure that others can come up with one just as
reasonable that shows an alternative outcome.

> They might well continue discarding non-DKIM signed mail from some
subset
> of ADSP publishers.

That wouldn't be particularly useful for senders or receivers. How does
this differ from the pre-ADSP situation where a handful of large senders
cut private deals with a handful of large receivers? The whole point is
to come up with a standard so that it is A) open and B) scalable. What
you are suggesting is neither.

> I think that's a perfectly reasonable operational result, but I don't
> think it's the one that those signing with ADSP intended.
>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jun 2010 14:37:18 -0700

On 06/24/2010 10:10 AM, Mark Delany wrote:
  Conceivably "at risk" domains would first submit themselves to such a
> John's list then simply becomes a focal point of discovery rather than

That's essentially the same thing that I mentioned with my "clueless"
list in a previous post.

The question is: once you get checked into the clueless motel, how can
you ever check out? This is the same weakness of DNSBL's, fwiw. Worse
in this case, because it's really bound up in whether somebody's infrastructure
is actually set up correctly, which is hard for the domain's owner and
near impossible for an outside third party to determine.

Mike

---

From: John Levine <[email-masked]>
Date: 24 Jun 2010 22:13:52 -0000

>Maybe we need an ADSP flag that says "I think I sign all my outbound
>mail, and if a trusted third party vouches that I'm not entirely
>clueless about DKIM then you should trust them and treat this as
>"dkim=discardable", but otherwise don't pay too much attention to
>this and treat it as "dkim=unknown"".

You could certainly use my DbR proposal together with ADSP, and say to
drop mail only if both ADSP and DbR say to drop it.

Assuming the DbR list were competently run, I'm not sure there'd be any
practical advantage, particularly since DbR allows you to check both DK
and DKIM.

R's,
John

---

From: John Levine <[email-masked]>
Date: 24 Jun 2010 22:21:51 -0000

> ADSP (or doing anything else for that matter) then the basic damage
> done is to themselves and their users. Their domain, their problem.

I think that if you talk to ISPs whose customers call and ask why they
didn't get the mail they were expecting, you will find that this
assertion is mistaken.

In practice, I expect that where a competent DbR and ADSP differ, the
DbR would say to ignore the ADSP, they say it's discardable but
they're wrong, not the other way around.  Amazon is a fairly unusual
case, signing everything (as far as I can tell) but not making any
public assertions about it.

>different case then something like SPAM and RBLs. 

Sigh.  I wish people would refrain from giving legal advice in
technical fora, particularly legal advice that, in the US at least, is
obviously wrong.

R's,
John

---

From: John Levine <[email-masked]>
Date: 24 Jun 2010 22:24:28 -0000

>mail.

Actually, it does.  Read it again.

>For all you know the ISP may choose to automatically send a notice to
>the intended recipient indicating that they dropped mail from
>example.com based on the published request from example.com and that
>if the enduser has any questions they should contact
>[email-masked].

Ooh, "we're sending you this useless notification instead of what might
have been spam".  Just when we thought that had been stamped out.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 25 Jun 2010 10:02:42 -0400

> From: John Levine [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 6:24 PM
> To: [email-masked]
> Cc: MH Michael Hammer (5304)

http://tools.ietf.org/search/rfc5617 

Section 3.3

All messages from this domain are signed with an Author Domain
      Signature and are discardable, i.e., if a message arrives without
      a valid Author Domain Signature, the domain encourages the
      recipient(s) to discard it.

4.2.1.  Record Syntax

discardable
                        All mail from the domain is signed with an
                        Author Domain Signature.  Furthermore, if a
                        message arrives without a valid Author Domain
                        Signature due to modification in transit,
                        submission via a path without access to a
                        signing key, or any other reason, the domain
                        encourages the recipient(s) to discard it.

Help me out here John, where exactly is that "silently drop" section? I
see the discarding part but the "drop silently" part seems to be a bit
silent. Other than the "encourages recipient(s) to discard it" phrase,
the document gives no other guidance as to what the receiver might or
might not do.

> have been spam".  Just when we thought that had been stamped out.

So you have decided to join the group that claims DKIM and ADSP are
about fighting spam rather than being an authentication mechanism.
Interesting.

---

From: "John R. Levine" <[email-masked]>
Date: 25 Jun 2010 11:44:07 -0400

> silent.

Sheesh, Mike.  Discard is an ordinary English word which I used in its 
ordinary English sense.  I suppose there might be people who say 
"Attention! I have thrown a used coffee cup into the wastebasket!" each 
time they do so, but I hope I don't know any of them.

> about fighting spam rather than being an authentication mechanism.

If by fighting spam, you mean not sending mail which is certain to be 
useless and unwanted, I guess I plead guilty.

If we can turn our minds back a decade or so, you may recall that some 
spam filters replaced a suspect message with an announcement saying "so 
and so sent you spam, which we caught, and we're sending you this message 
instead."  We all got a zillion of them.  Did you ever do anything with 
any of those messages other than delete them?  I certainly didn't.

If you don't trust a filtering technique to work, don't use it.  But for 
heaven sakes, don't excuse broken spam filters by sending more spam.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Jun 2010 09:11:26 -0700

On 06/25/2010 08:44 AM, John R. Levine wrote:
> ordinary English sense.

I guess you've never played Rummy.

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 25 Jun 2010 14:02:41 -0400

> From: John R. Levine [mailto:[email-masked]]
> Sent: Friday, June 25, 2010 11:44 AM
> To: MH Michael Hammer (5304)
> Subject: RE: [ietf-dkim] New Version Notification for
draft-levine-dbr-
> time they do so, but I hope I don't know any of them.

We seem to agree that discard means "throw away". Where we seem to
disagree is that I take it as face value and recognize that RFC5617 says
nothing beyond that. You are reading between the lines or the
super-secret lemon juice portion of the spec to determine that any
discarding must be silent and that the Receiver MUST NOT do anything
else beyond throwing it away silently.

> useless and unwanted, I guess I plead guilty.

Now I'm really getting confused John. On the one hand you argue that
there are hordes of panting implementers anxiously awaiting the
opportunity to publish borked (a technical term) ADSP records (compared
to their mailing practices) thus creating a situation where their very
important mail will be discarded by any receiver that follows the
instructions of those implementers. (If the mail was not important then
there would not be many - if any - complaints to receivers and this
discussion would be moot.)

On the other hand you are now arguing that a notification to the
intended recipient that there was a problem based on the published
requirements of the sending domain is certain to be useless and
unwanted.

Most interesting. I believe this is what's known as cognitive
dissonance. Either the mail is important and there will be complaints
(to receivers) or it is not important and nobody will care on the
receiving end if it gets discarded (silently).

> heaven sakes, don't excuse broken spam filters by sending more spam.

So ADSP is a broken spam filter? Why would you present yourself as the
co-author of a broken spam filter?

---

From: "John R. Levine" <[email-masked]>
Date: 25 Jun 2010 14:39:04 -0400

> We seem to agree that discard means "throw away".

Evidently.  But I do have the advantage of knowing what I meant when I 
wrote the section we're arguing about.

> discussion would be moot.)

That's why, as I have consistently argued since day 1, the correct thing 
for implementers to do is to ignore ADSP completely, since there is 
nothing you can do with it that will produce better results than ignoring 
it.

> co-author of a broken spam filter?

As I think I made pretty clear at the time, I crowbared my way into the 
ADSP effort to try to minimize the damage.   If it were up to me, we would 
have abandoned the effort without producing any RFC at all, but there 
were too many people who believed (and apparently some who still believe) 
that it's a magic bullet against something.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 25 Jun 2010 14:44:51 -0400

> Sent: Friday, June 25, 2010 2:39 PM
draft-levine-dbr-
> wrote the section we're arguing about.

And the rest of the world has the disadvantage of only knowing what is
written in the RFC. 

I don't recollect you proposing wording that included "silently" so it
isn't even possible for a person going back and look at the discussions
to know what you meant. 

We are therefore left with what you wrote and which the working group
came to a consensus on.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 25 Jun 2010 11:58:14 -0700

> wrote the section we're arguing about.

This is, I think, the third or fourth time we've been through the "what does
discard mean?" thread.

Is there any way we can add interpretation notes to the existing RFC,
to clarify what it means, so we can avoid going over the same terminology
issues repeatedly (and, as a bonus, make the spec clearer for
implementors)?

Cheers,
  Steve

---

From: Jon Callas <[email-masked]>
Date: Fri, 25 Jun 2010 12:20:37 -0700

>      recipient(s) to discard it.

My interpretation is that gives you the license to do whatever makes sense to you, as a receiver. If you *want* to silently drop a message that doesn't meet policy, that's all the standards ammo you need to justify your decision.

On the other hand, if you want to log, audit, quarantine, filter, or even bend, fold, spindle, or mutilate the message, you have justification as well. DiscardABLE doesn't mean they MUST be discarded. Encouragement is even weaker than a SHOULD, and it's the sending domain that encourages it.

	Jon

---

From: "John R. Levine" <[email-masked]>
Date: 25 Jun 2010 16:21:00 -0400

> We are therefore left with what you wrote and which the working group

Whatever.  I find it hard to see how anyone could interpret the RFC and 
the discussion leading up to it as a hidden consensus to send spam every 
time a receiver saw "dkim=discardable", but I'm clearly not going to 
persuade you otherwise.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 25 Jun 2010 12:44:11 -0700

Hi Mike,
>And the rest of the world has the disadvantage of only knowing what is

There is thread about the word at 
http://mipassoc.org/pipermail/ietf-dkim/2008q1/009572.html

The authoritative answer is in Section 4.2.1 of RFC 5617.

Regards,
-sm

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 25 Jun 2010 16:35:31 -0400

> Sent: Friday, June 25, 2010 4:21 PM
draft-levine-dbr-
> time a receiver saw "dkim=discardable", but I'm clearly not going to

Folks should interpret the RFC how it is written. 

For a failure on "discardable" the receiver is encouraged to discard the
message. Thus it is written thus it is interpreted.

By omission it is left to the receiver to decide whatever else they
might or might not do in conjunction with a decision to discard
messages. That is beyond the scope of what is written in RFC5617.

I did not say receivers MUST nor did I say receivers SHOULD, I said that
they COULD as one approach to the issue of making it clear that any
non-delivery is at the direction of the sending domain. A receiver might
choose to only do so for a financial domain such as Paypal.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 Jun 2010 13:46:52 -0700

> [email-masked]] On Behalf Of Jon Callas
> Sent: Friday, June 25, 2010 12:21 PM
> To: MH Michael Hammer
> Cc: IETF DKIM WG
> My interpretation is that gives you the license to do whatever makes
> sense to you, as a receiver. If you *want* to silently drop a message
> that doesn't meet policy, that's all the standards ammo you need to
> justify your decision.
> 
> On the other hand, if you want to log, audit, quarantine, filter, or
> even bend, fold, spindle, or mutilate the message, you have
> justification as well. DiscardABLE doesn't mean they MUST be discarded.
> Encouragement is even weaker than a SHOULD, and it's the sending domain
> that encourages it.

+1.  OpenDKIM actually implements a reject (55x error) with the intent of giving the sender/victim an opportunity to detect a problem, an idea for which there is some obvious demand, though I imagine we should make that configurable and maybe even default it to an actual accept-but-throw-away form of "discard".

As the language in RFC5617 is soft ("encourages", "discardABLE"), the assertion that doing anything other than accept-but-throw-away is indicative of lunacy could easily be lost on the reader.  If it's really a major problem, maybe the WG should do an update draft that hardens the language and explains clearly that "discard" in this context means "250 + bitbucket".

---

From: John Levine <[email-masked]>
Date: 26 Jun 2010 01:58:42 -0000

>+1.  OpenDKIM actually implements a reject (55x error) with the
>intent of giving the sender/victim an opportunity to detect a
>problem, an idea for which there is some obvious demand, though I
>imagine we should make that configurable and maybe even default it to
>an actual accept-but-throw-away form of "discard".

That seems reasonable to me, but keep in mind that's the exact behavior
that got people bounced off an IETF list when an unrelated domain marked
its users' mail as discardable.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Sat, 26 Jun 2010 14:49:32 +1200 (FJT)

Silly question, may be.

Can openDKIM issue a 4xx code if not a single valid DKIM signature is found?

This could be issued if no valid DKIM signature is found and connecting IP is v6. 

And would the sender retry with a V4 address then?

----- Original Message -----
From: "John Levine" <[email-masked]>
To: [email-masked]
Sent: Saturday, 26 June, 2010 1:58:42 PM
Subject: Re: [ietf-dkim]	New	Version	Notification	for	draft-levine-dbr-00(fwd)

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 26 Jun 2010 03:11:21 -0700

Hi Franck,
>Can openDKIM issue a 4xx code if not a single valid DKIM signature is found?

I suggest discussing about that on the OpenDKIM mailing 
list.  Opendkim supports fine-grained policy control (see 
http://www.opendkim.org/opendkim-lua.3.html ).

Regards,
-sm

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 28 Jun 2010 11:42:28 +0100

> its users' mail as discardable.

Yes, in light of the MLM problem, the best thing to do is to 5xx messages 
which don't appear to be from mailing lists, but to discard (silently or 
otherwise) those that do.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 28 Jun 2010 11:36:21 +0100

> wrote the section we're arguing about.

Right, but knowing what you meant isn't the point. You're arguing about 
what you wrote.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 28 Jun 2010 11:39:07 +0100

> time a receiver saw "dkim=discardable", but I'm clearly not going to

It's nothing of the sort. The question isn't whether one SHOULD notify the 
recipient, but whether one MAY do so.