[ietf-dkim] General Feedback loop using DKIM
steve at wordtothewise.com
Tue May 26 20:42:29 PDT 2009
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
> > > an organisation with a substantial number of users, like
> > > universities or small ISPs.
> > There are two difficult and/or expensive parts to offering a
> > 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
> > Compared to those two I suspect that working out where to send a
> > report, and actually sending it, are much cheaper parts of the
> 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
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.
More information about the ietf-dkim