John Levine wrote:
[ this is well trodden ground, so I will try and keep this short ]
Agreed, but the fact that it's a mailing list that is doing this
isn't significant. It could be any intermediary that is willing to
take responsibility for the message by signing it. Their reputation
now becomes a factor in the disposition of the message.
Right. As JD and others have often pointed out, mailing lists should
sign their mail like anyone else, and recipients handle it based on
the list's reputation. If we're going to encourage list operators to
change their software to deal with DKIM, sensible changes would help
them be sure that unwanted mail doesn't leak onto the list, perhaps
using DKIM and ancillary reputation systems. That will help all
subscribers getting mail from the list, whether they use DKIM or not.
So what you are saying is that LIST SERVER developers SHOULD NOT add
ADSP features to restrict signing of ADSP domain nor bother to see if
it should allow these restrictive domains to subscribe?
List name: ieft-dkim
DKIM/ADSP Options:
[_] Do not allow subscription from ADSP domains
[_] Do not accept domains with DISCARD, ALL policies
[X] Sign list mail:
[X] Remove any old signatures
Signing Selector: k00001
Signing domain : mipassog.org [ GENERATE KEY ]
[X] Checking Reputation Services
[ CLICK TO SEE REPUTATION SERVICE LIST ] None-Defined
A few milliseconds of thought should reveal that a scheme that allowed
a list to assert that incoming mail was signed would instantly be
abused by spammers who would start sending from "lists" that claimed
to be passing through signed mail from domains with good reputations.
hmmm so why do you want to tell developers not to support ADSP to
protect those domains from getting leaked into the network with
signing that should never happen in the first place?
You'd have to decide whether you trust the list, and if you're going
to do that anyway, just deliver the mail from people you trust like
you do for any other mail and you're done.
Where is this written in ADSP?
If the list server is blindly going to sign, can that be done
confidently that all RECEIVERS has decided not support RFC 5617 even
thought it exist to be implemented by receivers?
How does the list member tell his host to accept these RFC 5617
violations?
Do all the DON'T SUPPORT RFC-5617 Host systems now provide a Web Based
Application or Form to define the exceptions?
o User Email Settings:
[ Click Here to enter white listed lists names ]
Example entry form:
list-name: ieft-dkim
(_) Always accept
(o) Accept only if signed by domain: mipassoc.org
Is this the Levine Idea for a DKIM PRODUCT which everyone must do or a
widely adopted IETF standard protocol methodology based on voodoo
operators and hope?
This is all very simple john - If you don't want RFC 5617 to be used,
then either resign from further RFC 5617 and allow others to develop a
working protocol or support it and help the WG come to agreement by
all parties to finally get this done.
But I hope the we don't continue based on "HOPE" for non-RFC 5617 support.
Is it possible to take more than a few milliseconds, m2aybe about 5
mins, to thing more about what you are suggesting?
You are telling developers to IGNORE RFC 5617 and to continue to sign
mailing list with a total disregard that RFC 5617 may exist. Yet that
will only work if no receivers support RFC 5617.
How can you be sure that all list distribution downlinks:
- Are ignoring RFC 5617?
- Have added User Settings DKIM list server filter support?
Why so complicated? Why not get rid of RFC 5617 or update it?
--
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html