What do you conclude from this itemize list (which I *personally*
happen to believe are true, but also recognize it is not exclusively
true) from a design product development implementation standpoint?
Is this a feasibility study?
I'm interesting because we are very active right now in implementing DKIM.
See incline comments.
John R. Levine wrote:
I think these all should be non-controversial. Let me know if I'm
mistaken.
1. The overall amount of mail sent through discussion lists is small
relative to direct (person-to-person) mail or to broadcast (one-to-many)
mail.
Relative. I seen it shift go back and forth. For example, we have a
list support list (1 to many) and platinum/priority support (1 to 1).
It shift as to the amount. I would like to focus on using DKIM for
that later first beyond anything else, but in reality a list is really
a kludge for a 1 to 1 (i.e. the delivery is still 1 to 1)
2. Lists do a good enough job of managing the mail that they forward that
recipients generally do not worry about spam filtering mail from lists to
which they've subscribed. (Bozo filtering of legit but stupid messages
doesn't count as spam filtering.)
+1, a managed list does a good job of not allowing non members to
post. Filtering is done at a prior level, i.e. SMTP receiver.
However, we need to make sure that no IETF standard restrictive policy
is allowed to submit or subscribe - that will be our implementation.
3. The most common way for spam to get into a list in recent years is for
a subscriber's account to be stolen by a spammer who sends spam to
addresses in the account's address book.
+1. Compromised users are always a problem - at any level. IMO,
focusing on this is at a different level.
PS: I'm attempting to describe the way lists work now, not the way they
might work at a hypothetical future time.
+1, but if one is going to consider adding something new (DKIM) to a
25+ years legacy software like a list server, then one needs to
consider all the related hypothetical issues now and into the future.
While it might be feasible for some to not consider something, others
are more proactive about product development that server others other
than themselves and need to study it and ask the question "Are we
ignoring a potential issue? Maybe my system is fine, but what about
others? What is best for me, best for others?"
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html