Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

>> http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED If you look at the DKIM configuration files, you'll see that the ADSP usage is almost entirely faked up, via a list of entries for the usual phish targets (ebay, paypal, etc.) to pretend that they have ADSP records: http://svn.ap

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

This might be the right thing to do, but it seems like the more appropriate time might be to do this when DMARC becomes standards-track. I will note that vanilla, uncustomized SpamAssassin does implement ADSP, so there might be more checking of ADSP records than some realize. See, for example:

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/11/13 8:18 PM, MH Michael Hammer (5304) wrote: > > I think you need to look more closely. Many people realized very quickly that > ADSP had significant flaws that made implementation extremely risky for both > senders and mailbox providers. There were a number of private efforts to move > e

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

I'm a bit late here; sorry: IESG telechat day, so things were very busy. On Wed, Sep 11, 2013 at 9:41 PM, Michael Thomas wrote: > It doesn't help that ADSP's author actively wanted to subvert it. > > As far as I can tell, DMARC is warmed over ADSP with a different set of > participants to claim c

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas wrote: > The list of things DMARC does that ADSP doesn't in its appendix, is a trip > down memory lane > of constraints that were placed on it by the > against-it-before-they-were-for it set. True > SPF wasn't ever on its radar -- SPF has its own po

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/12/13 12:28 PM, Dave Crocker wrote: > On 9/12/2013 12:20 PM, Jim Fenton wrote: > >> I will note that vanilla, uncustomized SpamAssassin does implement ADSP, >> so there might be more checking of ADSP records than some realize. See, >> for example: >> >> http://wiki.apache.org/spamassassin/R

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

> If anyone has technical comments, data collection, or any other stuff > that's relevant to the ADs' judgment of whether moving ADSP to > Historic status is the right thing, those comments are welcome here. ... > Discussion of ADSP *ONLY*. No discussion of DMARC. No discussion of > people. No s

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/12/2013 3:28 PM, Dave Crocker wrote: > > There seems to be a pattern that has developed, of demanding that > failure mean literally no adoption. It doesn't mean that. It means > that it has no community traction. ADSP more than qualifies on the > pragmatics of failure. > > d/ > The pragmat

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/12/13 12:10 PM, Murray S. Kucherawy wrote: > On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas > wrote: > > The list of things DMARC does that ADSP doesn't in its appendix, is a > trip down memory lane > of constraints that were placed on it by the > against-it-b

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/12/2013 12:20 PM, Jim Fenton wrote: > This might be the right thing to do, but it seems like the more > appropriate time might be to do this when DMARC becomes standards-track. 1. There is not going to be any change the adoption of ADSP between now and then. 2. I don't see any obvious reaso

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

Dave, On 9/12/13 1:52 AM, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on > the dmarc@ietf list, please now lodge any formal comment