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:[email protected]?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

Reply via email to