[ietf-dkim] General Feedback loop using DKIM
michael.adkins at corp.aol.com
Wed May 27 13:57:44 PDT 2009
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
> 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
> 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?
More information about the ietf-dkim