Subject: [ietf-dkim] General Feedback loop using DKIM

From: Franck Martin <[email-masked]>
Date: Wed, 27 May 2009 10:36:31 +1200 (NZST)

I'm curious to see if the feedback loop mechanism could be extended using DKIM. The concept may have many issues, but I want to see if it is a stupid idea, or if it would have some merit. 

The system would be for the sender to include in the dkim mechanism an FBL-email: header wich would tell the receiving mail system where to send an ARF email if the recipient hit the spam button. 

This would provide a mechanism similar to FBL but allowing small receiving mail systems to participate. I think some stats show that 30% of people hitting the spam button, really means, unsubscribe me from this mailing list. 

Also, mail footers with remove links, are either not read or are not trusted by the recipient, I think, it is safer to hit the spam button, than to click on the links. 

By sigining the FBL-email: header it would give a certain level of trust, that there is a mailbox at this address and that the mailbox has been set to process ARF emails. The FBL-header must be DKIM validated, otherwise it would not be helpful at all. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Tue, 26 May 2009 16:07:12 -0700

On May 26, 2009, at 3:36 PM, Franck Martin wrote:

> I'm curious to see if the feedback loop mechanism could be extended  
> using DKIM. The concept may have many issues, but I want to see if  
> it is a stupid idea, or if it would have some merit.
>
> The system would be for the sender to include in the dkim mechanism  
> an FBL-email: header wich would tell the receiving mail system where  
> to send an ARF email if the recipient hit the spam button.
>
> This would provide a mechanism similar to FBL but allowing small  
> receiving mail systems to participate.

FBLs as currently implemented don't work very well except for webmail  
and AOL, because there's no UI support for it elsewhere.

Without some sort of MUA support, I think it's pretty much a non- 
starter (though there are a bunch of startups and projects that  
disagree with me and try and do similar things by annotating the email  
itself at the MX).

Are you thinking that this would be something that could be handled  
by, for example, an Outlook or Thunderbird plugin, without necessarily  
needing any support from the receiving ISP?

> I think some stats show that 30% of people hitting the spam button,  
> really means, unsubscribe me from this mailing list.
>
> Also, mail footers with remove links, are either not read or are not  
> trusted by the recipient, I think, it is safer to hit the spam  
> button, than to click on the links.

The List-Unsubscribe header is nearly as trustworthy as a DKIM signed  
FBL-Email header as far as communicating a desire to receive no  
further email is concerned, and it's been around forever, yet there's  
not been that much MUA support for it so far. I'm not sure whether  
that's because of a lack of desire or just due to the overly vague  
specification of List-Unsubscribe and friends.

>
> By sigining the FBL-email: header it would give a certain level of  
> trust, that there is a mailbox at this address and that the mailbox  
> has been set to process ARF emails. The FBL-header must be DKIM  
> validated, otherwise it would not be helpful at all.

Presumably there'd be some constraint to prevent a (DKIM-signing)  
spammer putting some random third party email address in there too.

Cheers,
   Steve

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 27 May 2009 05:19:23 +0530

As Steve says the list-unsubscribe header works about as well as what
you are suggesting .. if an ISP actually decides they want to
implement this across the board and trust any list unsubscribe header
that comes their way.  Which is not particularly recommended.

You typically contact an ISP out of band to apply for an FBL and
whitelisting.  And there is some crosschecking done before the FBL is
set up.

On Wed, May 27, 2009 at 4:06 AM, Franck Martin <[email-masked]> wrote:
> I'm curious to see if the feedback loop mechanism could be extended using
> DKIM. The concept may have many issues, but I want to see if it is a stupid
> idea, or if it would have some merit.
>
> The system would be for the sender to include in the dkim mechanism an
> FBL-email: header wich would tell the receiving mail system where to send an
> ARF email if the recipient hit the spam button.
>

---

From: Franck Martin <[email-masked]>
Date: Wed, 27 May 2009 12:22:40 +1200 (NZST)

list-unsubscribe: header is a free field and often contains a url rather than an email address: 
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, 
<mailto:[email-masked]?subject=unsubscribe> 
This could be a candidate, but would need may be some more specifics and codified in an RFC. I'm not sure it is today. I cannot recall exactly to have seen it codified in any RFC. 

Only very large ISPs are offering FBL programs, and often they sub-contract the program to a third party. Could technology make it simpler for smaller ISPs and organisations with a non trivial amount of mailboxes?

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 27 May 2009 06:07:57 +0530

list-unsubscribe IS an rfc. An rfc by Josh Baer but still ..

http://www.ietf.org/rfc/rfc2369.txt

On Wed, May 27, 2009 at 5:52 AM, Franck Martin <[email-masked]> wrote:
> This could be a candidate, but would need may be some more specifics and
> codified in an RFC. I'm not sure it is today. I cannot recall exactly to
> have seen it codified in any RFC.
>
> Only very large ISPs are offering FBL programs, and often they sub-contract
> the program to a third party. Could technology make it simpler for smaller
> ISPs and organisations with a non trivial amount of mailboxes?
>

---

From: Steve Atkins <[email-masked]>
Date: Tue, 26 May 2009 17:50:16 -0700

On May 26, 2009, at 5:22 PM, Franck Martin wrote:

> This could be a candidate, but would need may be some more specifics  
> and codified in an RFC. I'm not sure it is today. I cannot recall  
> exactly to have seen it codified in any RFC.

RFC 2369. It's defined to typically contain one or more URLs, usually  
mailto:. Something that handled solely mailto: automatically would  
handle all the forms I recall seeing, though (optionally) punting to  
the user for http: and https: if there were no mailto: would be an  
obvious thing to do. If there were interest in supporting it at the  
MUA level it would not be difficult to do the non-UI parts of the  
support needed.

It's widely deployed by senders, especially smaller senders, today,  
but has less support at receivers.

On May 26, 2009, at 5:15 PM, Franck Martin wrote:

> It is also very heavy to have a FBL program this is why only a few  
> ESPs offer feedback loops. I'm not sure it is something feasible for  
> an organisation with a substantial number of users, like  
> universities or small ISPs.

There are two difficult and/or expensive parts to offering a feedback  
loop. They are the development costs of implementing some sort of UI  
to capture feedback from the user (easier on webmail platforms, but  
still not trivial) and the ongoing support costs of managing a  
relationship with the senders who receive your feedback loop reports.

Compared to those two I suspect that working out where to send a  
report, and actually sending it, are much cheaper parts of the system.

Cheers.
   Steve

---

From: Franck Martin <[email-masked]>
Date: Wed, 27 May 2009 15:13:34 +1200 (NZST)

> report, and actually sending it, are much cheaper parts of the system. 

Well you define the 2 difficulties: 
1) Development costs of implementing a UI 
2) Relationship with the sender 

1) if there is a standard, developpers can implement it in MUA and MTA so they are compatible. say MUA forward the complete email to a special mailbox on the MTA, and the MTA process it. Not sure if it is a valid/possible implementation, but that one that comes to mind. 
2) if properly DKIM validated then there would be no need to define an out of band relationship with the sended. DKIM with a special protocol should be able to establish an inband relationship. Sender puts in the email that is wants to receive FBL, reciever evaluates if the sender request is valid and then process it. 

May be I should move this thread in ASRG? As dkim would provide validation/trust but not everything. 

Overall, the list-unsubscribe processing could not be done, because we could not trust any of the email headers until we had a trust mechanism with DKIM. 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 27 May 2009 09:09:19 +0530

> 1) Development costs of implementing a UI

... in an open source / freely available app like squirrelmail?

... as a 3rd party toolbar or extension for tbird / outlook?

... as a PART of outlook?

... as a part of the AOL client, or the hotmail / gmail / outblaze web UI?

Cost varies a lot, doesnt it?

> 2) if properly DKIM validated then there would be no need to define an out
> of band relationship with the sended. DKIM with a special protocol should be

Oh?  So a spammer publishes some random stuff in a dkim record and I'm
supposed to believe it?  Or c1t1b4nk.com publishes a dkim record with
a list unsubscribe and I'm supposed to do just what with it?

srs

---

From: Steve Atkins <[email-masked]>
Date: Tue, 26 May 2009 20:42:29 -0700

On May 26, 2009, at 8:13 PM, Franck Martin wrote:

> 1) if there is a standard, developpers can implement it in MUA and  
> MTA so they are compatible. say MUA forward the complete email to a  
> special mailbox on the MTA, and the MTA process it. Not sure if it  
> is a valid/possible implementation, but that one that comes to mind.

If you're just using it for FBLs then there's no need at all to get  
the MTA involved. If you also want to use it for other things (tuning  
spam filters, whatever) then that's a rather different scope as the  
MUA will need to communicate with an entity other than the sender.

> 2) if properly DKIM validated then there would be no need to define  
> an out of band relationship with the sended. DKIM with a special  
> protocol should be able to establish an inband relationship. Sender  
> puts in the email that is wants to receive FBL, reciever evaluates  
> if the sender request is valid and then process it.

Not at all, no. In an ISP scope the out of band relationship with the  
sender is not optional, even if you buy into the self-publication  
approach completely. Try ignoring their emails if you don't think  
that's so. :)

If it's an ad-hoc thing done just by end users then that's less likely  
to be an issue, perhaps.

> validation/trust but not everything.

That's a pretty bad place to take it. I'd guess that talking to MUA  
developers would be the sensible next step to work out whether it's  
worth pursuing or not, as they're the people who are going to have to  
implement it.

I think that you're right in it not really being a DKIM thing, though.

>
> Overall, the list-unsubscribe processing could not be done, because  
> we could not trust any of the email headers until we had a trust  
> mechanism with DKIM.

I don't see any failure mode there, really, with the (minor) exception  
of someone being able to route FBL reports to a third-party. So adding  
a DKIM signature doesn't really add any value.

If the List-Unsubscribe method is used solely to route feedback to the  
sender then there are two cases:

   1) The sender wants to receive that sort of feedback and intends to  
act on it.

   2) The sender doesn't want to receive that sort of feedback, or  
doesn't intend to act on it.

The sender is in complete control of the value of that field. If the  
sender wants to do (1) then they can do so with or without signing the  
field. Similarly, if the sender wants to do (2) then they can do so  
with or without signing the field.

There doesn't seem to be any value to an intermediate party to modify  
the field to prevent feedback reports or unsubscription requests from  
reaching the original sender, or even any scenario like that that  
isn't implausibly contrived, I don't think.

Cheers,
   Steve

---

From: Franck Martin <[email-masked]>
Date: Wed, 27 May 2009 16:46:59 +1200 (NZST)

> Cost varies a lot, doesnt it? 

None of the RFCs have trivial costs to implement 
> a list unsubscribe and I'm supposed to do just what with it? 

Well would you have allowed the email to reach the inbox in the first instance? 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Wed, 27 May 2009 10:44:05 +0530

> Well would you have allowed the email to reach the inbox in the first

What if it does manage to reach the inbox?  I certainly dont claim
infallibility, 100% accuracy etc for my spam filtering.

-- 
Suresh Ramasubramanian ([email-masked])

---

From: Franck Martin <[email-masked]>
Date: Wed, 27 May 2009 23:16:12 +1200 (NZST)

nobody's perfect ;)

---

From: Al Iverson <[email-masked]>
Date: Wed, 27 May 2009 10:44:40 -0500

Allowing a sending entity to determine a destination for FBL reports
by embedding that information in a message header implies trust of
that sender. Signing mail with DKIM is not an indicator of trust. So
how do you know to trust that sender? It's ends up being a big catch
22, in that if you trust the sender, perhaps because they've
registered with you, then they might as well have registered with you
directly to set up the FBL that way.

Savvy anti-spammers have long had a distrust of spam reporting vectors
being defined only by the sender of the message. Systems that track
where to send complaints by IP or domain (for example, Spamcop and
Abuse.net), as well as ISPs, have run into various scenarios where a
bad actor will attempt to direct complaints back only to himself, to
keep his connectivity provider or other provider in the dark as to the
nature of the bad acts. I had an "X-Complaints-to" header in mail sent
on the platform I used to manage at my last employer. The only notice
of it taken was by angry complainers assuming that use of this header
was evidence that I was trying to guide complaints away from
upstreams. Based on all of this, I wouldn't support a mechanism that
would allow a sender to specify where reports should be sent, because
of the potential for abuse, and the (in my opinion), very small chance
that it would gain traction.

BTW, I think that dismissing FBL utility because it's only (currently)
most useful in webmail environments is a bit short sighted. I wouldn't
be surprised to see more "report spam" plugins for various desktop or
smartphone MUAs in the future. Outlook + a widely distributed report
spam button plugin = a gold mine of reputation data for spam filter
developers. I am sure that I am not the first person to think of this.

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Wed, 27 May 2009 09:08:03 -0400

Perhaps I am confused as to the perceived complexity of an FBL
ISP needs an address of [email-masked]<mailto:[email-masked]>
user aligns the ThisISSpam setting in the MUA to the above address
ISP scans the purported sender header and forwards message to [email-masked]<mailto:[email-masked]>
which can either work or round file the item

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Franck Martin
Sent: Tuesday, May 26, 2009 8:23 PM
To: Suresh Ramasubramanian
Cc: [email-masked]
Subject: Re: [ietf-dkim] General Feedback loop using DKIM

---

From: <[email-masked]>
Date: Wed, 27 May 2009 09:08:03 -0400

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 May 2009 09:29:03 -0700

Al Iverson wrote:
> that sender. 
...
> smartphone MUAs in the future. 

There is a functional specification lurking in this thread, but I'm not 
convinced I fully understand it.  Quick glimpses of pieces.  Shadows.  But no 
full-on, explicit description.  There is a chance that everyone else is filling 
in the details, on their own, in the same way, but I'm not succeeding.

The activity of the thread suggests there might be some interest in pursuing the 
idea, so I'd like to make sure everyone really is on the same page, in terms of 
what the desired capability is and the problems in achieving it.

So here's a draft 'requirements' spec, mostly intended to give the rest of you 
something to fix:

=====

      An FBL Service Without Prior Arrangement
      ----------------------------------------
      Well-intentioned senders of bulk email attempt to restrict their mailing 
lists to willing recipients.  Nonetheless, their lists sometime contain 
erroneous entries.  In addition, willing recipients sometimes change their 
minds.  Some recipient systems afford users a means of indicating that they no 
longer wish to receive mail from a particular sender.  The FBL is an 
infrastructure mechanism for passing these indications on to registered senders.

      Existing FBLs involve registration for two reasons.  One is establish a 
validated trust relationship between the sender and the recipient's email 
operator, and the other is to make explicit that the registrant has a desire to 
participate in the FBL mechanism.  The reason for the former is obvious.  The 
reason for the latter is to avoid flooding senders with FBL traffic they are not 
prepared to process.  This is partly a matter of good etiquette and partly to 
limit the possibility of blow-back DOS streams.

      Existing FBL mechanisms are cumbersome and expensive to operate. Hence 
they are used only among the very largest email recipient operators.  However 
FBLs are useful mechanisms.  If the cost of operating them can be reduced, while 
retaining their protection, they could be applied more broadly among Internet 
mail services.

      The functional requirements for this service comprise:

          1.  A means by which a sending operator can indicate a desire to
              receive feedback from recipients, and the address to which to
              send the feedback.

          2.  Verification that the indication really is from the sending
              operator

          3.  Assessing the trustworthiness of the sending operator

          4.  A means by which a recipient can provide feedback.

      A List-Unsubscribe header field can satisfy Req. #1.  A DKIM signature by 
the operator -- so that the DKIM signing domain is the same as the 
List-Unsubscribe domain -- can satisfy Req. #2.  A specialized MUA button is 
needed for Req. #4.

      Req. #3 requires some sort of assessment mechanism, such as a third-party 
whitelist.

     If all 4 conditions are satisfied, the cost of running an FBL capability 
between any two operators will be quite low.

=====

Now, of course, the real problem here is that this merely moves the hardest part 
to Req. #3.  But the implication is that something other than a per-operator 
list could be useful and, thereby, costs reduced.

I guess my question is why this doesn't come for free, when honest-to-goodness 
operator-oriented domain name white lists gain traction?  Such lists are the 
real goal of doing /any/ DKIM signing.  So once you have sending operatos 
signing with DKIM and an array of assessment mechanisms used DKIM-verified 
domain names, why can their use be easily extended to this type of FBL?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Adkins <[email-masked]>
Date: Wed, 27 May 2009 16:57:44 -0400

Please, let's not drag message header fields into this. That's an
unproductive path. (and by unproductive path I mean I will never send an
ARF report to an address just because it's listed in a header field,
signed or not)

If we want to make FBLs (reports back to the signing domain, not the
mailbox provider) easier, then we need a record we can lookup to find a
report destination email address.

If the message is signed, great. We can check some kind of RR for the
signing domain to find a destination address. If it's an address within
the signing domain, then we send the report and call it a day. If the
signing domain does not list a destination address, then we don't need
to send a report.

If the address is not in the signing domain, then we need some kind of
'acceptance of delegation' record for the destination address' domain.
So, someone like ReturnPath would have a whopping DNS RR of 'domains we
accept FBLs for' listing their customer domains and each of their
customers would have a FBL destination RR like
[email-masked]'.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 May 2009 00:37:50 -0700

> ARF report to an address just because it's listed in a header field,

Mike,

Please review the summary.  It was not "just because it's listed in a header 
field", but the listing was within a larger trust and authentication context. 
Very different beast.

> report destination email address.

The choice between within-band (in the message) and out-of-band (e.g., DNS 
record) should be determined by efficiency and/or trust.  Out of band is mostly 
used for matters of trust, such as getting the DKIM key independent of the 
message that it is used to validate.

The summary I gave accomplishes the necessary trust by validating the associated 
identity with DKIM, and b) consulting whatever assessment/reputation mechanism 
is deemed sufficient.

Even with an external listing of the ARF address -- such as via a DNS record -- 
you don't have the necessary trust basis for believing that the address should 
be used.  Note that I claimed that the current FBL registration mechanism is for 
both authentication and trust.

If I've got that wrong, let's figure out what it should say that is right. 
After all, I did say the summary was primarily intended for you guys to fix. 
Not 'reject' but fix.

> signing domain does not list a destination address, then we don't need

What is the basis for requiring it to be external.

> 'acceptance of delegation' record for the destination address' domain.

I was careful to specify the relationship among the domain names, specifically 
to avoid delegation issues.  It's not that they are irrelevant, but that I'm 
hoping they are incremental.  Let's get the core details right and then we can 
enhance it to cover things like delegation.

d/
-- 

   Dave Crocker

---

From: Michael Adkins <[email-masked]>
Date: Thu, 28 May 2009 10:52:25 -0400

> What is the basis for requiring it to be external.
Where the signer wanted reports about the message to go at the time the
message was sent is not relevant.  Where the signer wants the reports to
go at the time the report is generated is relevant.  It is common for
there to be a week or more delta between sending the message and a user
submitting a report.  There is many a slip between cup and lip.

The presence of a header field that is signed does not guarantee that it
was placed there by the signer, merely that it was present when the
message was signed.   It therefore does not provide a mechanism for
verifying that the requested destination address is authoritative for
the domain.

Also, this is a policy statement by the domain.  Their policy is that
automated abuse reports should be sent to a specific address.  My
understanding of the current model for stating domain policy (as with
ADSP) is a published record that can be queried.

> I was careful to specify the relationship among the domain names,
> specifically to avoid delegation issues.  It's not that they are
> irrelevant, but that I'm hoping they are incremental.  Let's get the
> core details right and then we can enhance it to cover things like
> delegation.
Delegation is the first real stumbling block these efforts always hit. 
(I blame ReturnPath. ;))  If we are serious about it we need to make
sure that we have plan for how to handle it from the start so we don't
paint ourselves into a corner.

I think this is where we disagree.   I feel that the trust requirements
don't need be part of the core details but delegation does.

---

From: Michael Adkins <[email-masked]>
Date: Thu, 28 May 2009 10:39:52 -0400

>       An FBL Service Without Prior Arrangement
This is incorrect. FBLs are not unsubscribe mechanisms. They are used as
such by bulk senders who receive them, but that is neither their sole
nor primary purpose (nor does it constitute the majority of reports
sent). Their purpose is to inform system operators of abuse on their
network. How they choose to address (or not address) the report is up to
them and varies widely based on the type of organization they are.

> limit the possibility of blow-back DOS streams.
This is incomplete. What must be validated during registration is that
the destination address is authoritative for all the messages it will
receive reports about. I'm not sure what specific type of trust
relationship you are describing, but I'm not sure I would describe
'whether it would be a violation of the message author's privacy to send
them a report to the signer's address or not' as 'whether I trust a
signer or not'.

>       A List-Unsubscribe header field can satisfy Req. #1.
Discussed below.

>   A DKIM signature by 
There are two questions that you have to answer before you send a
report. One is where to send it. How to answer that question is a good
candidate for standardization I think. The other is whether you should
send it or not. This is a much stickier question as the policies for
existing FBLs vary widely and there is scant little consensus. On the
one end you have folks like Outblaze who require a strong whitelist
status for the sender in order to receive reports. On the other you have
AOL who will send reports to anyone who can display a reasonable amount
of authority for the domain (access to the postmaster@ mailbox for a
confirmation, for example). These differences are due to policies based
around everything from filtering strategy to legal requirements and
there is little motivation to converge. As such, I find this part to be
a poor candidate for standardization, beyond addressing the bare minimum
authority requirements. If there is a strong desire to do so, that's
fine, but please keep it separate from the 'where to send it' question.

> domain names, why can their use be easily extended to this type of FBL?
They can if the whitelists requirements comply with your FBL policy. So,
you are correct in that eventually we should get it for free. This is a
good argument for leaving the 'should I send it' question separate from
'where to send it'.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 May 2009 08:13:36 -0700

> fine, but please keep it separate from the 'where to send it' question.

I think the "whether" question divides into to parts.

The first is authority for receiving reports.  This is more than just being told 
where to send reports; it satisfies the requirement to determine that the 
directive for where to send reports comes from an authority to make that 
request.  So, is the "where" a valid request?

The second is whether the reporting agency wants to honor that valid request. 
That's the role of the assessment mechanism.  You cite Outblaze, which requires 
a strong assessment, and you cite AOL which effectively requires none -- it will 
send a report to anyone asking for it and authorized to do so.  I can't think of 
any reason that is or should be inherent to this mechanism for constraining the 
assessment step -- the Outblaze and the AOL policies both ought to be acceptable.

In the summary, I tried to wave my hand about what assessment step might be 
performed.  I think you've demonstrated why it's important NOT to specify very 
much about it.  But I don't think you've highlighted any error or problem with 
this part of the summary.  (In contrast with the corrections you supplied for 
other parts of the summary.)

> good argument for leaving the 'should I send it' question separate from

and, to be complete, the "is the specification for where to send it valid?"

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 28 May 2009 08:23:11 -0700

> submitting a report.  There is many a slip between cup and lip.

Oh.

Interesting point.

Anyone disagree with it?  If so, how and why?

> verifying that the requested destination address is authoritative for

Oops. Right.  I keep raising the same point about whether contents are validated 
by DKIM.  Sigh.

So, there's a Pandora's box that this raises, which is how to use DKIM in a way 
that has the semantics of claiming that bits of contents are in fact valid?

> ADSP) is a published record that can be queried.

I don't recall that ADSP is meant to lay claim to the entire space of such 
declarations.  So the precedent that it does some of it ought not to dictate the 
'venue' for communicating the next bit; that decision ought to hinge on whatever 
semantics, efficiency and validity issues apply.

> don't need be part of the core details but delegation does.

ack.  fair point to debate.

d/

-- 

   Dave Crocker

---

From: Michael Adkins <[email-masked]>
Date: Thu, 28 May 2009 12:04:04 -0400

Dave CROCKER wrote:
>
>
> Michael Adkins wrote:
>>>       Req. #3 requires some sort of assessment mechanism, such as a
>>> third-party whitelist.
>>>   
> The first is authority for receiving reports.  This is more than just
> being told where to send reports; it satisfies the requirement to
> determine that the directive for where to send reports comes from an
> authority to make that request.  So, is the "where" a valid request?
>
> The second is whether the reporting agency wants to honor that valid
> request. That's the role of the assessment mechanism.  You cite
> Outblaze, which requires a strong assessment, and you cite AOL which
> effectively requires none -- it will send a report to anyone asking
> for it and authorized to do so.  I can't think of any reason that is
> or should be inherent to this mechanism for constraining the
> In the summary, I tried to wave my hand about what assessment step
> might be performed.  I think you've demonstrated why it's important
> NOT to specify very much about it.  But I don't think you've
> highlighted any error or problem with this part of the summary.  (In
> contrast with the corrections you supplied for other parts of the
> summary.)
>
>
>>> I guess my question is why this doesn't come for free, when
>>> honest-to-goodness operator-oriented domain name white lists gain
>>> traction?  Such lists are the real goal of doing /any/ DKIM
>>> signing.  So once you have sending operatos signing with DKIM and an
>>> array of assessment mechanisms used DKIM-verified domain names, why
>>> can their use be easily extended to this type of FBL?

I can agree with all this.  Specify how to validate the request. 
Mention that trust is important and why, but leave it to the report
sender to specify.

---

From: Michael Adkins <[email-masked]>
Date: Thu, 28 May 2009 12:07:45 -0400

> Oops. Right.  I keep raising the same point about whether contents are
> validated by DKIM.  Sigh.
>
> So, there's a Pandora's box that this raises, which is how to use DKIM
> in a way that has the semantics of claiming that bits of contents are
> in fact valid?
>
>
Correct, which is why I prefer it out of band for this effort.

> I don't recall that ADSP is meant to lay claim to the entire space of
> such declarations.  So the precedent that it does some of it ought not
> to dictate the 'venue' for communicating the next bit; that decision
> ought to hinge on whatever semantics, efficiency and validity issues
> apply.
>
>
Fair enough.  I feel that the model fits the circumstances of this issue
well enough, but I'm open to debate if anyone has a good argument for a
different model.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Thu, 28 May 2009 09:07:35 -0700

> Anyone disagree with it?  If so, how and why?

It's a design decision. The approach Michael suggests is exactly what  
you're going to want to do for peer IP-based FBLs, and doing it the  
same way seems a perfectly reasonable implementation choice for signer  
identity based FBLs, but I don't think it's the only reasonable choice  
for FBLs based on self-publication by the signer (assuming there's any  
value to them at all, which I'm not entirely convinced by).

A counter-argument would be that an FBL is a way of responding to the  
sender of an email about that email. It's very siimilar to the Reply- 
To: field, the envelope from or the links in the body of the mail, and  
they all seem to work perfectly well as values set at the time the  
message was sent.

>> verifying that the requested destination address is authoritative for

Yup.

It depends on the way a DKIM signer chooses which headers to sign.

If the signer will sign any headers you give it, rather than having a  
list of headers it chooses to sign, then you're right.

If, on the other hand, it only signs a list of headers that it knows  
about then you would know that if you saw "My-Fun-Header" signed that  
it was done so with the knowledge and permission of the domain owner -  
as by signing it the signer asserts they know about it, and they're  
either adding it themselves or permitting their users to add it.

Unfortunately the DKIM spec is pointedly vague on which approach to  
use, so while most of the implementations I've seen use a fixed list  
of headers, that's not something you can rely on as a general mechanism.

> that has the semantics of claiming that bits of contents are in fact  

Can't do it as currently specced, I don't think.

Cheers,
   Steve

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 28 May 2009 15:01:43 -0400

>that has the semantics of claiming that bits of contents are in fact valid?

So the Affiliated Names List could be applied here. That proposal
basically says that if you find an authenticated domain in my DNS,
consider that some sort of relationship exists. Applying that to this:

FBL-Where-To-Send-Header: [email-masked]
DKIM-Signature: ... d=example.com ...

If in example.net's dns there exists an entry for example.com, then one
can safely assume there is a relationship between the two.

http://mipassoc.org/affil/specs/draft-macdonald-affiliated-nameslist-00-04dc.html

-- 
Jeff Macdonald
[email-masked]

---

From: Florian Sager <[email-masked]>
Date: Fri, 29 May 2009 09:04:31 +0200

Franck Martin schrieb:
> using DKIM. ...
Hi Franck,

with http://www.dkim-reputation.org we offered automatic FBLs for valid
DKIM signed messages in the following setup from approx. Sept 08 to Jan 09:
- feedback is provided for mails hitting a spamtrap
- destination address of the feedback: I discussed with Murray the use
of an r= entry (there was once a discussion about its use as reporting
address) but since this is not supported I chosed the following: a)
lookup the first public IP in the received header b) lookup an abuse
address in the whois entry of the IP
- the ARF reports contained headers with garbled destination addresses
to hide spamtrap addresses
- trusted signers get ungarbled mails: there is an extended mode,
offered in http://service.dkim-reputation.org that allows the sending of
feedback to registered users (so we have some control). Currently just
Google and Yahoo! wanted to get ARFs from us.

Why using abuse-addresses from the whois? 'Cause I expected that sending
feedback to the signer of the message could mean that I directly help
spammers to do list-washing.

LESSONS LEARNT with this setup:
1) even abuse-addresses in the whois lead to spammers: one wrote an
email to me and asked why content is garbled. I explained that I want to
hide destination addresses. He said he sends identifiers in the email
body that shows the destination address to him, so he removed the
spamtrap address. Maybe as a consequence of this open feedback the
spamtraffic in the spamtraps dropped a bit so I decided to switch open
FBLs off in Jan 09.
2) even datacenter's abuse contacts just forwarded the reports to the
spammers
3) ISPs like earthlink.net with a high spam ratio didn't respond to our
offer to send them FBLs (I think they didn't understand the system,
professionality in abuse departments is very different)

CHANGED setup:
we just send ARFs to trusted, manually confirmed feedback addresses
(that were entered in http://service.dkim-reputation.org)

With this experience I think FBLs should be provided to a very coarse
granular entity on the network administration level. Some guys in our
email working group in Germany started http://www.abusix.de that sends
reports based on AS numbers. The according network administrators can
process ARFs (a) more professionally (b) are more likely farest away
from spammers (c) can escalate the processing internally if necessary
(d) would get more reports that can be aggregated and analyzed by
"significant peaks" (e) can take serious actions [McColo].

Best regards,
Florian

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Fri, 29 May 2009 17:37:55 +0530

> professionality in abuse departments is very different)

Earthlink's actually got a great team and pretty good spam levels.  I
guess though that a network in Germany would see a very skewed spam vs
ham distribution from them.

And again - for networks .. you might not know who to ask (do you
attend MAAWG regularly? if so you might have known who the people to
ask at Earthlink are .. they are very visible there)

> (that were entered in http://service.dkim-reputation.org)

This is what we do by the way - and have done for all the years we
have operated our FBL (we started just after AOL did, and were the
first to switch 100% to ARF loops)

We might consider tying feedback loops to dkim d= (and treat i= as a
component of d= in that sum of i= published under a d= will be the sum
of d= reputation) .. but even there we'd insist on out of band, vetted
contacts .. as we tie our fbl to a strong whitelist.

srs