[ietf-dkim] General Feedback loop using DKIM
michael.adkins at corp.aol.com
Thu May 28 07:39:52 PDT 2009
> 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.
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.
> 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.
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'.
> 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
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.
> 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?
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'.
More information about the ietf-dkim