We tend to talk about legitimacy in contrast to malice or criminality, but in my economics classes, legitimacy was less pejorative. Gaining legitimacy meant gaining the social acceptance to continue operating. When a business gains enough customers to turn a profit, it has legitimacy. If it goes bankrupt, it is because it has lost, or never achieved, legitimacy.
When John says that list members plead their case, but their pleas are dismissed unsympathetically, it is evidence that mailing lists have a legitimacy problem. As with many social issues, there are extremes: AOL has unmoveably chosen security over list access. The EDU community has chosen list access over perceived security benefits. In the middle are people who might be convinced, but need convincing. These are the people that should be the focus of effort by mailing list advocates. A salesman friend has quoted the proverb that, "Nothing happens in our economy until somebody sells something." The mailing list advocates, which seem to be most members of this group, need to find a way to market better, to gain legitimacy with the middle ground that might be convinced. As an administrator of a business email system, I find myself in that middle ground. So here are the areas where I would like to be convinced: 1. Why is it necessary for mailing lists, in general, to modify content? RFC 7960 needed a companion document on this topic, When I read 7960, I was unmoved because my thought was, "Intermediaries should not be modifying content in the first place." There must be others who have the same response. I doubt that RFC 7960 changed any attitudes, because it never addressed the "why" behind the problem. 2. Even if I become convinced, in concept, that SOME mailing lists need to make SOME content changes, I would not conclude that ANY mailing list must be allowed to make ANY change, without limit. Before embracing a particular list, I would want to know the particulars of what changes that list makes, and why those changes are necessary to the success of that list. Isn't that reasonable? Are there any industry norms for this type of disclosure? If not, why not? If there are norms, why am I unable to find such information for this list? For this forum, I don't know what attachments are allowed, whether posts are subject to malware scanning, whether TinyURLs and their equivalents are allowed, or anything else related to participation security. I just checked the link at the bottom of every message, and it contained nothing about these topics. 3. Assuming that the first two objections are overcome, the last one remains critical. Acceptance of broken signatures will mean that I delegate responsibility for sender authentication from myself to the list server. Can the list under discussion be trusted to ensure that both MailFrom and From are free of deception? Given my assumption that we are talking about closed lists, this should be feasible. Ale's abuse demonstration was a deal breaker for me, because it demonstrated that this list cannot be trusted with delegated responsibility for sender authentication. What will be done to restore my trust in this list? What can be done to ensure that trustworthy sender authentication is the industry norm, rather than the exception? When I can trust the list to authenticate every post, I don't need to detect and parse an ARC set on every message. If I can only trust messages with DMARC PASS in an ARC Set, then I will never be able to accept more than a subset of all messages sent to me by a list server. As much as I hear the felt pain of mailing list advocates, I find the list industry to be woefully deficient on all three of these topics, and I see no movement to address any of the three. If list advocates want to increase legitimacy with people in the middle ground, these issues need to be addressed. Without it, I do not believe your language choice between "MUST NOT", "SHOULD NOT", and "should not" will make any difference. Doug Foster
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
