[sf-lug] email, Reply-to:, lists, and all that jazz

[Asheesh Laroia]

On Tue, 29 Apr 2008, Rick Moen wrote:

> Quoting Asheesh Laroia (asheesh at asheesh.org):
>
>> P.S. On a list without reply-to munging, the CC: line becomes enormous
>> when everyone replies-all.
>
> ...but then, FYI, shrinks to nothing again whenever someone using mutt
> or Emacs GNUS participates in the thread -- because both those MUAs have
> list-handling code to compensate for the cited undesired side-effect of
> mailing lists' inability to fully emulate NNTP netnews as people would
> actually prefer.

Yup!  That stuff's neat.

> (Example:  This post.  Quod erat demonstrandum:  The removal of non-list 
> addresses from my draft headers occurred automatically.)

Good - except maybe some of those people were people who were supposed to 
stay CC:d.  (For example:

1. I email the list and CC: my friend Bob not on the list.
2. Alice on the list replies and now adds me to the CC: line.
3. Charlie replies with mutt and drops Bob from the CC: line.

But also note that having the mailing list manager munge reply-to does not 
(far as I can see) improve this situation.  So, like, whatever, it's just 
a tiny nitpick.)

> I'm guessing that Alpine doesn't yet have list-reply handling.  You 
> should file a feature request with UofW.

Good idea.  Do you know where I can find docs on how Mutt and Emacs GNUs 
handles it?

(That's a serious question.  If you want to take that part of this thread 
off-list that's okay with me.)

>> I use a procmail+formail filter to remove duplicate inbound messages
>> based on their Message IDs - but if no munging + "use Reply to all" is
>> the most elegant solution, it's still not very elegant.
>
> No elegant solution is even theoretically possible, because mailing
> lists simply lack netnews/NNTP's built-in infrastructure support for
> distinguishing between reply (private) and followup (public).  Mailing
> lists attempt to emulate many-to-many forum semantics (i.e., netnews)
> over a one-to-many transport (i.e., SMTP):  Consequently, you as mailing
> list admin get to pick your choice of undesired side-effect.  You either
> deliberately sabotage subscribers' ability to do private reply (with
> periodic resulting social catastrophes), plus destructive mail loops, on
> the one hand, or live with the knowledge that there will be some
> generation of so-called "duplicate" mails by less-advanced participating
> MUAs, on the other.
>
> If you want full handling of the private / public messaging dichotomy
> with no undesired side-effects, go straight to _Usenet_.  Otherwise, a
> standards-compliant SMTP mailing list leavened with at least one mutt or
> GNUS user is exactly as good as it _can_ get.  ;->

(-:

> Here's the bog-standard procmail de-duping recipe you speak of (straight
> from "man procmailex"):
>
>              :0 Wh: msgid.lock
>              | formail -D 8192 msgid.cache
>
> Of course, the "Waaah!  Yes, you've proven that munging technology is bad
> and has been utterly rejected by standards authorities, but it's what
> we want" people aren't going to _bother_ using procmail, but there's a
> nice pool of water for any horses willing to drink.

Indeed.  You like the cup.  Drink from the cup. (*)

-- Asheesh.

*. http://people.debian.org/~branden/

-- 
My face is new, my license is expired, and I'm under a doctor's care!!!!