ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] General Feedback loop using DKIM

2009-05-26 20:54:21

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