bug#46472: Make lisp/mail/uce.el obsolete

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Severity: wishlist

While digging around, I have happened upon lisp/mail/uce.el.

Here is how it describes itself:

;; The code in this file provides a semi-automatic means of replying
;; to unsolicited commercial email (UCE) you might get.

It sends an email to the sender, as well as the abuse and postmaster
emails for the senders domain containing a fairly polite request to be
taken off any lists.  I think these days, it is pointless to reply to
spam, and no one is (or should be) doing it.  It only verifies to the
spammers that your email is valid, which is useful information to them
and will do nothing but ensure you stay on their list.

This seems like a relic from a more gentle and perhaps naive time of the
internet.  Nowadays, people should not waste their time on doing that,
but instead use a spam filter.

IOW, I think this library is useless these days.

So how about moving it to obsolete/?

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 12 Feb 2021 15:58:53 -0600
> 
> ;; The code in this file provides a semi-automatic means of replying
> ;; to unsolicited commercial email (UCE) you might get.
> 
> It sends an email to the sender, as well as the abuse and postmaster
> emails for the senders domain containing a fairly polite request to be
> taken off any lists.  I think these days, it is pointless to reply to
> spam, and no one is (or should be) doing it.  It only verifies to the
> spammers that your email is valid, which is useful information to them
> and will do nothing but ensure you stay on their list.
> 
> This seems like a relic from a more gentle and perhaps naive time of the
> internet.  Nowadays, people should not waste their time on doing that,
> but instead use a spam filter.
> 
> IOW, I think this library is useless these days.
> 
> So how about moving it to obsolete/?

What are the reasons for moving uce.el to obsolete/ ?

What you say above was always true: replying to spam bears an inherent
risk.  This didn't change in any way, so how will we justify
obsoleting this package now?  I don't think our personal opinions on
which is or isn't useful practices are reasons good enough to make it
harder for others to use those practices if they so wish.  It isn't
our prerogative to tell others what to do or not to do in these
circumstances.

So my vote is against obsoleting this package, if the above reasoning
is the only grounds for that.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> What you say above was always true: replying to spam bears an inherent
> risk.  This didn't change in any way, so how will we justify
> obsoleting this package now?

I think the methods for dealing with spam has developed quite a bit
since 1996, so I'm not quite sure I follow this argument.  The
justification is that no one should waste time replying to spam; they
should use a spam filter.

If you are looking for strictly technical reasons for obsoleting it, of
course they exist too: Anyone that wants to reply to an email using
pre-written drafts can do so using skeleton, tempo, abbrev, etc.  Those
are better tools that cover this use-case.

> I don't think our personal opinions on which is or isn't useful
> practices are reasons good enough to make it harder for others to use
> those practices if they so wish.

Whether or not replying to spam is good or bad is not really a matter of
personal opinion; it is objectively bad.  You can find any number of
security and privacy experts that could explain why:

- You will confirm your email address is valid, ensuring you get more
  spam.

- Sender address is probably fake.  (For example, you might unwittingly
  participate in flooding someones mailbox.  The abuse@domain and
  postmaster@domain is also unlikely to be able to act on your reply.)

- You open yourself up to various kinds of social engineering.

- You might leak information (e.g. on your email server and setup).

Encouraging this bad practice by shipping uce.el puts unknowing users at
risk, and promotes a bad method of dealing with spam.  We should instead
discourage this bad practice by moving it to obsolete/.

> It isn't our prerogative to tell others what to do or not to do in
> these circumstances.

Anyone would of course still free to continue doing whatever they want
(for example by making a copy of the obsolete libary for their own use).

But I think we should be equally free to (strongly) recommend against
bad practices.

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 13 Feb 2021 06:25:19 -0600
> Cc: 46472@debbugs.gnu.org
> 
> But I think we should be equally free to (strongly) recommend against
> bad practices.

The method of "recommendation" you propose is too strong for my
palate, sorry.  In general, I believe that people should be left to
their devices unless what they do causes harm to others.
Second-guessing other people under the assumption that we know better
is something I don't like doing, and don't like others doing to me.

How about adding some warnings to uce.el instead, either in the
commentary or when the main entry point is invoked for the first time
in a session?

bug#46472: Make lisp/mail/uce.el obsolete

[Glenn Morris]

Replying to spam is at best pointless, but most likely actively harmful.
Emacs having a package to help you reply to spam is at best pointless,
but most likely actively harmful.

This is one of the many things that makes Emacs look antiquated.
I find the refusal to even obsolete such things demotivating for working
on Emacs. So IMO the cost for keeping such things around is non-zero.

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  46472@debbugs.gnu.org
> Date: Thu, 04 Mar 2021 14:27:29 -0500
> 
> Replying to spam is at best pointless, but most likely actively harmful.
> Emacs having a package to help you reply to spam is at best pointless,
> but most likely actively harmful.

Yes, Stefan already said that up-thread.  I don't see how our views on
what is and isn't appropriate response to spam should be mandatory for
the few users who may disagree.  This is free software, users are free
to do whatever they want with it.  Which is also something I already
said, so I don't see why do we need to reiterate the same arguments
without saying anything new.

> This is one of the many things that makes Emacs look antiquated.

Why "antiquated"?  Is there any other, more modern method we support
to respond to spam?

> I find the refusal to even obsolete such things demotivating for working
> on Emacs. So IMO the cost for keeping such things around is non-zero.

I sympathize with your feelings, but feelings aren't limited to one
side in a disagreement, and you are not the only one who finds this
and similar disputes demotivating.  Which is why I think we should try
to stay technical and not emotional.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't see how our views on what is and isn't appropriate response to
> spam should be mandatory for the few users who may disagree.

Moving this to obsolete/ does not make it mandatory for anyone to do
anything.  It is not within our power to do that; one of the freedoms
granted by the GPL is to run the program for any purpose.

> This is free software, users are free to do whatever they want with
> it.

I can't see what this has to do with the principles of Free Software.

AFAIK, nowhere in the GPL, the GNU Manifesto etc. does it say that it is
contrary to the spirit of free software to make useless features
obsolete.

> Is there any other, more modern method we support to respond to spam?

Yes, I listed some of them in my previous reply.  Not that I understand
why this is pertinent, as we have already established that doing that is
useless and/or harmful.

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 6 Mar 2021 11:14:13 -0600
> Cc: 46472@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't see how our views on what is and isn't appropriate response to
> > spam should be mandatory for the few users who may disagree.
> 
> Moving this to obsolete/ does not make it mandatory for anyone to do
> anything.  It is not within our power to do that; one of the freedoms
> granted by the GPL is to run the program for any purpose.

Moving it to obsolete/ will make using it an annoyance.  If I were one
of those who for some reason use this package, I'd resent that move.
What I resent when done to myself I prefer we don't do to others.

> AFAIK, nowhere in the GPL, the GNU Manifesto etc. does it say that it is
> contrary to the spirit of free software to make useless features
> obsolete.

That this feature is obsolete is one opinion.  Even if that opinion is
predominant, it doesn't mean different opinions aren't possible, let
alone legitimate.

It is IMO condescending to force our views on others.

> > Is there any other, more modern method we support to respond to spam?
> 
> Yes, I listed some of them in my previous reply.

And I already said most of the above in my previous replies.  But we
are still arguing, for some reason that evades me.

Bottom line: I find obsolescence to be inappropriate for this kind of
situations.  If we want to warn users against responding to spam, we
should find a different way of doing that.  Like we do with
lib-src/movemail, for example.  (For some reason, ISTR I already said
that as well.)

bug#46472: Make lisp/mail/uce.el obsolete

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> Replying to spam is at best pointless, but most likely actively harmful.
> Emacs having a package to help you reply to spam is at best pointless,
> but most likely actively harmful.
>
> This is one of the many things that makes Emacs look antiquated.
> I find the refusal to even obsolete such things demotivating for working
> on Emacs. So IMO the cost for keeping such things around is non-zero.

I think, on reflection, that this is a good argument.  And I agree with
everybody's that said that you should never use uce.el, so I've now
moved it to obsolete.

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

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> The method of "recommendation" you propose is too strong for my
> palate, sorry.  In general, I believe that people should be left to
> their devices unless what they do causes harm to others.
> Second-guessing other people under the assumption that we know better
> is something I don't like doing, and don't like others doing to me.
>
> How about adding some warnings to uce.el instead, either in the
> commentary or when the main entry point is invoked for the first time
> in a session?

Is this okay for emacs-28?

diff --git a/lisp/mail/uce.el b/lisp/mail/uce.el
index b07004de38..611181ca61 100644
--- a/lisp/mail/uce.el
+++ b/lisp/mail/uce.el
@@ -24,11 +24,53 @@
 ;;; Commentary:

 ;; The code in this file provides a semi-automatic means of replying
-;; to unsolicited commercial email (UCE) you might get.  Currently, it
-;; only works with Rmail and Gnus.  If you would like to make it work
-;; with other mail readers, see the mail-client dependent section of
-;; uce-reply-to-uce.  Please let me know about your changes so I can
-;; incorporate them.  I'd appreciate it.
+;; to unsolicited commercial email (UCE) you might get.
+
+;; -- !!! NOTE !!! --------------------------------------------
+;;
+;; Replying to spam is at best pointless, but most likely actively
+;; harmful.
+;;
+;; - You will confirm that your email address is valid, thus ensuring
+;;   you get more spam.  Spammers use tricks like getting you to reply
+;;   and/or clicking unsubscribe links, etc. to confirm that you
+;;   should stay on their lists.
+;;
+;; - You will leak information (e.g. on your email server and setup),
+;;   thus opening yourself up for further attack.  More importantly,
+;;   they are likely to find your IP, thus your physical location (see
+;;   "geolocation"), and by combining that data with your name it
+;;   should be trivial to find e.g. your home address and phone
+;;   number.
+;;
+;; - The sender address is likely fake.  (For example, you might
+;;   unwittingly participate in flooding someones mailbox.  The
+;;   abuse@domain and postmaster@domain is unlikely to be able to act
+;;   on your reply.)
+;;
+;; - You open yourself up to various kinds of social engineering.
+;;   This could be the first in a planned exchange where they will
+;;   attempt to trick you to divulge sensitive information.
+;;
+;; - You confirm that the email landed in your inbox, and not the spam
+;;   folder.  This confirms to them that their current method of
+;;   spamming is useful, and helps them continue.
+;;
+;; - Scammers have been known to threaten, intimidate, and use other
+;;   forms of criminal manipulation.  Be aware that replying to spam
+;;   can lead down a path that you may not want to be on.
+;;
+;; Therefore, we strongly recommend that you do not use this package.
+;; Use a spam filter instead, or just delete the spam.
+;;
+;; If you still want to use it, read on.
+;;
+;; ------------------------------------------------------------
+
+;; Currently, it only works with Rmail and Gnus.  If you would like to
+;; make it work with other mail readers, see the mail-client dependent
+;; section of uce-reply-to-uce.  Please let me know about your changes so
+;; I can incorporate them.  I'd appreciate it.

 ;; The command uce-reply-to-uce, if called when the current message
 ;; buffer is a UCE, will setup a reply *mail* buffer as follows.  It
@@ -204,6 +246,12 @@ uce-subject-line
   "Subject of the message that will be sent in response to a UCE."
   :type 'string)

+(defcustom uce-i-want-to-use-this nil
+  "Non-nil means that you don't want the warning message about this package.
+See `uce-reply-to-uce' for background."
+  :type 'boolean
+  :version "28.1")
+
 ;; End of user options.


@@ -218,7 +266,44 @@ uce-reply-to-uce
   "Compose a reply to unsolicited commercial email (UCE).
 Sets up a reply buffer addressed to: the sender, his postmaster,
 his abuse@ address, and the postmaster of the mail relay used.
-You might need to set `uce-mail-reader' before using this."
+You might need to set `uce-mail-reader' before using this.
+
+-- !!! NOTE !!! --------------------------------------------
+
+Replying to spam is at best pointless, but most likely actively
+harmful.
+
+- You will confirm that your email address is valid, thus ensuring
+  you get more spam.  Spammers use tricks like getting you to reply
+  and/or clicking unsubscribe links, etc. to confirm that you
+  should stay on their lists.
+
+- You will leak information (e.g. on your email server and setup),
+  thus opening yourself up for further attack.  More importantly,
+  they are likely to find your IP, thus your physical location (see
+  \"geolocation\"), and by combining that data with your name it
+  should be trivial to find e.g. your home address and phone
+  number.
+
+- The sender address is likely fake.  (For example, you might
+  unwittingly participate in flooding someones mailbox.  The
+  abuse@domain and postmaster@domain is unlikely to be able to act
+  on your reply.)
+
+- You open yourself up to various kinds of social engineering.
+  This could be the first in a planned exchange where they will
+  attempt to trick you to divulge sensitive information.
+
+- You confirm that the email landed in your inbox, and not the spam
+  folder.  This confirms to them that their current method of
+  spamming is useful, and helps them continue.
+
+- Scammers have been known to threaten, intimidate, and use other
+  forms of criminal manipulation.  Be aware that replying to spam
+  can lead down a path that you may not want to be on.
+
+Therefore, we strongly recommend that you do not use this package.
+Use a spam filter instead, or just delete the spam."
   (interactive)
   ;; Start of mail-client dependent section.
   (let ((message-buffer
@@ -358,7 +443,49 @@ uce-reply-to-uce
       ;; Run hooks before we leave buffer for editing.  Reasonable usage
       ;; might be to set up special key bindings, replace standard
       ;; functions in mail-mode, etc.
-      (run-hooks 'mail-setup-hook 'uce-setup-hook))))
+      (run-hooks 'mail-setup-hook 'uce-setup-hook)))
+  (unless uce-i-want-to-use-this
+    (pop-to-buffer (get-buffer-create "uce-reply-to-uce warning"))
+    (insert "-- !!! NOTE !!! --------------------------------------------
+
+Replying to spam is at best pointless, but most likely actively
+harmful.
+
+- You will confirm that your email address is valid, thus ensuring
+  you get more spam.  Spammers use tricks like getting you to reply
+  and/or clicking unsubscribe links, etc. to confirm that you
+  should stay on their lists.
+
+- You will leak information (e.g. on your email server and setup),
+  thus opening yourself up for further attack.  More importantly,
+  they are likely to find your IP, thus your physical location (see
+  \"geolocation\"), and by combining that data with your name it
+  should be trivial to find e.g. your home address and phone
+  number.
+
+- The sender address is likely fake.  (For example, you might
+  unwittingly participate in flooding someones mailbox.  The
+  abuse@domain and postmaster@domain is unlikely to be able to act
+  on your reply.)
+
+- You open yourself up to various kinds of social engineering.
+  This could be the first in a planned exchange where they will
+  attempt to trick you to divulge sensitive information.
+
+- You confirm that the email landed in your inbox, and not the spam
+  folder.  This confirms to them that their current method of
+  spamming is useful, and helps them continue.
+
+- Scammers have been known to threaten, intimidate, and use other
+  forms of criminal manipulation.  Be aware that replying to spam
+  can lead down a path that you may not want to be on.
+
+Therefore, we strongly recommend that you do not use this package.
+Use a spam filter instead, or just delete the spam.
+
+Customize the variable `uce-i-want-to-use-this' if you do not
+want to see this message.
+")))

 (defun uce-insert-ranting (&optional _ignored)
   "Insert text of the usual reply to UCE into current buffer."

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Mon, 11 Oct 2021 21:33:31 -0700
> Cc: 46472@debbugs.gnu.org, Glenn Morris <rgm@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The method of "recommendation" you propose is too strong for my
> > palate, sorry.  In general, I believe that people should be left to
> > their devices unless what they do causes harm to others.
> > Second-guessing other people under the assumption that we know better
> > is something I don't like doing, and don't like others doing to me.
> >
> > How about adding some warnings to uce.el instead, either in the
> > commentary or when the main entry point is invoked for the first time
> > in a session?
> 
> Is this okay for emacs-28?

No, please leave unnecessary changes out of emacs-28.

>  ;; The code in this file provides a semi-automatic means of replying
> -;; to unsolicited commercial email (UCE) you might get.  Currently, it
> -;; only works with Rmail and Gnus.  If you would like to make it work
> -;; with other mail readers, see the mail-client dependent section of
> -;; uce-reply-to-uce.  Please let me know about your changes so I can
> -;; incorporate them.  I'd appreciate it.
> +;; to unsolicited commercial email (UCE) you might get.

I would leave the original text intact, as dividing it into two splits
the description of the package, and the additional text is too long to
keep the beginning in mind.

> +;; -- !!! NOTE !!! --------------------------------------------
> +;;
> +;; Replying to spam is at best pointless, but most likely actively
> +;; harmful.
> +;;
> +;; - You will confirm that your email address is valid, thus ensuring
> +;;   you get more spam.  Spammers use tricks like getting you to reply
> +;;   and/or clicking unsubscribe links, etc. to confirm that you
> +;;   should stay on their lists.
> +;;
> +;; - You will leak information (e.g. on your email server and setup),
> +;;   thus opening yourself up for further attack.  More importantly,
> +;;   they are likely to find your IP, thus your physical location (see
> +;;   "geolocation"), and by combining that data with your name it
> +;;   should be trivial to find e.g. your home address and phone
> +;;   number.

These two paragraphs basically says the same, so you could say the
same more concisely and to the point by combining them.

> +;; - You open yourself up to various kinds of social engineering.
> +;;   This could be the first in a planned exchange where they will
> +;;   attempt to trick you to divulge sensitive information.
> +;;
> +;; - You confirm that the email landed in your inbox, and not the spam
> +;;   folder.  This confirms to them that their current method of
> +;;   spamming is useful, and helps them continue.

These two just reiterate what you already said.

> +;; - Scammers have been known to threaten, intimidate, and use other
> +;;   forms of criminal manipulation.  Be aware that replying to spam
> +;;   can lead down a path that you may not want to be on.

Likewise.

So I think the same message could be usefully conveyed with much fewer
words.

> +(defcustom uce-i-want-to-use-this nil
> +  "Non-nil means that you don't want the warning message about this package.
> +See `uce-reply-to-uce' for background."
> +  :type 'boolean
> +  :version "28.1")

This is redundant, since users that don't want this should not load
the package.

> @@ -218,7 +266,44 @@ uce-reply-to-uce
>    "Compose a reply to unsolicited commercial email (UCE).
>  Sets up a reply buffer addressed to: the sender, his postmaster,
>  his abuse@ address, and the postmaster of the mail relay used.
> -You might need to set `uce-mail-reader' before using this."
> +You might need to set `uce-mail-reader' before using this.
> +
> +-- !!! NOTE !!! --------------------------------------------
> +
> +Replying to spam is at best pointless, but most likely actively
> +harmful.

Why the same text again?

> +  (unless uce-i-want-to-use-this
> +    (pop-to-buffer (get-buffer-create "uce-reply-to-uce warning"))
> +    (insert "-- !!! NOTE !!! --------------------------------------------

And again?

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> No, please leave unnecessary changes out of emacs-28.

Even documentation changes?

I'd suggest installing the change as attached on emacs-28.  If that's
not possible, I'd like to install it on master, but add the same text to
the package "Commentary" section on emacs-28.

> I would leave the original text intact, as dividing it into two splits
> the description of the package, and the additional text is too long to
> keep the beginning in mind.

OK.

> So I think the same message could be usefully conveyed with much fewer
> words.

I've tried shortening it in the attached.

>> +(defcustom uce-i-want-to-use-this nil
>> +  "Non-nil means that you don't want the warning message about this package.
>> +See `uce-reply-to-uce' for background."
>> +  :type 'boolean
>> +  :version "28.1")
>
> This is redundant, since users that don't want this should not load
> the package.

OK, I'm fine with a non-optional warning.

> Why the same text again?
[...]
> And again?

So these were the three entry points I see: `describe-package', `C-h f',
and running the command.  It is true that it should be enough to just
show the warning when running the command.

[-- Attachment #2: 0001-Recommend-against-using-uce.el.patch --]
[-- Type: text/x-diff, Size: 2110 bytes --]

From 8dfe3d1e8f1d9571e1f11da75ff5956f3b1ef4a0 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 12 Oct 2021 06:30:20 +0200
Subject: [PATCH] Recommend against using uce.el

* lisp/mail/uce.el: Recommend against its use.  (Bug#46472)
---
 lisp/mail/uce.el | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/lisp/mail/uce.el b/lisp/mail/uce.el
index b07004de38..7d59986ae2 100644
--- a/lisp/mail/uce.el
+++ b/lisp/mail/uce.el
@@ -358,7 +358,36 @@ uce-reply-to-uce
       ;; Run hooks before we leave buffer for editing.  Reasonable usage
       ;; might be to set up special key bindings, replace standard
       ;; functions in mail-mode, etc.
-      (run-hooks 'mail-setup-hook 'uce-setup-hook))))
+      (run-hooks 'mail-setup-hook 'uce-setup-hook)))
+  (pop-to-buffer (get-buffer-create "uce-reply-to-uce warning"))
+  (insert "-- !!! NOTE !!! --------------------------------------------
+
+Replying to spam is at best pointless, but most likely actively
+harmful.
+
+- You will confirm that your email address is valid, thus ensuring
+  you get more spam.
+
+- You will leak information (e.g. on your email server and
+  setup), thus opening yourself up for further attack.  They are
+  likely to find your IP and \"geolocation\"), which often makes
+  it trivial to find e.g. your home address and phone number.
+
+- The sender address is likely fake.  The abuse@domain is
+  unlikely to be able to do anything.
+
+- You open yourself up to various kinds of social engineering.
+
+- You confirm that the email did not land in your spam folder.
+  (This helps them refine their methods of spamming.)
+
+- Scammers have been known to threaten, intimidate, and use other
+  forms of criminal manipulation.  Replying to spam can lead down
+  a path that you may not want to be on.
+
+Therefore, we strongly recommend that you do not use this package.
+Use a spam filter instead, or just delete the spam.
+"))
 
 (defun uce-insert-ranting (&optional _ignored)
   "Insert text of the usual reply to UCE into current buffer."
-- 
2.30.2

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 12 Oct 2021 09:12:02 -0700
> Cc: 46472@debbugs.gnu.org, rgm@gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, please leave unnecessary changes out of emacs-28.
> 
> Even documentation changes?

These are not just documentation changes, these are changes of the
semantics of the package.  It's not like they are typos or
inaccuracies in the documentation.  And the new defcustom is
definitely not a documentation change.

> I'd suggest installing the change as attached on emacs-28.  If that's
> not possible, I'd like to install it on master, but add the same text to
> the package "Commentary" section on emacs-28.

On master, please.  And I don't see why have the same text twice.

> > So I think the same message could be usefully conveyed with much fewer
> > words.
> 
> I've tried shortening it in the attached.

It is still too repetitive, IMO:

> +- You will confirm that your email address is valid, thus ensuring
> +  you get more spam.
> +
> +- You will leak information (e.g. on your email server and
> +  setup), thus opening yourself up for further attack.  They are
> +  likely to find your IP and \"geolocation\"), which often makes
> +  it trivial to find e.g. your home address and phone number.

The first paragraph is a special case of the second one.

> +- The sender address is likely fake.  The abuse@domain is
> +  unlikely to be able to do anything.
> +
> +- You open yourself up to various kinds of social engineering.
> +
> +- You confirm that the email did not land in your spam folder.
> +  (This helps them refine their methods of spamming.)

This is also the same as what you already said.

> +- Scammers have been known to threaten, intimidate, and use other
> +  forms of criminal manipulation.  Replying to spam can lead down
> +  a path that you may not want to be on.

This is the same as "open yourself to ..." paragraph.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'd suggest installing the change as attached on emacs-28.  If that's
>> not possible, I'd like to install it on master, but add the same text to
>> the package "Commentary" section on emacs-28.
>
> On master, please.

It is really unfortunate if we can't even document serious security and
privacy issues in Emacs 28 at this point.  I do not see how such
documentation could possibly affect the release date.

> And I don't see why have the same text twice.

I removed the duplicates in the new patch.  Did I send the wrong patch?

Or maybe my suggestion was not clear:

- Emacs 28: Documentation changes only.  Do not merge to master.
- Emacs 29: Warning only, no documentation changes.

>> +- You will confirm that your email address is valid, thus ensuring
>> +  you get more spam.
>> +
>> +- You will leak information (e.g. on your email server and
>> +  setup), thus opening yourself up for further attack.  They are
>> +  likely to find your IP and \"geolocation\"), which often makes
>> +  it trivial to find e.g. your home address and phone number.
>
> The first paragraph is a special case of the second one.

Yes, it is also the one that immediately shows why this is
counter-productive, so it is worth making into its own item.

>> +- You confirm that the email did not land in your spam folder.
>> +  (This helps them refine their methods of spamming.)
>
> This is also the same as what you already said.

It is subtly different:

1. Spammers can use the information that your address is valid.

2. They can also use the information that their email has been crafted
   in such a way that they can evade some spam filters.

>> +- Scammers have been known to threaten, intimidate, and use other
>> +  forms of criminal manipulation.  Replying to spam can lead down
>> +  a path that you may not want to be on.
>
> This is the same as "open yourself to ..." paragraph.

It is hammering home the point to a certain extent, sure.  I think it is
motivated and useful.  There is no specific reason to keep this text
very brief: it is much more important that it accurately conveys the
dangers involved.

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 12 Oct 2021 10:29:16 -0700
> Cc: 46472@debbugs.gnu.org, rgm@gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'd suggest installing the change as attached on emacs-28.  If that's
> >> not possible, I'd like to install it on master, but add the same text to
> >> the package "Commentary" section on emacs-28.
> >
> > On master, please.
> 
> It is really unfortunate if we can't even document serious security and
> privacy issues in Emacs 28 at this point.

Document: yes.  But your change modified the code as well, and more
importantly changed how the feature works.

> I do not see how such documentation could possibly affect the
> release date.

The release branch is closed for any behavior changes, except the ones
that are strictly necessary to fix some bug (and even those last ones
only if they are safe enough).

> It is hammering home the point

Please don't hammer.  Say it once, clearly and concisely, and
preferably without implying that the user who might want to use it has
a death wish.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> Document: yes.  But your change modified the code as well, and more
> importantly changed how the feature works.

This is what I suggest for emacs-28, note the "Do not merge to master"
in the commit message.

On master, I suggest the same patch as before, but with the updated
text that you can read here.

[-- Attachment #2: 0001-Recommend-against-using-uce.el.patch --]
[-- Type: text/x-diff, Size: 1589 bytes --]

From bb575f38b54624d973e72a06a9272db2fbe0cf06 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 12 Oct 2021 06:30:20 +0200
Subject: [PATCH] Recommend against using uce.el

* lisp/mail/uce.el: Recommend against its use.  (Bug#46472)
Do not merge to master.
---
 lisp/mail/uce.el | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/lisp/mail/uce.el b/lisp/mail/uce.el
index b07004de38..0a488e176f 100644
--- a/lisp/mail/uce.el
+++ b/lisp/mail/uce.el
@@ -30,6 +30,27 @@
 ;; uce-reply-to-uce.  Please let me know about your changes so I can
 ;; incorporate them.  I'd appreciate it.
 
+;; -- !!! NOTE !!! ---------------------------------------------
+;;
+;; Replying to spam is at best pointless, but most likely actively
+;; harmful.
+;;
+;; - You will confirm that your email address is valid, thus ensuring
+;;   you get more spam.
+;;
+;; - You will leak information and open yourself up for further
+;;   attack.  For example, they could use your \"geolocation\" to find
+;;   your home address and phone number.
+;;
+;; - The sender address is likely fake.
+;;
+;; - You help them refine their methods of spamming.
+;;
+;; Therefore, we strongly recommend that you do not use this package.
+;; Use a spam filter instead, or just delete the spam.
+;;
+;; -------------------------------------------------------------
+
 ;; The command uce-reply-to-uce, if called when the current message
 ;; buffer is a UCE, will setup a reply *mail* buffer as follows.  It
 ;; scans the full headers of the message for: 1) the normal return
-- 
2.30.2

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 14 Oct 2021 13:45:49 -0700
> Cc: 46472@debbugs.gnu.org, rgm@gnu.org, monnier@iro.umontreal.ca
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Document: yes.  But your change modified the code as well, and more
> > importantly changed how the feature works.
> 
> This is what I suggest for emacs-28, note the "Do not merge to master"
> in the commit message.

This is okay for the release branch, thanks.

> On master, I suggest the same patch as before, but with the updated
> text that you can read here.

I'd like to see the patch for master, please.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> I'd like to see the patch for master, please.

Please see the attached.

[-- Attachment #2: master-0001-Recommend-against-using-uce.el.patch --]
[-- Type: text/x-diff, Size: 1740 bytes --]

From e2c046477798b15f30748752716b03986b356080 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 12 Oct 2021 06:30:20 +0200
Subject: [PATCH] Recommend against using uce.el

* lisp/mail/uce.el: Recommend against its use.  (Bug#46472)
Do not merge to master.
---
 lisp/mail/uce.el | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/lisp/mail/uce.el b/lisp/mail/uce.el
index b07004de38..0a0c827acd 100644
--- a/lisp/mail/uce.el
+++ b/lisp/mail/uce.el
@@ -358,7 +358,30 @@ uce-reply-to-uce
       ;; Run hooks before we leave buffer for editing.  Reasonable usage
       ;; might be to set up special key bindings, replace standard
       ;; functions in mail-mode, etc.
-      (run-hooks 'mail-setup-hook 'uce-setup-hook))))
+      (run-hooks 'mail-setup-hook 'uce-setup-hook)))
+  (pop-to-buffer (get-buffer-create "uce-reply-to-uce warning"))
+  (insert "\
+-- !!! NOTE !!! ---------------------------------------------
+
+Replying to spam is at best pointless, but most likely actively
+harmful.
+
+- You will confirm that your email address is valid, thus ensuring
+  you get more spam.
+
+- You will leak information and open yourself up for further
+  attack.  For example, they could use your \"geolocation\" to find
+  your home address and phone number.
+
+- The sender address is likely fake.
+
+- You help them refine their methods of spamming.
+
+Therefore, we strongly recommend that you do not use this package.
+Use a spam filter instead, or just delete the spam.
+
+-------------------------------------------------------------
+"))
 
 (defun uce-insert-ranting (&optional _ignored)
   "Insert text of the usual reply to UCE into current buffer."
-- 
2.30.2

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 15 Oct 2021 03:50:17 -0500
> Cc: 46472@debbugs.gnu.org, rgm@gnu.org, monnier@iro.umontreal.ca
> 
> > I'd like to see the patch for master, please.
> 
> Please see the attached.
> 
> * lisp/mail/uce.el: Recommend against its use.  (Bug#46472)

This should mention the function in which you make the change.

> Do not merge to master.

???

> --- a/lisp/mail/uce.el
> +++ b/lisp/mail/uce.el
> @@ -358,7 +358,30 @@ uce-reply-to-uce
>        ;; Run hooks before we leave buffer for editing.  Reasonable usage
>        ;; might be to set up special key bindings, replace standard
>        ;; functions in mail-mode, etc.
> -      (run-hooks 'mail-setup-hook 'uce-setup-hook))))
> +      (run-hooks 'mail-setup-hook 'uce-setup-hook)))
> +  (pop-to-buffer (get-buffer-create "uce-reply-to-uce warning"))
> +  (insert "\
> +-- !!! NOTE !!! ---------------------------------------------

This should pop only once per Emacs session, not each time the command
is invoked.

I also think we should have in the Commentary section something like
this:

  ;; We don't recommend using this feature; see the message in
  ;; 'uce-reply-to-uce' for the reasons.

Thanks.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> This should pop only once per Emacs session, not each time the command
> is invoked.

Thanks, I believe all your comments are fixed in the attached.

[-- Attachment #2: 0001-Recommend-against-using-uce.el.patch --]
[-- Type: text/x-diff, Size: 2632 bytes --]

From bc85fc30ba94b1166fc526c7bae2b373dcecaa49 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Sat, 16 Oct 2021 14:39:04 +0200
Subject: [PATCH] Recommend against using uce.el

* lisp/mail/uce.el (uce-reply-to-uce): Recommend against its use on
the first invocation.  (Bug#46472)
---
 lisp/mail/uce.el | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/lisp/mail/uce.el b/lisp/mail/uce.el
index b07004de38..4347ff1402 100644
--- a/lisp/mail/uce.el
+++ b/lisp/mail/uce.el
@@ -30,6 +30,9 @@
 ;; uce-reply-to-uce.  Please let me know about your changes so I can
 ;; incorporate them.  I'd appreciate it.
 
+;; NOTE: We don't recommend using this feature; see the message in
+;; 'uce-reply-to-uce' for the reasons.
+
 ;; The command uce-reply-to-uce, if called when the current message
 ;; buffer is a UCE, will setup a reply *mail* buffer as follows.  It
 ;; scans the full headers of the message for: 1) the normal return
@@ -213,6 +216,8 @@ rmail-buffer
 (declare-function rmail-maybe-set-message-counters "rmail" ())
 (declare-function rmail-toggle-header "rmail" (&optional arg))
 
+(defvar uce--usage-warning-displayed nil)
+
 ;;;###autoload
 (defun uce-reply-to-uce (&optional _ignored)
   "Compose a reply to unsolicited commercial email (UCE).
@@ -358,7 +363,32 @@ uce-reply-to-uce
       ;; Run hooks before we leave buffer for editing.  Reasonable usage
       ;; might be to set up special key bindings, replace standard
       ;; functions in mail-mode, etc.
-      (run-hooks 'mail-setup-hook 'uce-setup-hook))))
+      (run-hooks 'mail-setup-hook 'uce-setup-hook)))
+  (unless uce--usage-warning-displayed
+    (setq uce--usage-warning-displayed t)
+    (pop-to-buffer (get-buffer-create "uce-reply-to-uce warning"))
+    (insert "\
+-- !!! NOTE !!! ---------------------------------------------
+
+Replying to spam is at best pointless, but most likely actively
+harmful.
+
+- You will confirm that your email address is valid, thus ensuring
+  you get more spam.
+
+- You will leak information and open yourself up for further
+  attack.  For example, they could use your \"geolocation\" to find
+  your home address and phone number.
+
+- The sender address is likely fake.
+
+- You help them refine their methods of spamming.
+
+Therefore, we strongly recommend that you do not use this package.
+Use a spam filter instead, or just delete the spam.
+
+-------------------------------------------------------------
+")))
 
 (defun uce-insert-ranting (&optional _ignored)
   "Insert text of the usual reply to UCE into current buffer."
-- 
2.30.2

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 16 Oct 2021 08:48:55 -0400
> Cc: 46472@debbugs.gnu.org, rgm@gnu.org, monnier@iro.umontreal.ca
> 
> Thanks, I believe all your comments are fixed in the attached.

Yes, thanks.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Thanks, I believe all your comments are fixed in the attached.
>
> Yes, thanks.

Thanks, pushed to master as commit 735086e440.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> This is okay for the release branch, thanks.

Thanks, pushed to emacs-28 (commit 1dfe9d6285).  I will send the updated
patch for master shortly.

bug#46472: Make lisp/mail/uce.el obsolete

[Stefan Monnier]

>> So how about moving it to obsolete/?

You have my vote.

> What are the reasons for moving uce.el to obsolete/ ?

I don't think it's useful to anyone.
Moving it to `obsolete` might let us discover that I'm wrong on this
point, of course ;-)


        Stefan

bug#46472: Make lisp/mail/uce.el obsolete

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Kangas <stefan@marxist.se>,  46472@debbugs.gnu.org
> Date: Wed, 03 Mar 2021 16:22:16 -0500
> 
> > What are the reasons for moving uce.el to obsolete/ ?
> 
> I don't think it's useful to anyone.
> Moving it to `obsolete` might let us discover that I'm wrong on this
> point, of course ;-)

I'm against this method of "discovery", sorry.  This package doesn't
require any maintenance, so let's not invent any maintenance for it.
We have more important things to do with our time (I hope).