On 2022-06-20 at 23:25:49 UTC-0400 (Mon, 20 Jun 2022 21:25:49 -0600)
Rob Nagler via mailop <[email protected]>
is rumored to have said:
On Mon, Jun 20, 2022 at 12:17 PM Bill Cole wrote:
Which part?
"That form of mailing list was already dying out 20 years ago"
I don't think people were rewriting From: or envelope from at that
time.
They were managing bounce addresses.
Rewriting header and envelope addresses is as old as Sendmail.
I'm mystified by your distinction between rewriting the envelope sender
and "managing bounce addresses."
To test my conjecture, I downloaded mailman-2.1.15 (2012-06-15) and
didn't
find any "via" handling. I picked mailman-2.1.19 (2015-02-28), and it
handles DMARC, but it seems to wrap messages in another message, and
doesn't do From rewriting (cursory glance).
In any version, it never sends a list message out with the same envelope
sender that it arrived with. The same is true of majordomo, LISTSERV,
ezmlm, Lyris, and every other ML package I've used in the past 30 years
and I expect also of those I've not used.
Which was the point I was making: SPF does not cause problems with
mailing lists, because they use their own domains in envelope sender
addresses.
I looked at mailop's history, and it
was a simple reflector in 2018, less than 5 years ago.
Not true. See Graeme Fowler's message.
I apologize if I slighted Graeme or anybody else with the word "simple
reflector".
I meant that there wasn't any From rewriting 5 years ago. I would like
to
change that to 10 years ago, but it's certainly not 20.
True for this list, and broadly true unless you count the NP-complete
language used in sendmail.cf since at least v5 which does nothing but
rewrite addresses... :)
And it is generally true that software designed to accept messages via
SMTP at a public list address and redistribute them to a mailing list
mostly didn't mess with the From header address until meaningful DMARC
enforcement reared it's ugly head ~5 years ago.
[...]
There arguably *IS* an issue with still running Mailman 2.x in 2022,
but
that's a very special case of hard-to-upgrade software.
This was my main point, really. Mail is becoming much more complicated
to
manage and to implement.
True. In the specific case of Mailman the upgrade impediment has nothing
to do with mail per se, but the general point is valid. It is especially
painful to stand up new mail systems that have to talk directly to the
world.
Add to this "reputation" and other opaque
barriers, which are just "hard-to-upgrade" peerings. The standards are
making things more complicated (and confusing) while skirting the
primary
issue which is a public trust system.
Because a "public trust system" is either impossible or at least
resembles an impossibility.
There's no universal agreement on the specific outline of acceptable
behavior regarding mail. So while we have a somewhat working toolset for
authentication grounded in the single-root DNSSEC tree and a
quasi-consensus on X.509 roots, there's no consensus on the shape of any
authorization layer.
--
Bill Cole
[email protected] or [email protected]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
