[sf-lug] reply / reply-all / reply-sender

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] (forw) Re: How to check distro checksums and signatures
> Date: Sun, 21 Feb 2016 22:56:10 -0800
> Well, my guess about 'Smart Reply' is that it's an attempt to do a
> creative workaround to an age-old problem:  (Many) users are
> slow/reluctant/unable to deal with the Internet reality of there always
> having been two[1] different reply modes, in e-mail:
>
> o  Reply-All
> o  Reply-Sender (which in software usually bears the label 'Reply')

Bit of obscure detail ;-) ... but I'd be a bit careful with the
terminology, and would generally use/state "reply" rather than
"reply-sender".

Why?  Well, ancient RFCs (some parts of which may still be
applicable!).  As I seem to recall, among headers email can have, it
can have *both* headers:
Sender:
From:
... including *both* in the same email, and they can be distinct!  E.g.
(the probably hopelessly outdated example): boss dictates a memo to be
sent out, administrative assistant takes the dictation, and sends out
the email from the boss.  The From: header would indicate the boss, the
Sender: header, in such case, may well indicate the administrative
assistant.  At least in theory, this could be quite useful, e.g.
recipient wants to address something of the content of the email - take
it up with the boss - e.g. reply to the From address.  Recipient wants
to let the sender know they've moved to a newer preferred email address
- perhaps more appropriate to let the Sender: email address know.
Anyway, I'd probably refrain from referring to "reply-sender", unless I
meant to the email in the Sender: header.  ;-)  I'd think Sender: could
also be useful for lists ... but seems instead, other list-specific
headers more generally (at least these days) tend to get used for that.

And to perhaps further confuse things (or not).  Some email clients are
"smart"(?) enough, to recognize what looks like email from a list, and
also give a reply-to-list option ... which I think is generally a good
idea.  Though some list software (ugh, Google Groups), sticks both an
http or https URL, and email address, among list related headers ...
and some email client software, when using reply-to-list, will rather
uselessly fill in the email address with the http or https string :-/
... not quite sure which side messed up on not following proper
standards (RFC, etc.) - but in that case, either or both sides
certainly didn't get it right.

And, some email clients can quite confusingly flip around the reply vs.
reply-all functionality.  E.g. some will do "r" for one, and "R" for
the other ... unless one tweaks a simple option, or might even have
that different by default on some distribution or operating system
version - then which the "r" does, and which the "R" does, have their
functionality flipped around the other way (!) - even for the same
client software.

So, yep, wee bit of a jungle out there.  So, look, see what options the
client offers, see what configuration options it offers, and check
(look over those fields) before taking the "send" action.  Some clients
also do funky things with the sending identity (From:, etc.) - e.g. if
your client is configured with multiple identities, when using reply or
reply-all, it will (for better or worse), automagically default to
using a different identity if it sees one of those in the relevant
headers of the email one is replying to.  So, yeah, sometimes the
behaviors are rather confusing/bewildering - or just not what one would
want/expect - at least by default.  So ... check, ... and sometimes
upgrade, or even switch clients, as necessary, useful, or even just
more convenient and as may be preferred to get the desired behavior ...
or at least closer to it.