Re: [dmarc-ietf] Mediation
On Sun, Jun 21, 2020 at 6:07 PM John Levine wrote: > In article > you > write: > >Apart from Mailman, what would be a reasonable set of MLMs to > >approach? I don't need a universal set here, just enough to get us to > >at least what we are pretty sure would be 80% or better of the active > >modern use cases. > > 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. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
In article you write: >Apart from Mailman, what would be a reasonable set of MLMs to >approach? I don't need a universal set here, just enough to get us to >at least what we are pretty sure would be 80% or better of the active >modern use cases. 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. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On 6/21/2020 4:35 PM, Murray S. Kucherawy wrote: Armed with such a list and a plan, I can see what the IRTF Chair thinks of the idea. cool! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Mediation
On Sat, Jun 20, 2020 at 1:24 PM Dave Crocker wrote: > Perhaps if the effort were viewed as a staged sequence, over an extended > time. Staging along the lines of: > > Document a modest number of highly common 'patterns' of mailing list patterns. > * Get reasonable community support (rough consensus) for the document -- > including from MLM developers and operators > * Formulate survivable authentication choices > * Get reasonable community support for that approach I'm curious enough (and have been since the discussions that led to draft-kucherawy-dkim-transform-00 five years ago) to give this effort some energy orthogonal to what this working group is doing, and with minimum distraction. Apart from Mailman, what would be a reasonable set of MLMs to approach? I don't need a universal set here, just enough to get us to at least what we are pretty sure would be 80% or better of the active modern use cases. Armed with such a list and a plan, I can see what the IRTF Chair thinks of the idea. -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
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 unmodified3) 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.MLMs could compare a submission against their screening criteria and reject submissions rather than transforming them. IETF wants text-only subnissions. Why not simply require text-only? Because we have a MUA problem: Some MUAs, including the one I am using, do not provide an option for sending text on ly. Fix tbe submitter MUA and you eliminate the need for MLM reauthoring.The recipient need is ironic. We have established that the MUA's handling of From is unimportant as it has no effect on user behavior, and Dave has been forceful on this point. But now Dave and others argue that From rewrite is a problem because it reduces the usability of the MUA. The two positions need to be reconciled.However, the upshot of this issue is that From rewrite creates a MUA problem and it can be solved with MUA changes. I have previously reported that my 3 MUAs present the IETF header information in 3 different ways. This is ripe for standadization, and the header rewrite objection can be addressed during that process.So we have two MUA problems. Fixing the latter one provides a quick fix while header rewrite continues. Fixing the former one and changing MLM behavior will take a little longer, but provides a high-integrity end result over time.IETF also applies Subject tagging, which breaks DKIM signatures. There are altetnatives for this as well, largely involving MUA tweaks.DF___ 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/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...) For most email, From: and Sender: are the same person (and the same email address.) This fact was the reason the original specification of Sender: in RFC 733 only required an explicit Sender: field be present when the addresses are different. For today, these same abstract constructs have -- or should have -- only slightly different application. From: is still supposed to be the author, which remains the creator of the (original) content. Sender: could be any separate party responsible for processing the message. 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. 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. 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.) 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. My understanding of the meaning that DMARC added was, "The author of this message, as expressed in the From: field, always has their messages properly signed by the domain in the From: address." You seem to be saying that, no, what DMARC did was changed the semantic to be, "The From: field now represents the transmitter of the message (as used to be expressed in the Sender: field when present), not the author, and that transmitter always has their messages properly signed by the domain
