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 '[email protected]'. 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
