On May 26, 2009, at 8:13 PM, Franck Martin wrote:
----- "Steve Atkins" <steve(_at_)wordtothewise(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html