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 comments you
On 9/12/13 12:10 PM, Murray S. Kucherawy wrote:
On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas m...@mtcc.com
mailto:m...@mtcc.com 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
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 reason
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 pragmatics of
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
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:
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 m...@mtcc.com 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
On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas m...@mtcc.com 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
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:
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:
10 matches
Mail list logo
