On May 26, 2009, at 8:13 PM, Franck Martin wrote: > > ----- "Steve Atkins" <[email protected]> wrote: > > > > On May 26, 2009, at 5:15 PM, Franck Martin wrote: > > > > > It is also very heavy to have a FBL program this is why only a few > > > ESPs offer feedback loops. I'm not sure it is something feasible > for > > > an organisation with a substantial number of users, like > > > universities or small ISPs. > > > > > > There are two difficult and/or expensive parts to offering a > feedback > > loop. They are the development costs of implementing some sort of UI > > to capture feedback from the user (easier on webmail platforms, but > > still not trivial) and the ongoing support costs of managing a > > relationship with the senders who receive your feedback loop > reports. > > > > Compared to those two I suspect that working out where to send a > > report, and actually sending it, are much cheaper parts of the > system. > > > > Well you define the 2 difficulties: > 1) Development costs of implementing a UI > 2) Relationship with the sender > > 1) if there is a standard, developpers can implement it in MUA and > MTA so they are compatible. say MUA forward the complete email to a > special mailbox on the MTA, and the MTA process it. Not sure if it > is a valid/possible implementation, but that one that comes to mind.
If you're just using it for FBLs then there's no need at all to get the MTA involved. If you also want to use it for other things (tuning spam filters, whatever) then that's a rather different scope as the MUA will need to communicate with an entity other than the sender. > 2) if properly DKIM validated then there would be no need to define > an out of band relationship with the sended. DKIM with a special > protocol should be able to establish an inband relationship. Sender > puts in the email that is wants to receive FBL, reciever evaluates > if the sender request is valid and then process it. Not at all, no. In an ISP scope the out of band relationship with the sender is not optional, even if you buy into the self-publication approach completely. Try ignoring their emails if you don't think that's so. :) If it's an ad-hoc thing done just by end users then that's less likely to be an issue, perhaps. > > May be I should move this thread in ASRG? As dkim would provide > validation/trust but not everything. That's a pretty bad place to take it. I'd guess that talking to MUA developers would be the sensible next step to work out whether it's worth pursuing or not, as they're the people who are going to have to implement it. I think that you're right in it not really being a DKIM thing, though. > > Overall, the list-unsubscribe processing could not be done, because > we could not trust any of the email headers until we had a trust > mechanism with DKIM. I don't see any failure mode there, really, with the (minor) exception of someone being able to route FBL reports to a third-party. So adding a DKIM signature doesn't really add any value. If the List-Unsubscribe method is used solely to route feedback to the sender then there are two cases: 1) The sender wants to receive that sort of feedback and intends to act on it. 2) The sender doesn't want to receive that sort of feedback, or doesn't intend to act on it. The sender is in complete control of the value of that field. If the sender wants to do (1) then they can do so with or without signing the field. Similarly, if the sender wants to do (2) then they can do so with or without signing the field. There doesn't seem to be any value to an intermediate party to modify the field to prevent feedback reports or unsubscription requests from reaching the original sender, or even any scenario like that that isn't implausibly contrived, I don't think. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
