Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On Mon, Jun 22, 2020 at 6:58 PM Douglas E. Foster wrote: > [...] > Of course, adding additional voices may make the consensus problem more > difficult. What is your mechanism for resolving consensus problems? Are you familiar with RFC 7282? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
To the chairs: It has become clear that we do not have consensus on the issue of content-altering mailing lists. Despite the diversity of viewpoints the number of persons involve in the discussion is fairly small. Have you identified the stakeholder groups that should be represented in the DMARCbis process for it to be considered sufficiently representative? Have you made any assessment of whether all such groups are in some way represented in this discussion? Do we need to do some outreach to ensure that all stakeholder groups are involved Of course, adding additional voices may make the consensus problem more difficult. What is your mechanism for resolving consensus problems? Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/22/20 10:48 AM, Hector Santos wrote: > 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. If those were the only choices then no EDU would publish DMARC policies. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/22/20 6:23 AM, Alessandro Vesely wrote: > The fact that it cannot be set by a MUA implies Sender: already lost > its menial meaning. So it became a Mediator sort of thing. This list > sets it to "dmarc" . Does anybody use it, or > ever happened o take a look at it? Yes, and I assume that's partially why the OP (who I was posting on behalf of) brought this Sender dilemma up in the first place. Outlook on the Web displays: dmarc on behalf of dcroc...@gmail.com and for those domains that have DMARC policies dmarc on behalf of todd.herr=40valimail@dmarc.ietf.org Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/21/2020 3:44 PM, Douglas E. Foster wrote: Dave Crocker writes: The practical problem with From: field munging by MLMs that are otherwise trying to relay a largely-unmodified messages, is that they effective destroy author information, by putting in a different email address. This is helpful for identifying the three key stakeholder needs: 1) MLM's such as IETF want to alter the author's submission. 2) Authors like Hector want their submission left unmodified List Servers has historically modified submissions, the body and subject line. It is part of the "package" per se. Burned in. While problematic for DKIM, I doubt that will ever change. However, my only concern has been always with the RFC5322.From address rewriting kludge when done in a blind way. If the MLM is aware of DMARC, then it is intentional ignorant of a security protocol. While it may have been done in certain legacy distributions, it was not a common practice for List Servers to rewrite the 822/2822/5322.From field. What was "rewritten" was the return address for errors & bouncing back to the MLM list agent. A kludge is by definition (by Google) "an ill-assorted collection of parts assembled to fulfill a particular purpose." We ideally view a kludge as a temporary solution until a real fix is obtained. But as we have learned by practice, a kludge, a temporary solution left unaddressed, has a tendency to become permanent. So if the IETF is going to sanction this kludge, then we should get it officially IETF reviewed, documented, and not via some highly subjective wiki primarily authored by one person who believed this was the right thing to do without foreseeing the consequences. 3) Users like Dave want accurate author information in the MUA. There is no legal corollary for "largely-unmodified". If I use whiteout on a signed document, spill an ink bottle on hallf of the signature, or replace the special lawyer-only staples with standard staples, the document ceases to be trusted and is probably unenforcable. The nature of the changes made by the IETF mailing list renders the reverse transformation impossible, so there is no way to validate the transformed document against the original unless the original is obtained, yet the purpose of the transformatiin is to hide the original. A real solution has to eliminate this operation. Hector is right. Imo, the resigner performing the rewriting, SHOULD resign using a secured resigner domain with the same level protection sought by the original author domain. This would be consistent with the ietf.org only rewriting for domains with a p=reject|quarantine DMARC policy. It uses _dmarc.ietf.org for the rewriting domain. Since this _dmarc.ietf.org domain only exist for rewriting a p=reject|quarantine domain, it would be technically logical for _dmarc.ietf.org to also have a p=reject|quarantine policy as well. This includes using _dmarc.ietf.org for the return address to kept with the expected DMARC alignment. That will maintain the DMARC aligned protection for the original submission and resigner distribution. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
Hi, Le 21/06/2020 à 21:44, Douglas E. Foster a écrit : > > There is no legal corollary for "largely-unmodified". [...] Then what? An overwhelming majority of users need e-mail for day-to-day communication, not for binding legal contracts. "Largely-unmodified" as mailing-lists have been doing it for 40 years is good enough (we usually don't hear authors complaining that they were impersonated). People who need a high-integrity validation for each and every message before reading it are the minority. The rest of us would rather keep our communication possibilities unimpaired, even if it means dealing with a bit of spam and use cryptography or out-of-band checks for important business. Not to say that DMARC's validation is not valuable per se. But asking mailing-list (or other) users to jump through hoops to simply communicate as they have for 40 years is incredibly arrogant. Cheers, Baptiste P.S.: and no, "then don't use DMARC" cannot be the answer. Some time down the road, it will be forced on us by the large mailhosts, who have a business interest in curbing spam. So it'd better be done right. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
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
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 2020-06-21 7:32 p.m., Dave Crocker wrote: > On 6/18/2020 12:46 AM, Alessandro Vesely wrote: >> "Authoring" can have subtly different acceptations, though. The >> exact sentence is: >> >> The "From:" field specifies the author(s) of the message, >> that is, the mailbox(es) of the person(s) or system(s) responsible >> for the writing of the message. >> [https://tools.ietf.org/html/rfc5322#section-3.6.2] >> >> That is not so far from real. The term "writing" sounds ambiguous, >> as it is not clear whether it means "typing" or "publishing", in the >> case of public mailing lists. Given that Sender: is dedicated to >> the typist, I'd opt for the latter interpretation. > > In simple terms, author is the creator of the content and sender is > the agent for getting the content processed. The latter was > distinguished to provide a means of improving accountability if there > were problems. When SMTP was created, later, MailFrom was added as an > address for sending message handling reports. > > When first specified, Sender: was to cover the case of someone doing > the online work, on behalf of authors who weren't online, or at least > not online for processing the message. Back in those days, that was > not uncommon. Even if the author officially had an online presence, > they often did not do the typing. > > (To underscore this a bit: in most of the business world, knowing how > to type was deemed a menial, secretarial skill and not appropriate for > an executive. To carry this a bit further: around the time RFC733 was > developed, in 1977, I managed to get the person in charge of > department administration functions to authorize my getting a desk > with a right-hand return, where a secretary's typewriter would go, and > where I put my terminal. This was extremely unusual and the immediate, > similar requests from all the other staff like me were rejected. Also, > when I announced my departure, the next year, the admin was instantly > flooded with requests for my desk...) Thank you for sharing the above historic perspective. > [...] > > So, in abstract terms, if I go to a greeting card site and have it > send a greeting on my behalf, the From: field should be my own email > address and Sender: should an address at the greeting card company. > But I said 'abstract' because current realities mean this isn't as > useful an arrangement as the theory intended. Agreed. I'd derive it's time to revise the theory, however slightly. > I believe this is because Sender: is not reliably present. Hence, it > literally cannot be relied upon. The Sender field is not created > reliably to indicate such distinctions and the receive side does not > reliable note the distinctions. The fact that it cannot be set by a MUA implies Sender: already lost its menial meaning. So it became a Mediator sort of thing. This list sets it to "dmarc" . Does anybody use it, or ever happened o take a look at it? See below for an alternative arrangement. >> For a newspaper, if you pardon the analogy, the masthead is more >> visible than columnist signatures at the end of the articles. For a >> mailing list, publisher visibility used to be provided by subject >> tags, leaving the From: intact. Why? Presumably, because it just >> worked that way. However, if the MLM is the system responsible for >> writing, not modifying From: should be considered a violation. > > If a Mediator makes 'substantial' changes to a message, then it can be > considered a new and different message? Yes, but note that we have no > objective criteria for this. That's why I class this reference to > 'publisher' as a business issue rather than a technical one. (And an > ethical one, as some wayward journalists discover when they claim to > be quoting someone but it turns out the reporter invented the content.) You certainly recall the level of sophistication described in Nelson's Literary Machines. Email is nowhere near that precision, therefore we /have/ to relegate such issues to ethical or business ones. As you say, an add-on to check quotation authenticity would require access to the whole thread, and even then it wouldn't be trivial to get it done. > However I think that referencing the role of an MLM as 'publisher' can > be helpful to remind us that MLMs have their own agency and can, > legitimately, make all sorts of changes. Whether authors and > recipients like those changes is a non-technical matter. > > The practical problem with From: field munging by MLMs that are > otherwise trying to relay a largely-unmodified messages, is that they > effective destroy author information, by putting in a different email > address. > > In practical terms, today, the MLMs arguably don't have a choice. But > it still can be helpful to understand the problems created by this > alternation. IMHO, the choice is how to do rewriting given the constraint that the domain of From:'s addr-spec must match d= in MLM's signa
