[ietf-dkim] General Feedback loop using DKIM

[Franck Martin]

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.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. 

Only very large ISPs are offering FBL programs, and often they sub-contract the program to a third party. Could technology make it simpler for smaller ISPs and organisations with a non trivial amount of mailboxes? 

----- Original Message ----- 
From: "Suresh Ramasubramanian" <ops.lists at gmail.com> 
To: "Franck Martin" <franck at genius.com> 
Cc: ietf-dkim at mipassoc.org 
Sent: Wednesday, 27 May, 2009 11:49:23 AM GMT +12:00 New Zealand 
Subject: Re: [ietf-dkim] General Feedback loop using DKIM 

As Steve says the list-unsubscribe header works about as well as what 
you are suggesting .. if an ISP actually decides they want to 
implement this across the board and trust any list unsubscribe header 
that comes their way. Which is not particularly recommended. 

You typically contact an ISP out of band to apply for an FBL and 
whitelisting. And there is some crosschecking done before the FBL is 
set up. 

On Wed, May 27, 2009 at 4:06 AM, Franck Martin <franck at genius.com> wrote: 
> I'm curious to see if the feedback loop mechanism could be extended using 
> DKIM. The concept may have many issues, but I want to see if it is a stupid 
> idea, or if it would have some merit. 
> 
> The system would be for the sender to include in the dkim mechanism an 
> FBL-email: header wich would tell the receiving mail system where to send an 
> ARF email if the recipient hit the spam button. 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20090527/a1e8979d/attachment.html