From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 31 09:08:58 2022 Received: (at submit) by debbugs.gnu.org; 31 Jul 2022 13:08:58 +0000 Received: from localhost ([127.0.0.1]:36541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI8gd-0007LT-5N for submit@debbugs.gnu.org; Sun, 31 Jul 2022 09:08:58 -0400 Received: from lists.gnu.org ([209.51.188.17]:56692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI8ga-0007LK-6c for submit@debbugs.gnu.org; Sun, 31 Jul 2022 09:08:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI8gZ-0000C6-OR for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 09:08:48 -0400 Received: from harrington.uberspace.de ([185.26.156.85]:59556) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI8gX-0005Dv-Rw for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 09:08:47 -0400 Received: (qmail 14611 invoked by uid 500); 31 Jul 2022 13:08:37 -0000 Authentication-Results: harrington.uberspace.de; auth=pass (plain) From: Justus Winter To: bug-gnu-emacs@gnu.org Subject: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr Date: Sun, 31 Jul 2022 15:08:28 +0200 Message-ID: <87wnbtig4z.fsf@thinkbox> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Bar: -- X-Rspamd-Report: MIME_GOOD(-0.1) MID_RHS_NOT_FQDN(0.5) BAYES_HAM(-2.909661) X-Rspamd-Score: -2.509661 Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Sun, 31 Jul 2022 15:08:37 +0200 Received-SPF: none client-ip=185.26.156.85; envelope-from=justus@sequoia-pgp.org; helo=harrington.uberspace.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) sendmail-send-it considers it an error if sendmail wrote to stdout/stderr, despite the fact that the process returned success. I use msmtp with the authentication password encrypted using OpenPGP. Then, I use 'gpg --no-tty -q -d ...' as msmtp's passwordeval function. Now, my OpenPGP key has expired, but that doesn't stop GnuPG from decrypting the secret, and in fact it returns the status code 0. It also prints gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST to stderr, which is picked up by emacs, it says sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST in the status buffer while the compose buffer stays open. Note that despite this, the message has been sent successfully, while emacs indicates that the sending has failed. I wrote to the notmuch mailing list before investigating further, and at least one other person hat a similar problem. The thread is here: https://nmbug.notmuchmail.org/nmweb/show/87k080jgx8.fsf%40thinkbox I dug into emacs, and discovered that indeed sendmail-send-it considers any output from the sendmail process to be an indication of an error, even if the process returned 0. I read documentation of various sendmail implementations, and all agreed that returning success meant that the operation succeeded. I found no justification for emacs thinking that the operation failed if the process printed to stdout or stderr. Best, Justus From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 01 16:46:28 2022 Received: (at 56855) by debbugs.gnu.org; 1 Aug 2022 20:46:28 +0000 Received: from localhost ([127.0.0.1]:41713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIcJ2-0003M4-8w for submit@debbugs.gnu.org; Mon, 01 Aug 2022 16:46:28 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:52441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIcIy-0003Ln-Vb for 56855@debbugs.gnu.org; Mon, 01 Aug 2022 16:46:27 -0400 Received: (Authenticated sender: matt@rfc20.org) by mail.gandi.net (Postfix) with ESMTPSA id D0C96200003; Mon, 1 Aug 2022 20:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rfc20.org; s=gm1; t=1659386778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NDA/RXd3zXmhwTFpx58jCdi5xEfgwjFvqMmT0ruC1+A=; b=L3ON0E0C1BEUbfCAwjoTBgfoNbRo0+h4IjSJkNeNpnM+LqJow/cu/3/ji6Zlt9dTLSc0GU xSme28sxEl7Sp7/znbMevC2YUpQvKvpJnidwi8RY3m7LDBg0PQuCjUVosBtW7bRH7Eps9c znxQnSZuLfj0WUMGagOPO6OsFIFdaEfQLqtBBxUCsLIhMtz4QrNQ59qrPIgBUaMIrH4MSK BbSg89R1mpAzQZpRITrmGALTdi4fdr+qByy0/vucNTc4CjRVI1UxnSerxAVAgGIFuwJ5D3 sG84wrBtKygYtqYS/1qQmRSnHlKrAeS4FISqlzqNa4MraWFhPdqBHE1c0gfg0A== Received: from matt by naz with local (Exim 4.96) (envelope-from ) id 1oIcIp-00176S-0K; Mon, 01 Aug 2022 13:46:15 -0700 From: Matt Armstrong To: Justus Winter , 56855@debbugs.gnu.org Subject: Re: bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr In-Reply-To: <87wnbtig4z.fsf@thinkbox> References: <87wnbtig4z.fsf@thinkbox> Date: Mon, 01 Aug 2022 13:46:15 -0700 Message-ID: <87o7x34rqg.fsf@rfc20.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 56855 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Justus Winter writes: > sendmail-send-it considers it an error if sendmail wrote to > stdout/stderr, despite the fact that the process returned success. [...] > I read documentation of various sendmail implementations, and all > agreed that returning success meant that the operation succeeded. I > found no justification for emacs thinking that the operation failed if > the process printed to stdout or stderr. This is perhaps surprising. It is also behavior that has come to be expected, especially in more traditional Unix programs. E.g. crontab also considers jobs that print to stderr to have an error, regardless of exit status. >From the sendmail(8) manpage we have this statement: Sendmail is not intended as a user interface routine; other programs provide user-friendly front ends; sendmail is used only to deliver pre-formatted messages. An implementation of the "sendmail program" should probably emulate the original sendmail as closely as possible. It prints no messages when it succeeds. On this we do have roughly 35 years of historical precedent, since the original Sendmail began in the mid-80s. :-) This may seem like a historical wart, but I have personally found this behavior to be helpful, especially in programs that are typically run non-interactively and "out of sight" like a crontab or sendmail wrapper script. E.g. when a shell script prints to stderr there may indeed have been a problem, but a bug in the script may still have caused it to exit with zero regardless. It is usually easy to arange for such programs to print nothing when they succeed. > I use msmtp with the authentication password encrypted using OpenPGP. > Then, I use 'gpg --no-tty -q -d ...' as msmtp's passwordeval function. > Now, my OpenPGP key has expired, but that doesn't stop GnuPG from > decrypting the secret, and in fact it returns the status code 0. It > also prints > > gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST > > to stderr, which is picked up by emacs, it says > > sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST > > in the status buffer while the compose buffer stays open. Note that > despite this, the message has been sent successfully, while emacs > indicates that the sending has failed. Can you configure your msmtp to behave like sendmail and refrain from printing human readable messages upon success? Perhaps the --logger-fd or --logger-file arguments to gpg could be used to direct the output you do not wish to read to /dev/null? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 01:59:24 2022 Received: (at 56855) by debbugs.gnu.org; 2 Aug 2022 05:59:24 +0000 Received: from localhost ([127.0.0.1]:42061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIkw8-00081X-1X for submit@debbugs.gnu.org; Tue, 02 Aug 2022 01:59:24 -0400 Received: from harrington.uberspace.de ([185.26.156.85]:42540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIkw6-00081M-H4 for 56855@debbugs.gnu.org; Tue, 02 Aug 2022 01:59:23 -0400 Received: (qmail 28787 invoked by uid 500); 2 Aug 2022 05:59:19 -0000 Authentication-Results: harrington.uberspace.de; auth=pass (plain) From: Justus Winter To: Matt Armstrong , 56855@debbugs.gnu.org Subject: Re: bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr In-Reply-To: <87o7x34rqg.fsf@rfc20.org> References: <87wnbtig4z.fsf@thinkbox> <87o7x34rqg.fsf@rfc20.org> Date: Tue, 02 Aug 2022 07:59:06 +0200 Message-ID: <875yjbi3th.fsf@thinkbox> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Bar: / X-Rspamd-Report: MIME_GOOD(-0.1) MID_RHS_NOT_FQDN(0.5) BAYES_HAM(-1.11445) X-Rspamd-Score: -0.71445 Received: from unknown (HELO unkown) (::1) by harrington.uberspace.de (Haraka/2.8.28) with ESMTPSA; Tue, 02 Aug 2022 07:59:19 +0200 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 56855 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Matt Armstrong writes: > Justus Winter writes: > >> sendmail-send-it considers it an error if sendmail wrote to >> stdout/stderr, despite the fact that the process returned success. > > [...] > >> I read documentation of various sendmail implementations, and all >> agreed that returning success meant that the operation succeeded. I >> found no justification for emacs thinking that the operation failed if >> the process printed to stdout or stderr. > > This is perhaps surprising. It is also behavior that has come to be > expected, especially in more traditional Unix programs. E.g. crontab > also considers jobs that print to stderr to have an error, regardless of > exit status. >From man cron(8) I see: When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists) from the owner of the crontab (or from the email address given in the MAILFROM environment variable in the crontab, if such exists). Note how it says nothing about considering it an error. In fact, I did an experiment on my cron implementation (ISC cron 3.0pl1-149 as packaged by Debian), and it did send me any output written to stdout or stderr regardless of the exit status, and it did *not* notify me of a failing command if no output was written. Clearly, sending mails is orthogonal to the exit status as far as cron is concerned. > From the sendmail(8) manpage we have this statement: > > Sendmail is not intended as a user interface routine; other programs > provide user-friendly front ends; sendmail is used only to deliver > pre-formatted messages. > > An implementation of the "sendmail program" should probably emulate the > original sendmail as closely as possible. It prints no messages when it > succeeds. I don't read the snippet you quoted as promising to never send text to stderr if the process succeeds. Now, I don't know which version of the manpage you consider authoritative, but I found e.g. https://linux.die.net/man/8/sendmail.sendmail which does contain your snippet, and then clearly states: Sendmail returns an exit status describing what it did. The codes are defined in : EX_OK Successful completion on all addresses. And: % grep EX_OK /usr/include/sysexits.h #define EX_OK 0 /* successful termination */ > On this we do have roughly 35 years of historical precedent, since the > original Sendmail began in the mid-80s. :-) Well, happily, we're also 35 years wiser than to trust the original sendmail with anything. > This may seem like a historical wart, but I have personally found this > behavior to be helpful, especially in programs that are typically run > non-interactively and "out of sight" like a crontab or sendmail wrapper > script. E.g. when a shell script prints to stderr there may indeed have > been a problem, but a bug in the script may still have caused it to exit > with zero regardless. It is usually easy to arange for such programs to > print nothing when they succeed. I don't understand that argument. I agree that seeing the output is beneficial, but then you say that it is easy to suppress that output, the same output that seeing you deemed beneficial just a few lines earlier. In fact, I think we should ask what the best thing is for the user. I think that (a) emacs should correctly indicate whether sending the mail succeeded or not, and (b) any warnings should be presented to the user. Currently, emacs fails at (a) and your workaround violates (b). >> I use msmtp with the authentication password encrypted using OpenPGP. >> Then, I use 'gpg --no-tty -q -d ...' as msmtp's passwordeval function. >> Now, my OpenPGP key has expired, but that doesn't stop GnuPG from >> decrypting the secret, and in fact it returns the status code 0. It >> also prints >> >> gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST >> >> to stderr, which is picked up by emacs, it says >> >> sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 05:31:26 PM CEST >> >> in the status buffer while the compose buffer stays open. Note that >> despite this, the message has been sent successfully, while emacs >> indicates that the sending has failed. > > Can you configure your msmtp to behave like sendmail and refrain from > printing human readable messages upon success? Perhaps the --logger-fd > or --logger-file arguments to gpg could be used to direct the output you > do not wish to read to /dev/null? Yes I can, but the question is: should I have to? Best, Justus From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 06:44:20 2022 Received: (at 56855) by debbugs.gnu.org; 2 Aug 2022 10:44:20 +0000 Received: from localhost ([127.0.0.1]:42462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpNs-0005S3-2c for submit@debbugs.gnu.org; Tue, 02 Aug 2022 06:44:20 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpNq-0005Ro-1q for 56855@debbugs.gnu.org; Tue, 02 Aug 2022 06:44:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=17G5Utou2juXnD2C9eujkE8yCX3ojJeASP+RPMJMBKY=; b=IvaEb0TPGvMGPJKbJaH97t77tj YYGi40aHeL1btIonS9W+qXdIpaq1iFxIhF3vzZW59PACIa2Gws1db/5Qn9YODxtfUU+uMxyeyV+8H B6H+GYEOlI1GQkysDWRowKYnvNF45by+aaTr7LsgaGBbnFl2oB0yd4ZhqOIPMngXWoLo=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oIpNg-0007Q5-K4; Tue, 02 Aug 2022 12:44:10 +0200 From: Lars Ingebrigtsen To: Justus Winter Subject: Re: bug#56855: 27.1; sendmail-send-it considers it an error if sendmail wrote to stdout/stderr In-Reply-To: <875yjbi3th.fsf@thinkbox> (Justus Winter's message of "Tue, 02 Aug 2022 07:59:06 +0200") References: <87wnbtig4z.fsf@thinkbox> <87o7x34rqg.fsf@rfc20.org> <875yjbi3th.fsf@thinkbox> X-Now-Playing: Thick Pigeon's _Too Crazy Cowboys_: "Babcock + Wilcox" Date: Tue, 02 Aug 2022 12:44:08 +0200 Message-ID: <87h72vylfr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Justus Winter writes: > In fact, I think we should ask what the best thing is for the user. I > think that (a) emacs should correctly indicate whether sending the mail > succeeded or not, and (b) any warnings should be pre [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 56855 Cc: Matt Armstrong , 56855@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Justus Winter writes: > In fact, I think we should ask what the best thing is for the user. I > think that (a) emacs should correctly indicate whether sending the mail > succeeded or not, and (b) any warnings should be presented to the user. Your argument makes sense, but there's a lot of systems out there, and there's a lot of different things people use in place of `sendmail-program'. Emacs' contract with the user here has been (for 35 years) to consider any output from these programs as an error condition, and changing that will inevitably lead to people losing mail, because they're using that contract. As a practical matter, accepting a SUCCESS exit code as a success, but then showing the extra text isn't much friendlier than signalling an error -- users don't want to see warnings every time they send a mail, so they'll have to fix whatever program they're using for `sendmail-program'. So I think the fix here is to just document that output is considered failure, and I've now done this in Emacs 29, and is therefore closing this bug report. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 02 06:44:22 2022 Received: (at control) by debbugs.gnu.org; 2 Aug 2022 10:44:22 +0000 Received: from localhost ([127.0.0.1]:42465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpNu-0005SL-CN for submit@debbugs.gnu.org; Tue, 02 Aug 2022 06:44:22 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIpNs-0005Rs-J8 for control@debbugs.gnu.org; Tue, 02 Aug 2022 06:44:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q3TaJU0/J2jCmp8lwDTnU/fkR0PwOMGJFesLhDySKq0=; b=C3dBAdP9h4lafVO2f53Bqj9sGH pt+ZDU3bU/MSJTnIIGmq2Q/gXG1khd6SLWLBm+/i4YX/NiX+T0EzdlgmP7FQ9ZmcG+2UkPOayP11i 2hc+UqbGiUrZIZIRgSipcaYArtqn62EgAdXs2V4ORS/PPrA0UxVm8VPJtxamCigEpB5A=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oIpNk-0007QG-Vk for control@debbugs.gnu.org; Tue, 02 Aug 2022 12:44:14 +0200 Date: Tue, 02 Aug 2022 12:44:12 +0200 Message-Id: <87fsifylfn.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #56855 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 56855 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 56855 29.1 quit From unknown Sun Jun 22 07:40:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 30 Aug 2022 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator