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

[Michael Paoli]

Well, I would have made several of the excellent points Rick already
made, but he beat me to it :-) (Thanks, Rick).

In any case (quite a "thread" it turned out to be), there were still
several items I'd also consider worthy of mention, that weren't
directly addressed, or were rather to quite lightly touched upon.

Anyway, some of those points and some examples.  I'll try to cover them
in what I'd think roughly priority order (relative to my perception of
their importance, and how much they may have not, or not so much, been
covered already - at last on this "thread") ... such may not necessarily
be the most logically flowing of order, however ;-) :

* "User" training/education.
  Part of this "reply" / "Reply-all" / Reply-to "issue"/"problem" I
  think can be at least somewhat addressed by user education/training.
  I think also as email client software continues to get better, that
  also helps things - e.g. in making it more clear - and consistently
  clear - to the user - what various actions in the email client do (or
  at least ought to do) and will do.
  * "r"eply/"R"eply-all - most any reasonably sane email client provides
    at least two - and in many cases only two - "reply" flavors of
    options/choices/commands.  They're commonly called/labeled "reply",
    and "reply-all" or "reply-to-all".  Note also for common single-key
    commands, that "r" vs. "R" don't always correlate the same way
    around (probably much more commonly "r" is "reply" and "R"
    "Reply-all", but sometimes the reverse is the case).
  * probably one of the easiest ways to think of the "reply" vs.
    "Reply-all" is a minimal vs. maximal reply.  Though that may not be
    strictly true in terms of number of recipients, it tends to hold
    quite true in number of email addresses the client sends to.
  * "reply" has the client send to a single email address (though that
    address might be a forwarder, alias or even a list).  "reply" can
    also be thought of as generally going to the author/originator of
    the email (or address they specify that replies be directed to).
    "reply" is *not* for some intermediary (other than as may be
    explicitly specified by the author/originator).  (Probably a sucky
    analogy - but ... magazines in the mail, business reply cards -
    reply - one expects them in that case to go to the magazine or
    advertiser, not to be delivered to the postal service itself for
    having made possible this distribution and delivery of large
    quantities of magazines, ... and not to the 3rd party printing press
    or mailing house that printed and sent the magazines, either).  So,
    ... think "reply" - reply to author (or their designee).
  * "Reply-All" goes more towards the maximum, sending using To: (and
    sometimes also Cc:) picking the addresses from Reply-To: (or From:
    if Reply-To: isn't present or is empty), To: and Cc: headers, and
    using all those addresses (think maximum/broadest/*all* - or at
    least the largest set that would be a reasonably sensible thing to
    do).
* on email, lists, and replying, etc. in general.
  * If you want to reply just to the author/originator (or their designee), or m
ostly so, start with "reply".
  * If you want to address author/originator plus most or all of the email's rec
ipients, start with "Reply-all".
  * See also immediately following point!:
  * before sending, review, and adjust as appropriate, the To:, Cc:,
    and/or Bcc: recipients.  Not everything will always work as one
    expected or anticipated (or even as it should), and merely
    selecting "reply" or "Reply-All" may not have gotten one the set of
    recipients one actually wanted - so always review these (I'd
    recommend looking them over and adjusting them immediately after
    one does the reply or Reply-all selection, and again before making
    the send action).  One may also want to pay attention to exactly
    what recipients are/aren't included (did you include lists you're
    not even subscribed to and may not be able to post to, or email
    addresses you don't even recognize or know why they're there or
    who/what they're for?)  Whom is one addressing and/or Ccing?  Is
    that reasonably clear from the To:/Cc:(/and possibly also Bcc:)
    recipients, and if appropriate, salutation and/or closing?  Note
    also that in general, author/originator of email can set Reply-To:
    to whatever they want - e.g. if they want, they could set it to the
    list, or some other list, or president at whitehouse.gov, or whatever
    ... so, ... check before hitting send :-) !
  * Before making the send action, triple-check.  For most all intents
    and purposes, there is no unsend (perhaps another sucky analogy -
    you've hit send? - you just dropped that letter into a USPS
    mailbox). [0]
* Reply-to: munging by list software sucks - hopefully most have figured
  that out by now :-), but here's a bit more illustration of how it
  tends to suck.  Example, I often send email, from or as a "role" -
  i.e. I wear many hats, and may send something under a particular
  hat/"role".  One of the ways I commonly do that is by setting an
  appropriate Reply-to: header.  Why?  So that when a recipient
  replies, the email will go to the appropriate person(s) and/or
  queue(s) for that role, rather than simply and generally only going
  to me.  Reply-to: munging breaks that - E.g. I send some BALUG newsy
  announcement thingy to some spattering of other UGs that are likely
  interested (e.g. to their talk/discussion lists) - I may set a
  Reply-To: corresponding to BALUG's publicity feedback (are we getting
  too much stuff out there, not enough, not the right places, or not
  the best timing, etc.?) ... with the Reply-to: set, that feedback
  goes to the folks that work on trying to find that "just right"
  contents, amount, timing and placement of BALUG's
  publicity/announcements and communications ... rather than merely
  going to me.  If the list software munges the Reply-To: to be the
  list, then when persons read that list, they pick "reply", it not
  only won't go to those intended by the author of the original
  message, but I might not even see it at all (at least hypothetically
  it could be a list I could send to without being subscribed to), and
  the person responding might be embarrassingly (or worse) surprised
  that their "reply" went to the list, rather than the author or their
  designee (think of a newbie having just joined the list, and having
  never encountered such aberrant standards defiant behavior).  Another
  similar example, person sends from soon-to-be-defunct email address
  (as they want folks to recognize it as them), and sets Reply-To: of
  their newly created email address - again, list munging of Reply-To:
  breaks that.  Anyway, many other suitable references and points on
  the topic were covered, but I thought I'd add some much more direct
  example (like yes, it would in fact impact email I send - even
  including to this list; and would likewise impact email of *everyone*
  sending to the list if Reply-To: munging were in effect).
* and (semi-?)related (mostly about check before one sends - before I go
  too far off-topic):
  * Consider updating/changing the Subject: - Subject: is for Subject:,
    not thread tracking (other headers can be used for tracking
    threads).  If it's already "close enough" it may be better left
    alone, but if the Subject: is no longer fitting, suitably adjust it.
    (And no, email client software hasn't yet gotten quite smart enough
    to figure out the Subject: for you ... other than perhaps prepending
    a RE: or the like).  Most people will generally appreciate Subject:
    headers that reasonably reflect the subject(s) addressed in the email.
  * you don't *have* to include the entirety of whatever it is you're
    replying to.  It's generally considered best practice to just
    include/quote the relevant parts/bits that one is referring to (with
    sufficient but not excess context) (okay, so once in a while someone
    will get miffed that they've been quoted out of context or whatever,
    but they can generally always respond, and pick out / emphasize the
    bits they think most appropriate to make their point[1]).  Want to
    address the entirety of what was said?  You're replying to an item
    that was sent to the list, and sending your reply to the list?  That
    list footer on there, ... do you really need to even include that as
    part of what you're quoting, when the listserver is going to add the
    same footer again to what it sends out?  Come on, trim a 'lil, it's
    not *that* painful to do. :-)
  * It's probably better/best, in general, not to be sending email as
    HTML to lists (or USENET).  At least certain email clients will
    default to sending both HTML and text - in such cases for lists,
    it's generally best to configure them to just use plain text when
    sending to the list email address.  Also, for those of us that read
    the list in digest form (which may be a quite sizeable percentage,
    due to the list's relatively high volume), those "An HTML
    attachment was scrubbed..." footers and URLs get rather annoying
    after a while.  They also take up lots of space on the listserver,
    and are probably, in most regards there, wasted space.  Are you
    guilty?  Your email client might not be making this blatantly
    obvious to you ... have a look at the list archives (not to pick on
    anyone in particular, but just grabbing the most recent that's
    there when I peek, have a look at the tail end of:
    http://linuxmafia.com/pipermail/sf-lug/2008q2/004530.html
    to see what I mean).  Not sure if it shows up quite that annoyingly
    for those on the list that aren't subscribed in digest form.
  * yes, there is no real unsend
  * try to spell check, etc. (especially as audience and/or relative
    permanence and visibility increase).
  * if you wouldn't want to see it leaked and printed in some newspaper
    or tabloid - including being quoted totally out of context, you
    *might* not want to email it.
  * if things are at all ambiguous in email, they'll generally be
    interpreted in the more/most negative of ways.  Many studies have
    shown this.  It mostly has to do with the relative "flatness" of
    email communication - no verbal cues, no body language, the feedback
    loop only starts after the e-mail is sent (no realtime or near
    realtime feedback of communication as it is being formed), etc.  And
    the smiley thingies can hardly come close to filling those gaps. 8-O
  * if unsure if one should hit send (should that email be sent?  will
    it be taken the wrong way?), the more correct answer is usually
    either don't send it, or sit on it a while, then reconsider and
    reread and reconsider.  (so, yeah, if you're hesitating, there's
    probably a good reason why).
  * despite best intentions, most of us will manage to blow it at least
    occasionally anyway - try to be reasonably understanding, and try to
    give the benefit of the doubt on the ambiguities (or at least allow
    for the reasonably possible range, and typos and brain farts and
    misedits, that may have compounded any problems or possible
    misinterpretation).

Footnotes:
* for brevity, I didn't delve into all the details and exceptions, and
  may have given "just" fairly good approximations for some/many of the
  descriptions (e.g. I didn't even touch upon Sender: and Resent-
  headers, etc.).
0. Similar rule for systems administrators: always triple check before
   viciously striking the <RETURN> key - okay, so the vicious part is
   optional, but it should be a deliberate and intended action in any
   case - that practice has saved my tail on multiple occasions.
1. Once upon a time I had a manager that directed me to include the
   *entirety* of everything I replied to.  After initially essentially
   saying "yes boss", but very shortly thereafter and before I made it
   to my next send, I informed my boss that I would not be following
   that particular direction, as it was far too ignorant/stupid of a
   direction (though I didn't phrase it that way ... "best practices"
   and all that).  It was also me that would be authoring those emails,
   and I had no interest in sending emails that would in many cases go
   so abhorrently contrary to best practices.  Nice person, but
   *horrible* manager - 3rd worst boss I'd ever had (needn't cover the
   yet worse ones) ... thankfully most have been *much better* than
   that.

references/excerpts:
> Date: Sun, 27 Apr 2008 15:14:20 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: sf-lug at linuxmafia.com
> Message-ID: <20080427221420.GA3800 at linuxmafia.com>

> Quoting jim (jim at well.com):

> > hmmm. good point.

> Exceedingly bad point.  Internet novices should (finally) stop insisting
> that their MUAs' "Reply" command must be induced to magically do the
> right thing in all circumstances, and should learn about their MUAs'
> separate Reply-to-All command.

> > you'd like the mailman server to send mail such that the reply to:
> > field is the list so that reply sends to the list (then what's the
> > purpose in this context of reply all?).  correct me if i've got it
> > wrong.

> That is an abuse of the Reply-To: header, and (as usually implemented)
> prevents its use in its legitimate role by individuals to indicate an
> alternate address to which direct replies should go.

> > i'm not sure it's a good idea, ultimately, but worth inspection.
> > we (hopefully someones more than just me) will check this out: can we
> > do it as well as should we do it.

> I'm afraid I cannot permit mailing lists with munging of Reply-To
> enabled on my server.  The technical disasters that tend to result from
> that configuration error (e.g., mail loops with badly written
> out-of-office autoresponders) and the social disasters of accidentally
> published highly confidential mail should be well known, seven years
> after advocates of munging lost the standards battle.

> http://linuxmafia.com/~rick/faq/index.php?page=netiquette#replyto

> I'm not _personally_ menaced by the practice, because I'm a mutt user:
> Mutt has an option to ignore and override Reply-To: munging (as does
> Emacs GNUS).  However, others tend over time to suffer mishaps (getting
> fired, bloody noses, divorces, etc.) from accidental public sending of

> confidential mails that they _thought_ were going offlist.