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(_dot_)example(_dot_)customer(_at_)returnpath(_dot_)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/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html