[conspire] PenLUG this week - Gumstix - Thursday Feb 22

[Rick Moen]

Quoting Paul Reiber (reiber at gmail.com):

> What's REALLY at the heart of this particular problem?

In brief, the fact that one _wants_ mailing lists to behave the way
NNTP newsgroups do.  Unfortunately, the software and protocols don't
support that.  More later.


> I can't quite see how bouncing emails [...] occur more often or are
> somehow made worse by cross-posting.  

Users 1, 2, and 3 are on mailing list A.  Users 3, 4, and 5 are on
mailing list B.  User 3 makes an informational cross-post.  He/she 
innocently and honestly expects nobody to reply, since the posting is
just informational.  Unfortunately, user 5 doesn't happen to see it that
way, and does Reply-to-All, maybe drifting the topic because he/she
spotted something amusing and wanted to post a comment about it: 

  To: A, B, 3

Mailing list B processes 3's post, preserving the To: header during
retransmission.  Mailing list A does either of two things, depending on
how it's configured:

o  If it allows non-subscriber posting, it broadcasts 3's reply post to
   mailing list A, with To: header intact.  You now have the beginnings of
   a noisy two-list discussion.

o  If, as is more common, it blocks non-subscriber posting, 3's post is
   held for list A's listadmins' scrutiny.  Those poor-bastard
   listadmins will likewise be bothered to vet _every_ single subsequent
   followup post from users 4 or 5.  (The same slow petty torture will, 
   symmetrically, be visited upon B's listadmins every time users 1 and
   2 respond.

To worsen this situation, imagine that the lists have slightly different
focusses:  instant culture clash.  To worsen it further, imagine that 
each of the lists has 50 or 100 posters, instead of three.

Imagine that one or two of those 50 or 100 are having a bad day, and
start responding crankily to a sudden big burst of traffic, mostly
involving people they don't know.  Who are these people, and why are
they suddenly clogging my mailbox and barging into my community
mailing list?  So, the cranky people reply... crankily, and suddenly you
have a crossposted flamewar across a suddenly and unexpectedly huge
composite group of 100-200 people who've in effect been shotgun-married
into that composite against their intention.

And believe it or not, some flamewars get started just from the traffic
levels:  People will often respond angrily when they start getting
mailing list traffic from mailing lists they aren't part of:  (If they'd
wanted that other list's mail, they'd have subscribed to that list,
dammit.)

Improbable?  I've seen it happen, over and over.  The demise of
non-subscriber posting makes it happen less, these days -- but now,
instead of pissing off people on another mailing list, each responder
pisses off the other list's _listadmins_.  And that's not really
healthy, either.

(Because of the way repeated Reply-To-All responses accumulates
addresses of individuals as well as of lists, individuals on A may start
getting direct-reply copies of responses from B people even where
neither mailing list itself passes through non-subscribed posts.)

This is why, based on my long experience as a listadmin, I politely
suggest that people multipost across newsgroups rather than crosspost,
as the latter tends to cause problems.  (As a reminder, I'm _not_
speaking with my conspire listadmin "hat", here.)


By contrast, on groups of NNTP newsgroups (such as those that comprise
Usenet), multiposting is strongly deprecated:  You are advised to
_please_ crosspost your articles (what posts are called in newsgroups)
instead of multiposting, if you must address multiple groups.  Why?
Because of the way NNTP newsreader software deals with the two cases:

o  With a crosspost, the user's newsreader will treat the post as "read"
   in all groups in the Newsgroups: header, the instant the user 
   encounters and reads the article in any of them.  

o  With a multipost, the user first sees your article in rec.aquariums,
   and _then_ encounters it again in soc.culture.finland, and _then_
   plows through the copy you posted to alt.os.linux.suse.  By the
   time he/she sees it a fourth time in rec.arts.sf.written, he/she
   is mondo pissed.


> Digging into this... is a cross-post with a well formed "reply-to"
> header field somewhat better than one without that header field?

No.  Reply-To: doesn't work the way you think it does.  It's a sign
saying "Please send any direct replies to alternate address Foo, 
instead of to the one in my From: header."

In the above example, imagine initial user 3 sets "Reply-To: Foo" 
when he/she does "To: A, B".  Then, user 5's MUA, when he/she does 
Reply-To-All, _if_ it honours the Reply-To:, will do this:

  To: A, B, Foo

instead of

  To: A, B, 3  



> Rick mentioned that there are numerous things that can go wrong after
> one crossposts among multiple lists.  I'd be interested to see those
> things separated into three categories - things that can go wrong
> which affect the author, things that can go wrong that affect the
> readership of the lists in question, and things that can go wrong that
> affect the list admins.

You'll note how lengthy the above explanation is.  And that was just one
small cluster of consequences -- though it's the bulk of what occurs to
me off the top of my head.  Even at that, I had to write carefully for
several reasons, including the well-known fact that discussing Reply-To: 
at all is known to be inflammatory (i.e., known to induce flamewars).  

I'm not really up for a lengthy discussion -- but I hope that, if you
consider a combination of mailing list software mechanics and the social
consequences likely to result from crossposts, you'll begin to see why 
multiposting is generally wiser, where mailing lists are concerned -- 
and why I politely suggest it.


> My intuition is that it's the list setup that causes the problems...

Unfortunately, all possible list setups endure one bad scenario or
another.  All you can do is pick your bad scenario.

> and (as Bill mentioned) people _responding_ to those emails without
> thinking clearly about _who_ they're responding to.

I mean no ill will towards anyone when I say that that's exactly what
inevitably occurs.  If 90% of each list is being careful, then the other
10% of each will fill the lull.

> Lists which don't allow posts from non-members, but which also don't
> simply DISCARD posts from non-members, but rather leave them for a
> list admin to peruse, create work for the list admin _because of how
> they're set up_.

Speaking for myself, because I've gotten pretty deft at Mailman
administration (if I may say so), I can now deal with these scenarios
pretty efficiently:  I generally approve the post (if it's even halfway
topical and non-spammy) _and_ check the box that will allow this
non-subscribed address's future posts (if any) through without being
held.  Any fallout I leave to the mailing list's membership -- because 
admin'ing with the minimum touch possible except to control spam and
flooding/spew is healthiest for the list (and for the listadmin's
sanity).

But even though I'm very efficient at dealing with that, I have to admit
the need for avoidable manual handling does tick me off, just a wee bit.
Ordinarily, I'd never mention it.  And the better I get at efficient
list-handling, the less it bothers me.

> Changing the options so the admin isn't given more work to do
> might make the list less friendly... but then again, so does making it
> members-only-can-post in the first place.

Generally speaking, fortunately, the very same things that reduce work
for the listadmin _also_ tend to make the list more friendly, i.e., more
relaxed and freer -- in my experience.  The uptight, hypercontrol,
admin-involved-in-everything mailing lists where the listadmin calls
him/herself a "listmom" (I kid you not) are worst.



[SVLUG lists]

> If/when I hear him saying otherwise, we'll probably be
> changing the list options to start auto-discarding crap faster.

I've tweaked the number of days posts are held to what I think is
optimal, at this point.  Real advances would actually be NOT within
Mailman at all, but rather involve better spam-rejection at the MTA
level.  (By the time spam reaches Mailman, you've missed your best
chance, and have only a series of realatively bad options.)  For reasons
discussed, that's something that needs to be implemented on the rebuild
machine, not the legacy one.