ietf-dkim
[Top] [All Lists]

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

2009-05-27 17:02:38
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
'arf(_dot_)example(_dot_)customer(_at_)returnpath(_dot_)com'.


Dave CROCKER wrote:
Al Iverson wrote:
  
Allowing a sending entity to determine a destination for FBL reports
by embedding that information in a message header implies trust of
that sender. 
    
...
  
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. 
    


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/

  

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