On 12/18/2021 10:17 AM, Phillip Hallam-Baker wrote:
Mailing lists are not well supported by SMTP and never will be. Any discussion of how to make mailing lists work better has to begin with the acceptance that they will never work very well which is what most people have been arguing in this thread.
SMTP is a transfer protocol. It does not know about mailing lists and doesn't need to. (There is text in the SMTP spec about mailing lists, but really the text has nothing to do with SMTP, per se, and not a lot to do with the operation of mailing lists.
Mailing lists are user-level processes that sit at a layer above SMTP.
Rather than seeing mailing lists as they work today as the pinnacle of evolution, we should see them for what they are, a rather disgusting hack that we never got round to fixing.
Can't say I've ever noticed anyone suggesting that mailing lists are the pinnacle of anything. On the other hand, efforts to produce more interesting capabilities that aren't centralized have not gotten much traction. One keeps hoping, but field experience is not encouraging.
Why is it assumed that the input to a mailing list is an SMTP email? That seems to me to be a rather narrow assumption.
Not everyone makes that assumption. That said, where is the spec for the alternative and who supports that spec?
Once we recognize that the inputs and outputs from 'mailing lists' can be through other transports than SMTP, all arguments about preserving 'original' headers collapse. This is not an interaction between an SMTP sender and receiver, the mailing list itself is a principal.
When playing in the sandbox of a particular set of specifications, then it's fine -- actually it's essential -- to specify requirements such as information preservation.
If the point is that mail can transit heterogeneous environments, with different semantics, then the fact of that difference ensures information loss. Absent that assurance, why shouldn't the information be preserved, no matter how it is transported? That is, after all, one of the benefits of distinguish the message object specification from the message transport specification.
Apologies. I've probably entirely missed your point. d/ -- Dave Crocker dcroc...@gmail.com 408.329.0791 Volunteer, Silicon Valley Chapter Information & Planning Coordinator American Red Cross dave.crock...@redcross.org
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
