unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#37591: Ring big alarms when slipped a 'Mail-Copies-To: never' header
@ 2019-10-02 19:26 積丹尼 Dan Jacobson
  2019-10-14 20:59 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: 積丹尼 Dan Jacobson @ 2019-10-02 19:26 UTC (permalink / raw)
  To: 37591

Big problem!

Let's say we get this mail

From: Robert Pluim <rpluim@gmail.com>
To: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,  6615@debbugs.gnu.org,  34130@debbugs.gnu.org
Mail-Copies-To: never

Well, causally hitting S W to reply to all gives us a buffer with:

To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 6615@debbugs.gnu.org,  34130@debbugs.gnu.org
From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>

Do you see the problem?

Gnus has blindly picked the **first** person from the CC list to become
the single To: person.

Yes, a proper mail needs a To: person. But it is a massive mistake to
pick one of the equal Cc: people to be the new To: person.

It was just like we were set up to redirect our anger at somebody else
via the silent booby trap Mail-Copies-To: never !

Solution: make all the people of the former Cc: and To: list now all equally
represented in a new single To:
To: Lars Ingebrigtsen <larsi@gnus.org>,  6615@debbugs.gnu.org,  34130@debbugs.gnu.org

Simple!

Furthermore, definitely give a warning:
'"Mail-Copies-To: never" header detected. Honor? [Y,n,?]'

And what if there were no Cc's or other To's ....

Anyway, the idea is to warn the user that he in now replying to someone else.
Also to eliminate making it look like we have chosen a special bystander
to now direct our wrath at instead of equally distributing it.

Gnus v5.13
GNU Emacs 26.3 (build 2, i686-pc-linux-gnu, GTK+ Version 3.24.11)
 of 2019-09-23, modified by Debian





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#37591: Ring big alarms when slipped a 'Mail-Copies-To: never' header
  2019-10-02 19:26 bug#37591: Ring big alarms when slipped a 'Mail-Copies-To: never' header 積丹尼 Dan Jacobson
@ 2019-10-14 20:59 ` Lars Ingebrigtsen
  2020-08-06 13:53   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-14 20:59 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 37591

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Let's say we get this mail
>
> From: Robert Pluim <rpluim@gmail.com>
> To: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 6615@debbugs.gnu.org,
> 34130@debbugs.gnu.org
> Mail-Copies-To: never
>
> Well, causally hitting S W to reply to all gives us a buffer with:
>
> To: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 6615@debbugs.gnu.org,  34130@debbugs.gnu.org
> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
>
> Do you see the problem?

Yeah, that's perhaps not optimal, and since it's valid to put several
addresses in the To header, perhaps the best solution is (as you
suggest) just to put all of them in the To header.

Does anybody have an opinion here?

> Furthermore, definitely give a warning:
> '"Mail-Copies-To: never" header detected. Honor? [Y,n,?]'
>
> And what if there were no Cc's or other To's ....

I don't think that's an issue -- it'll just use it in that case, if I
remember correctly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#37591: Ring big alarms when slipped a 'Mail-Copies-To: never' header
  2019-10-14 20:59 ` Lars Ingebrigtsen
@ 2020-08-06 13:53   ` Lars Ingebrigtsen
  2020-08-06 14:47     ` Robert Pluim
  0 siblings, 1 reply; 4+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-06 13:53 UTC (permalink / raw)
  To: 積丹尼 Dan Jacobson; +Cc: 37591

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yeah, that's perhaps not optimal, and since it's valid to put several
> addresses in the To header, perhaps the best solution is (as you
> suggest) just to put all of them in the To header.
>
> Does anybody have an opinion here?

Nobody had, so I've now done this change in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#37591: Ring big alarms when slipped a 'Mail-Copies-To: never' header
  2020-08-06 13:53   ` Lars Ingebrigtsen
@ 2020-08-06 14:47     ` Robert Pluim
  0 siblings, 0 replies; 4+ messages in thread
From: Robert Pluim @ 2020-08-06 14:47 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 37591, 積丹尼 Dan Jacobson

>>>>> On Thu, 06 Aug 2020 15:53:50 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> Yeah, that's perhaps not optimal, and since it's valid to put several
    >> addresses in the To header, perhaps the best solution is (as you
    >> suggest) just to put all of them in the To header.
    >> 
    >> Does anybody have an opinion here?

I used to have one, but Iʼve given up on Mail-Copies-To: never, since
there are too many broken mua's out there (which combined with people
who do 'reply all' when they should 'reply to sender' and 'reply to
sender' when they should 'reply all' just makes me despair for the
human race).

    Lars> Nobody had, so I've now done this change in Emacs 28.

OK.

Robert





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-08-06 14:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-02 19:26 bug#37591: Ring big alarms when slipped a 'Mail-Copies-To: never' header 積丹尼 Dan Jacobson
2019-10-14 20:59 ` Lars Ingebrigtsen
2020-08-06 13:53   ` Lars Ingebrigtsen
2020-08-06 14:47     ` Robert Pluim

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).