=====
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
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.
Discussed below.
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.
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'.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html