The unofficial responses to which are:

      Which is less hot? (tourist)

      Which is hotter? (local)

      Which is better today? (foodie)

      On the side. (wimp)

      Christmas! (wiseass)

      It was yellow when I went through it, officer,
      and three other cars came through behind me! (local)

The question:

        Red or Green? (chile, not political affiliation.)

... where you always find things sort of like what you really wanted.

Way to go, citizens. March on!

Most of the services available through state or other BAs and other
industry groups are not necessarily "endorsed by" those groups or likely
to be better than other solutions.

I wouldn't expect an affiliation or mention of any kind to indicate
anything more than something like "their sales team got here first"
and perhaps "and offered us some kind of good deal".

IANAL. YMMV. Place on ground, light, retreat. :-)

If the mailing list does not set the value of Reply-To to the list address,
and the recipient's MUA clients honor the 'Reply-To' header, then:

        Reply-To: nobody@state.gov

where 'nobody' is a mailbox connected to /dev/null
(or to a file, as needed, for gummint archive requirements)
is a reasonable choice for an "email to all" announcement.

Add a "do not reply" tag atop the message body to head off those who
would send a carefully drafting reply, and let the clue-resistant
recipients send all the "take me off this list" messages they want.

Otherwise, surely some mailing list manager packages offer as a option a:
"messages to more than L lists or U users must be approved by list admin(s)"
feature?

After my last round of wrestling with video drivers,
I'd settle for a multi-step process:

        install new distro
        plug in all optional hardware, devices, whatever
        boot an 'inventory' kernel
        mount all desired file-system types
        start any unusual drivers or processes

        direct 'inventory' kernel to
                "detect and configure the options as needed"
                        for all the hardware or other configuration
                        sensitive stuff that is visible, mounted, etc.

        manually tweak kernel config if needed
        compile new kernel & any modules needed
        boot to new kernel
        enjoy

I'd settle for any method that lets the non-kernel-guru
user focus on the few config items that might need
changing, instead of facing 2900-odd CONFIG_ variables,
many for obscure hardware that won't be found in most
systems. Yes, the settings need to be available for
people who do have that hardware, but they should not
require decisions by people who do not have that hardware.

To put that in a way more Slashdot readers might remember,
I'd like a tool or specialized kernel that could determine
from the hardware, without having to poll the user,
the appropriate settings for:

        CONFIG_ATHLETIC_JOCK_STRAP=

        CONFIG_ATHLETIC_SPORTS_BRA=