[sf-lug] email, Reply-to:, lists, and all that jazz
Michael.Paoli at cal.berkeley.edu
Tue Apr 29 04:06:53 PDT 2008
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
* 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
* 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). 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:
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
* 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-
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
> 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.
> 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.
More information about the sf-lug