On May 26, 2009, at 5:22 PM, Franck Martin wrote:
list-unsubscribe: header is a free field and often contains a url
rather than an email address:
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>,
<mailto:ietf-dkim-request(_at_)mipassoc(_dot_)org?subject=unsubscribe>
This could be a candidate, but would need may be some more specifics
and codified in an RFC. I'm not sure it is today. I cannot recall
exactly to have seen it codified in any RFC.
RFC 2369. It's defined to typically contain one or more URLs, usually
mailto:. Something that handled solely mailto: automatically would
handle all the forms I recall seeing, though (optionally) punting to
the user for http: and https: if there were no mailto: would be an
obvious thing to do. If there were interest in supporting it at the
MUA level it would not be difficult to do the non-UI parts of the
support needed.
It's widely deployed by senders, especially smaller senders, today,
but has less support at receivers.
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.
Cheers.
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html