On 10/3/2013 6:25 PM, Douglas Otis wrote:
On Oct 3, 2013, at 1:37 PM, Barry Leiba <barryleiba(_at_)computer(_dot_)org>
wrote:
To both Doug and Hector, and others who want to drift in this direction:
As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we do or
don't do with DMARC. Bringing DMARC into the discussion is a
distraction, and, worse, makes it look like there's a tie-in. There
is not.
Dear Berry,
Even John Levine the author had opine along these same lines. The response to
Hector was agreeing a reason should be given, along with agreeing with his
justifications. The tie-in may be limited, but nevertheless DMARC has become
the chosen alternative. It seems if any reasons are given for moving ADSP to
historic it also should conjecture why DMARC and not ADSP, unless your point is
nothing has been learned?
Doug, the whole problem was the middleware, the mailing list software
or the 3rd party resigners who were either not supporting DKIM,
ignorant of policy protocols and/or that did wish to have any 1st
party domain controls dictating what mail can be resigned or not.
If DMARC is the "chosen alternative" we are still repeating the same
related issues with this Author Domain Domain Policy Protocol as well.
The mailing list software needs to support this otherwise we still
have the same problems as with ADSP. In short, a subscriber to a list
using a DOMAIN that is DMARC restrictive will also have a potential to
cause automated unsubscribe events to members with DMARC compliant
receivers supporting the DMARC restrictive policies. Same thing as
with ADSP, just change the protocol name.
Keep in mind that DMARC promises to offer better ADSP or as it
documents "Super ADSP," in fact it outlines what seems to be the short
comings of ADSP:
http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#appendix-A.5
A.5. Issues With ADSP In Operation
DMARC has been characterized as a "super-ADSP" of sorts.
Contributors to DMARC have compiled a list of issues associated with
ADSP, gained from operational experience, that have influenced the
direction of DMARC:
1. ADSP has no support for subdomains, i.e., the ADSP record for
example.com does not explicitly or implicitly apply to
subdomain.example.com. If wildcarding is not applied, then
spammers can trivially bypass ADSP by sending from a subdomain
with no ADSP record.
2. Non-existent subdomains are explicitly out of scope in ADSP.
There is nothing in ADSP that states receivers should simply
reject mail from NXDOMAINs regardless of ADSP policy (which of
course allows spammers to trivially bypass ADSP by sending email
from non-existent subdomains).
3. ADSP has no operational advice on when to look up the ADSP
record.
4. ADSP has no support for using SPF as an auxiliary mechanism to
DKIM.
5. ADSP has no support for a slow roll-out, i.e., no way to
configure a percentage of email on which the receiver should
apply the policy. This is important for large-volume senders.
6. ADSP has no explicit support for an intermediate phase where the
receiver quarantines (e.g., sends to the recipient's "spam"
folder) rather than rejects the email.
7. The binding between the "From" header domain and DKIM is too
tight for ADSP; they must match exactly.
We must consider that the requestor for the ADSP status change has
also authored a DMARC "BCP:"
Using DMARC
http://tools.ietf.org/html/draft-crocker-dmarc-bcp-01
This draft only mentions ADSP once, and very briefly:
10. Interaction Issues
Some issues come into play when DMARC is used in conjunction with one
or more other services.
o Sender using both DMARC and ADSP
Ok, like what?
Lets try to get the issues straight. We are talking about dropping
work that is already active in replace of some "super-ADSP" protocol.
Can we get it right please?
--
HLS