My analysis is rather different but comes to a stronger statement of John's point.
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. That does not mean that we should not attempt to make changes but it does mean that any changes should be considered through two lenses, not just one. First 'will this make mailing lists a bit more tolerable', Second, 'will this help a successor technology work better'. 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. 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. I am typing this into Gmail, why assume that my HTTP transaction must be mediated by an SMTP transaction to reach a mailing list user? Why should 'mailing list' necessarily involve SMTP at all? 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. I am of course aware that you can read IETF lists via IMAP, NNTP etc. In the short term, those efforts are being hobbled by the lack of decent clients. If the Web 4.0 folk get somewhere with a new generation of user centric social media, that might change. On Sat, Dec 18, 2021 at 12:15 PM John Levine <[email protected]> wrote: > It appears that Jeremy Harris <[email protected]> said: > >On 18/12/2021 03:47, Douglas Foster wrote: > >> MX checks are a valid tool for assessing SMTP MailFrom addresses, since > the > >> sender is supposed to be ready to accept non-delivery reports and other > >> automated messages. Of course, this has applicability if (but only if) > >> the RFC5322.From domain is the same as the RFC5321.MailFrom domain. > > > >I disagree. It is well-established practice for a mailing list manager > >to accept and process NDRs accepted on the 5321.mailfrom (which differs > >from the 5322.from). > > Jeremy is right. Mailing lists always, and I mean always, put their > own 5321 bounce address on the messages so they can do bounce > management. If you look at the mail from this list, the bounce address > is [email protected]. > > I have to say I am dismayed that we are spending time dealing with such > utterly basic misconceptions here. > > R's, > John > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
