John R. Levine wrote:
>
>> Shorter summary: The WG charter says there should be
>
> Yes, there was considerable naive optimism in the charter.
>
> We all agree that it would be great to have a scheme to spoof-proof mail.
> But ADSP isn't it, for the reasons we've all gone over,
which were?
> no matter how much we might wish that it were.
-1. The only wish I have is that stop injecting misinformation.
Any domain that publishes a DKIM=DISCARDABLE and for any receiver that
supports ADSP will immediately protect the Author Domain and the
receiver system from further abuse from:
1) ALL legacy (non-signed mail) DOMAIN spoof attempts at
the receiver.
1) All 3rd party signed mail NOT EXPECTED by the Author Domain
regardless if its was a malicious reply or a stupid list
server ignoring RFC 5617.
Both are huge immediate payoffs for the domain and receiver. To deny
this high benefit is being intentionally ignorant.
> I can assure you that Paypal and eBay are quite aware of DKIM and ADSP,
> and I have personally heard them encourage ISPs to drop unsigned mail
> purporting to be from them due to the amount of forgery. Nonetheless,
> they don't publish ADSP.
Well, maybe if the WG can get a true champion of POLICY and not one
that selfishly took over SSP with the sole clever confessing purpose
of creating a non-working protocol poison pill, then could change.
No one can take any POLICY opposition serious from one that author's a
document he doesn't support.
Your input is extremely bias and a conflict of interest to the WG
participants who have interest in seeing a POLICY system work.
But you know, I don't blame you. I blame the CHAIRS for allowing this
to occur. It is surreal! It is completely wrong to have you as the
author of a draft standard you don't even want PEOPLE to support.
Is that crazy or what?
> This tells me that I'm not the only one who
> thinks that there isn't a business case for ADSP.
Thats crazy!
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
