Geoff Clare via austin-group-l at The Open Group wrote in
<20200909161256.GA15692@localhost>:
|Robert Elz wrote, on 09 Sep 2020:
|>
|> And thanks for the tutorial on how to use e-mail - but my e-mail client
|> doesn't have a "reply all" function, I don't want it to, the notion of
|> just "reply" vs "reply all" is absurdly simplistic. What I have \
|> is "reply"
|> which by default replies to the Reply-To if there is one, otherwise the
|> From+To+Cc list (more or less the equivalent of what you consider to be
|> "Reply All" I assume).
|
|There's your problem right there. You are using an email client that
|is not fit for purpose.
Hihihi. But at least his mailer is scriptable to the core!
And i would throw in and say that DMARC is to blame. And maybe it
is because so many mostly graphical and web-based mail clients do
not truly support "attachments" (aka MIME parts) nicely. We have
two distinct standardized approaches for signed data (S/MIME and
multipart/encrypted plus multipart/signed), and DMARC could very
well just have created a MIME multipart/signed from the DKIM
signed data, or just any other multipart type (/mixed mostly),
where the original data resides. But that cannot simply be done
on the island that a single RFC is, so that simply injects yet
another header into the main header block, and does not care for
the very important and decades old part of the email
infrastructure that mailing-lists are. But the job is done.
For the MUA i maintain i have implemented and use a "set
reply-to-swap-in=mlist" approach, where "mlist" states that the
action shall be performed when "the thread happens on something
configured as a mailing-list" (mlist and mlsubscribe commands
here), and it works somewhat, but it is nothing but a gross hack
to at least address the real person in From:.
It does not (yet) cover the introductional reply reference.
|> That's the way it should work - the Reply-To field
|> is the one you are supposed to use to suggest to me where you prefer \
|> to have
|> replies sent
|
|The part after the "-" is (partially) correct. However, it in no way
|implies that email clients should behave the way yours does.
|
|The Reply-To header is used to indicate where the author prefers to
|have replies sent *instead of the address in the From header*.
Yes. _Instead_. I always have to look. It is a misuse by DMARC.
|Therefore when replying (using whichever of the reply functions the email
|client provides) the only difference that the presence of Reply-To should
|have is that the reply address(es) the client offers contain the Reply-To
|address(es) in place of the From address. All other addresses (if any)
|taken from other headers should be the same. Using the presence of
|Reply-To to decide whether or not to include To+CC is just plain broken.
That is not how it usually works, or? Isn't Reply-To: used as an
exclusive replacement of all the addressees, unless i am mistaken?
RFC 5322 explicitly states
Note: Some mail applications have automatic reply commands that
include the destination addresses of the original message in the
destination addresses of the reply. How those reply commands
behave is implementation dependent and is beyond the scope of this
document. In particular, whether or not to include the original
destination addresses when the original message had a "Reply-To:"
field is not addressed here.
and if i recall correctly presence and usage of Reply-To: caused
replacement of all addressees with that address(es)?
I have definitely seen Reply-To: used like that, likely because
Mail-Followup-To: never became standardized.
Having said that, i think the behaviour of the MUA i maintain is
no good, and i think i will treat your statement as a suggestion
and implement it like that.
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
