[ietf-dkim] General Feedback loop using DKIM

[Michael Adkins]

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.example.customer at returnpath.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/
>
>