[ietf-dkim] General Feedback loop using DKIM

[Steve Atkins]

On May 26, 2009, at 8:13 PM, Franck Martin wrote:

>
> ----- "Steve Atkins" <steve at wordtothewise.com> 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