Mailman and Sympa seem to tbe the popular open source list managers.
LISTSERV is an expensive commercial product and is I gather popular
among users who have money to pay for an SLA.
Thanks, I've reached out to all three and will report back.
This exchange does not read right.
Decisions like this should not be made on the basis of open source,
nor commercial. The magical Pareto margin with just those three
mentioned may not be reached. There are others out there that may not
be represented in this group, and there are those like my own
commercial add-on product line, Wildcat! List Server, which does come
with an optional SLA and it should not matter if it does or not, a
smaller entity but has been "around" far longer than most except ListServ?
https://secure.santronics.com/products/winserver/wcListServer.php
I provided a guideline to a MLS approach back in the 2006 DSAP proposal:
https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3
3.3. Mailing List Servers
Mailing List Servers (MLS) applications who are compliant with DKIM
and DSAP operations, SHOULD adhere to the following guidelines:
Subscription Controls
MLS subscription processes should perform a DSAP check to
determine if a subscribing email domain DSAP policy is restrictive
in regards to mail integrity changes or 3rd party signatures. The
MLS SHOULD only allow original domain policies who allow 3rd party
signatures.
Message Content Integrity Change
List Servers which will alter the message content SHOULD only do
so for original domains with optional DKIM signing practices and
it should remove the original signature if present. If the List
Server is not going to alter the message, it SHOULD NOT remove the
signature, if present.
I have since then employed a very simple first item, Prevent
Subscription, added preventing submissions from restrictive domains
and avoided the more complex, integrity change part.
I understand there are those who want to bypass the DKIM Policy
security to be able to blindly resign any domain regardless of the
submission's direct mail policy. But my take is, if a MLS is going to
"change" then we should recommend to consider the preemption approach
by simply honoring the policy.
I hope to read from the report those 3 packages are willing to offer
the option to prevent restrictive domains. Even if rewriting remains
as an IETF "sanctioned" option (I hope not), the recommendation should
suggest a SHOULD to incorporate it as an authorized permission concept
with the subscriber:
Your domain has a restrictive DMARC policy. Here are your options:
1) Use another non-restrictive domain,
2) Prevent your domain from subscription and submission, or
3) Authorize the Rewriting of your secured domain to a secured
resigner domain.
Thanks
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
