oh noes. the listserv deded.
Started getting a series of these just now from the past. 
And yes, the headers reveal that they are indeed coming from the NANOG
listserv/MailMan.
Can someone please fix that? kthxbai.
- - ferg
- -------- Forwarded Message --------
Same here. The 821 headers show Received: to be "now", while the RFC
822 headers have a Date of first of <month> where Month started in
August 2017.
Suspect something got reset and the list server is just catching up with
the monthly reminders.
1. It's not a listserv. It's a mailing list. ListServ is obsolete,
expensive, closed-source garbage software used exclusively by people
who don't know any better and like to waste their money.
2. This problem was possibly, but not certainly, caused by a misfiring
cron job. (I've seen it before.) The list-owner(s) were probably made
aware of it almost immediately, because on a mailing list of this size,
there are always SMTP rejects of some small fraction of the monthly
reminders -- and this time, they probably arrived in batches of 16.
---rsk
Groundhog day AGAIN!
Lyle
Last night there was an update to the OS of our production environment, and a restart of the system. We are currently working to confirm all is functioning properly.
Apologies for the extra noise in the mail list.
Cheers,
Valerie
Valerie Wittkop
NANOG Program Director
Tel: +1 866 902 1336, ext 103
1. It's not a listserv. It's a mailing list. ListServ is obsolete,
expensive, closed-source garbage software used exclusively by people
who don't know any better and like to waste their money.
Butbutbut!
A VM/370 app that still does all internal processing in EBCDIC, even on
POSIX OSes[0], with almost-ascii config files, and that ran very well
on VMS? What is there not to love?
/MÃ¥ns, former sysop at SEGATE.SUNET.SE
Well Rich, your bias is obvious. Have you ever considered that in some
cases there's reasons it's used by people who don't agree with your assessment?
We recently completed a migration from Listserv to Google Groups. It took
us close to 3 years of planning and execution and well over 1 FTE/year, because
we had been running Listserv for well over 30 years, and there were a *lot*
of places where the way Listserv does things were embedded into business
logic or otherwise difficult to replicate/migrate.
One biggie - Listserv has this useful feature where you can say "people subscribed to
this *OTHER* list are allowed to post". One very large department had well over
100 lists for various things, and all 100 had "accept post from dept-admins@".
Worked really slick - if they create a new list, they just have to include that options.
If they hire new administrative staff, they just add that person to dept-admins.
Then there was the creeping horror for "class lists" - professors got a list for
each of their classes, pre-loaded with the roster of the class. When you have
35,000 students, that's a big bunch of lists. (Amazingly enough, I never *did*
get our ERP people deploy the Listserv feature of building subscriber lists
on the fly using an SQL query - which would have been another thing that
would be difficult to replicate (Hint: just doing an extract and doing a bulk
mailing is similar - until you try to make "Reply-to: Listname" work)
Don't ask how that works under Google Groups - it's another creeping horror
Now add in the fun of migrating the archives for 12,000+ lists, notify list owners
and users of the new addresses, etc etc etc, and suddenly the $4500/year doesn't
look so bad.
And you have reason to think that it *still* does things that way, 17 years later?
And you have reason to think that it *still* does things that way, 17 years later?
I honestly do not know, but I'd suspect so. More of a hunch than anything else, though.
It *was* very fast back then, though. Today, not so much of a competitive edge.