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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html