GNU bug report logs - #26102
movemail can't connect mail server

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26102 in the body.
You can then email your comments to 26102 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Õžü·å" <hengaini2055 <at> qq.com>
To: "bug-gnu-emacs" <bug-gnu-emacs <at> gnu.org>
Subject: movemail can't connect mail server
Date: Wed, 15 Mar 2017 09:14:19 +0800

[Message part 1 (text/plain, inline)]

From: hengaini2055 <at> qq.com
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; 
Date: Wed, 15 Mar 2017 09:11:30 +0800
Message-ID: <8760jb1gzh.fsf <at> HENGAINI2055-PC.i-did-not-set--mail-host-address--so-tickle-me>
--text follows this line--




I can't receive mail using rmail. When I use the command(movemail -p
"pop://hengaini:password <at> pop.qq.com:995"), I get the following errors:


> d:\emacs-25.1\libexec\emacs\25.1\x86_64-w64-mingw32>movemail -p 'pop://hengaini2055 <at> 163.177.72.198:995' Test.mbox 'password'
> movemail -p 'pop://hengaini2055 <at> 163.177.72.198:995' Test.mbox 'password'
> movemail: Invalid argument for 'pop://hengaini2055 <at> 163.177.72.198:995'


Is this a bug?








In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-18 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'


Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS


Important settings:
  value of $LANG: CHS
  locale-coding-system: cp936


Major mode: Dired by name


Minor modes in effect:
  diff-hl-dired-mode: t
  desktop-save-mode: t
  editorconfig-mode: t
  global-diff-hl-mode: t
  diff-auto-refine-mode: t
  winner-mode: t
  global-undo-tree-mode: t
  global-anzu-mode: t
  anzu-mode: t
  projectile-mode: t
  volatile-highlights-mode: t
  global-hl-line-mode: t
  recentf-mode: t
  savehist-mode: t
  save-place-mode: t
  show-smartparens-global-mode: t
  global-auto-revert-mode: t
  delete-selection-mode: t
  prelude-global-mode: t
  prelude-mode: t
  shell-dirtrack-mode: t
  which-key-mode: t
  beacon-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t


Recent messages:
Loading c:/Users/hengaini2055/AppData/Roaming/.emacs.d/personal/custom.el (source)...done
Prelude is ready to do thy bidding, Master hengaini2055!
Can¡¯t guess python-indent-offset, using defaults: 4
Using vacuous schema
Setting up indent for shell type sh
Indentation variables are now local.
Indentation setup for shell type sh
Wrote c:/Users/hengaini2055/AppData/Roaming/.emacs.d/.emacs.desktop.lock
Desktop: 1 frame, 20 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.


Load-path shadows:
c:/Users/hengaini2055/AppData/Roaming/.emacs.d/elpa/seq-2.19/seq hides d:/emacs-25.1/share/emacs/25.1/lisp/emacs-lisp/seq


Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec epg mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils sh-script smie executable
nxml-uchnm rng-xsd xsd-regexp rng-cmpct nxml-mode-expansions
html-mode-expansions sgml-mode smartparens-html rng-nxml rng-valid
rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn
nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc
xmltok vc-mtn vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs
diff-hl-dired vc-git editorconfig-core editorconfig-core-handle
editorconfig-fnmatch python-el-fgallina-expansions smartparens-python
python tramp-sh desktop frameset cus-start cus-load
prelude-global-keybindings prelude-editor editorconfig operate-on-number
calc-bin calc-ext calc calc-loaddefs calc-macs diff-hl smartrep vc-dir
ewoc vc vc-dispatcher diff-mode winner undo-tree diff esh-var esh-io
esh-cmd esh-opt esh-ext esh-proc esh-arg esh-groups eshell esh-module
esh-mode esh-util re-builder whitespace tabify browse-kill-ring derived
midnight ediff-merg ediff-wind ediff-diff ediff-mult ediff-help
ediff-init ediff-util ediff dired-x dired anzu avy projectile grep
compile ibuf-ext ibuffer bookmark pp expand-region text-mode-expansions
er-basic-expansions expand-region-core expand-region-custom flyspell
ispell rect etags xref project volatile-highlights hl-line windmove
recentf tree-widget wid-edit savehist saveplace diminish
smartparens-config smartparens autorevert filenotify delsel prelude-mode
easy-mmode edmacro kmacro crux ido tramp tramp-compat tramp-loaddefs
trampver shell pcomplete comint ansi-color ring format-spec
imenu-anywhere imenu prelude-core epl ov thingatpt prelude-ui which-key
beacon smart-mode-line rich-minority zenburn-theme prelude-custom
prelude-packages finder-inf gh-common gh-profile url-parse auth-source
gnus-util mm-util help-fns mail-prsvr password-cache url-vars rx s
ucs-normalize marshal eieio-compat cl-seq ht json map dash eieio
eieio-core cl-macs advice info package epg-config seq byte-opt bytecomp
byte-compile cl-extra help-mode easymenu cconv cl gv cl-loaddefs pcase
cl-lib time-date mule-util china-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)


Memory information:
((conses 16 515133 315754)
 (symbols 56 46052 34)
 (miscs 48 257 1048)
 (strings 32 112634 210758)
 (string-bytes 1 3598720)
 (vectors 16 69469)
 (vector-slots 8 1754352 281655)
 (floats 8 593 766)
 (intervals 56 1199 841)
 (buffers 976 45))

[Message part 2 (text/html, inline)]

Message #8 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: hengaini2055 <at> qq.com
Cc: 26102 <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 17:49:57 +0200

> From: hengaini2055 <at> qq.com
> Date: Wed, 15 Mar 2017 09:14:19 +0800
> 
> I can't receive mail using rmail. When I use the command(movemail -p
> "pop://hengaini:password <at> pop.qq.com:995"), I get the following errors:
> 
> > d:\emacs-25.1\libexec\emacs\25.1\x86_64-w64-mingw32>movemail -p
> 'pop://hengaini2055 <at> 163.177.72.198:995' Test.mbox 'password'
> > movemail -p 'pop://hengaini2055 <at> 163.177.72.198:995' Test.mbox 'password'
> > movemail: Invalid argument for 'pop://hengaini2055 <at> 163.177.72.198:995'
> 
> Is this a bug?

No, I don't think it's a bug.  But you expect some features that
aren't supported by movemail.

First, movemail that comes with Emacs doesn't accept pop:// "URLs", it
only accepts the form po:USERNAME:HOSTNAME, so you need to invoke it
like this:

  movemail -p po:hengaini2055:163.177.72.198:995 Test.mbox password

Second, Windows doesn't support '..' style of quoting, you need to use
the ".." style instead.

And third, movemail that comes with Emacs doesn't support the ":port"
part of the POP inbox (":995" in your case).  I'm guessing that you
are using port 995 because your POP server requires SSL/TLS
connections, in which case that's another problem: movemail that comes
with Emacs doesn't support such connections.

So you need first find a version of movemail from GNU Mailutils, which
can support all those missing features.  Then you need to configure
Rmail with the name of your POP mailbox, so that Rmail will invoke
movemail correctly.  And then it will work.

Message #11 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: hengaini2055 <at> qq.com, 26102 <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 10:30:44 -0700

> I'm guessing that you
> are using port 995 because your POP server requires SSL/TLS
> connections, in which case that's another problem: movemail that comes
> with Emacs doesn't support such connections.
How about if we change Emacs so that it relies on GNU Mailutils 
movemail, instead of installing its own movemail? This should help 
prevent similar problems in the future, and should simplify Emacs 
maintenance a bit. These days it's almost malpractice to ship a mail 
client that supports only unencrypted network connections.

Message #14 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: hengaini2055 <at> qq.com, 26102 <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 19:48:57 +0200

> Cc: hengaini2055 <at> qq.com, 26102 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 15 Mar 2017 10:30:44 -0700
> 
> > I'm guessing that you
> > are using port 995 because your POP server requires SSL/TLS
> > connections, in which case that's another problem: movemail that comes
> > with Emacs doesn't support such connections.
> How about if we change Emacs so that it relies on GNU Mailutils 
> movemail, instead of installing its own movemail?

I don't understand what that means in practice.  We already support
GNU Mailutils, and its movemail is even described in the manual.

Message #17 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 26102 <at> debbugs.gnu.org,
 hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 14:15:48 -0400

Eli Zaretskii wrote:

>> How about if we change Emacs so that it relies on GNU Mailutils 
>> movemail, instead of installing its own movemail?
>
> I don't understand what that means in practice.  We already support
> GNU Mailutils, and its movemail is even described in the manual.

I assume it means stop distributing our own partial movemail, and
require people who want to use Emacs for mail in this way to install the
superior version from GNU Mailutils. I support this proposal. I think it
is good general practice to reduce the number of things that need to be
maintained in Emacs.

Message #24 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 26102 <at> debbugs.gnu.org, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 20:20:35 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  hengaini2055 <at> qq.com,  26102 <at> debbugs.gnu.org
> Date: Wed, 15 Mar 2017 14:15:48 -0400
> 
> Eli Zaretskii wrote:
> 
> >> How about if we change Emacs so that it relies on GNU Mailutils 
> >> movemail, instead of installing its own movemail?
> >
> > I don't understand what that means in practice.  We already support
> > GNU Mailutils, and its movemail is even described in the manual.
> 
> I assume it means stop distributing our own partial movemail, and
> require people who want to use Emacs for mail in this way to install the
> superior version from GNU Mailutils. I support this proposal. I think it
> is good general practice to reduce the number of things that need to be
> maintained in Emacs.

We already find movemail from Mailutils, if installed, before we find
our own.  And our movemail requires zero maintenance.  In this
situation, removing our version means just removing features, no more,
no less.  I'm against removing features for no good reason.

Message #27 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
 26102 <at> debbugs.gnu.org, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 16:03:18 -0400

On Wed, Mar 15, 2017 at 2:20 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> I assume it means stop distributing our own partial movemail, and
>> require people who want to use Emacs for mail in this way to install the
>> superior version from GNU Mailutils. I support this proposal. I think it
>> is good general practice to reduce the number of things that need to be
>> maintained in Emacs.
>
> We already find movemail from Mailutils, if installed, before we find
> our own.  And our movemail requires zero maintenance.  In this
> situation, removing our version means just removing features, no more,
> no less.  I'm against removing features for no good reason.

Currently we release Emacs with a movemail implementation lacking the
usual features. This may confuse users, like the OP.
Is avoiding this confusion a good enough reason?

Message #30 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Glenn Morris <rgm <at> gnu.org>
Cc: hengaini2055 <at> qq.com, 26102 <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 15:48:50 -0700

[Message part 1 (text/plain, inline)]

On 03/15/2017 11:20 AM, Eli Zaretskii wrote:
> I'm against removing features for no good reason.

Sure, but there is a good reason here: Emacs movemail supports only 
unencrypted POP3 connections, which has real security problems in 
typical network environments today. Also, as can be seen earlier in this 
thread, having two 'movemail' commands confuses users and can trip them up.

I take your point that there is a backwards-compatibility argument for 
installing a movemail program that converts mailboxes from system format 
to Emacs format, when GNU Mailutils is not available. However, we should 
not distribute a movemail program that encourages users to read their 
mail unencrypted over a network -- although that may have been OK in the 
1980s when POP support was added to movemail, it's a grave disservice to 
users in typical environments today.

Attached are two proposed patches to try to improve the current 
situation. The first removes unencrypted POP3 support from Emacs 
movemail, as it's a significant security blunder to insist on 
unencrypted network connections these days. The second changes the Emacs 
build procedure so that there is a configure-time option for whether to 
install the substitute 'movemail' program instead of relying on GNU 
Mailutils 'movemail'; the idea is to let distributors decide whether to 
make GNU Mailutils be a prerequisite for reading email in Emacs.

[0001-Drop-POP-from-movemail.patch (application/x-patch, attachment)]

[0002-Emacs-movemail-is-now-a-configure-time-option.patch (application/x-patch, attachment)]

Message #33 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 26102 <at> debbugs.gnu.org, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Wed, 15 Mar 2017 20:15:02 -0400

Eli Zaretskii wrote:

> We already find movemail from Mailutils, if installed, before we find
> our own.  And our movemail requires zero maintenance.  In this
> situation, removing our version means just removing features, no more,
> no less.  I'm against removing features for no good reason.

It's your decision to make, of course.
(I'd be interested to hear what your co-maintainer's position on this
general issue is.)

I want to point out that answering (or reading) this bug report (and the
previous help-gnu-emacs post) is an act that takes maintainer time,
therefore the maintenance cost is not zero.
(Obviously Paul and I have increased the short-term cost by starting a
discussion, but the cost was there before.)
And when anyone needs to read (whether or not they change it) the
relevant support code in rmail or lib-src/Makefile, that's a cost too.
Yes, the cost is very small, but these things add up over time.

We clearly don't have enough people to maintain the code we have.
So personally I'm pro-simplification - expect more reports along those
lines from me, and I'll expect similar responses from you. :)

Message #36 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: rgm <at> gnu.org, eggert <at> cs.ucla.edu, 26102 <at> debbugs.gnu.org, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Thu, 16 Mar 2017 05:31:53 +0200

> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Wed, 15 Mar 2017 16:03:18 -0400
> Cc: Glenn Morris <rgm <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>, 26102 <at> debbugs.gnu.org, 
> 	hengaini2055 <at> qq.com
> 
> > We already find movemail from Mailutils, if installed, before we find
> > our own.  And our movemail requires zero maintenance.  In this
> > situation, removing our version means just removing features, no more,
> > no less.  I'm against removing features for no good reason.
> 
> Currently we release Emacs with a movemail implementation lacking the
> usual features. This may confuse users, like the OP.
> Is avoiding this confusion a good enough reason?

That confusion wouldn't be solved by removing our movemail, because 3
out of 4 problems in OP's command will also fail the version from
Mailutils, and the 4th is taken care of by Rmail, which converts the
pop:// "URL" to the "po:" form when it invokes movemail.

Message #39 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rgm <at> gnu.org, hengaini2055 <at> qq.com, 26102 <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Thu, 16 Mar 2017 17:31:22 +0200

> Cc: hengaini2055 <at> qq.com, 26102 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 15 Mar 2017 15:48:50 -0700
> 
>     I'm against removing features for no good reason.
> 
> Sure, but there is a good reason here: Emacs movemail supports only unencrypted POP3 connections, which has real security problems in typical network environments today.

Which is why Rmail prefers Mailutils, if installed.

> Also, as can be seen earlier in this thread, having two 'movemail' commands confuses users and can trip them up.

As I wrote elsewhere, the confusion which started this thread has
nothing to do with how many movemail's and of which origin are
installed.  The cockpit errors in the command line would have failed
with any version of movemail.  Moreover, AFAIK there's no Windows port
of GNU Mailutils, so no way to have more than one version of movemail
on that OS, for which the bug was filed.

> I take your point that there is a backwards-compatibility argument for installing a movemail program that converts mailboxes from system format to Emacs format, when GNU Mailutils is not available. However, we should not distribute a movemail program that encourages users to read their mail unencrypted over a network -- although that may have been OK in the 1980s when POP support was added to movemail, it's a grave disservice to users in typical environments today.

It's not a disservice.  No one forces users to use this version, let
alone encourages them.  Quite the contrary.

> Attached are two proposed patches to try to improve the current situation. The first removes unencrypted POP3 support from Emacs movemail, as it's a significant security blunder to insist on unencrypted network connections these days. The second changes the Emacs build procedure so that there is a configure-time option for whether to install the substitute 'movemail' program instead of relying on GNU Mailutils 'movemail'; the idea is to let distributors decide whether to make GNU Mailutils be a prerequisite for reading email in Emacs.

Both patches, as proposed, are too drastic.  I could agree to the
second one, provided that the default is changed to build and install
our movemail -- this will let distributors decide whether to install
it or not, while keeping backward compatibility.  (The NEWS part of
your patch should then be changed accordingly.)

Thanks.

Message #42 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 26102 <at> debbugs.gnu.org, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Thu, 16 Mar 2017 17:33:03 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: eggert <at> cs.ucla.edu,  hengaini2055 <at> qq.com,  26102 <at> debbugs.gnu.org
> Date: Wed, 15 Mar 2017 20:15:02 -0400
> 
> I want to point out that answering (or reading) this bug report (and the
> previous help-gnu-emacs post) is an act that takes maintainer time,
> therefore the maintenance cost is not zero.

It's zero as in "negligible", since the time it took to understand the
cockpit errors was short, and it's not like questions about movemail
get posted frequently (I don't remember any for a long time).

Neither did I see anyone from the developers group besides myself
interested in answering the question, as long as the actual problem
was on the table.

> (Obviously Paul and I have increased the short-term cost by starting a
> discussion

Indeed.

> And when anyone needs to read (whether or not they change it) the
> relevant support code in rmail or lib-src/Makefile, that's a cost too.
> Yes, the cost is very small, but these things add up over time.
> 
> We clearly don't have enough people to maintain the code we have.
> So personally I'm pro-simplification

In general, so am I.  But this particular bike shed is not worth
wasting time on.

Message #47 received at 26102-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, hengaini2055 <at> qq.com, 26102-done <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Fri, 17 Mar 2017 00:23:47 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii wrote:
> Both patches, as proposed, are too drastic.  I could agree to the
> second one, provided that the default is changed to build and install
> our movemail -- this will let distributors decide whether to install
> it or not, while keeping backward compatibility.  (The NEWS part of
> your patch should then be changed accordingly.)

OK, I installed the second patch with modifications along the lines that you 
suggested, updated the documentation accordingly, and am closing this bug 
report. The patch that I installed is attached.

As the default Emacs configuration still has a significant security hole, this 
patch changes 'configure' to warn about the problem if present. Although many 
distributors and/or installers will no doubt ignore the warning, at least we can 
later say in our defense that 'configure' warned them.

[0001-Emacs-movemail-is-now-a-configure-time-option.patch (text/x-diff, attachment)]

Message #50 received at 26102-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rgm <at> gnu.org, hengaini2055 <at> qq.com, 26102-done <at> debbugs.gnu.org
Subject: Re: bug#26102: movemail can't connect mail server
Date: Fri, 17 Mar 2017 10:58:27 +0200

> Cc: rgm <at> gnu.org, hengaini2055 <at> qq.com, 26102-done <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 17 Mar 2017 00:23:47 -0700
> 
> Eli Zaretskii wrote:
> > Both patches, as proposed, are too drastic.  I could agree to the
> > second one, provided that the default is changed to build and install
> > our movemail -- this will let distributors decide whether to install
> > it or not, while keeping backward compatibility.  (The NEWS part of
> > your patch should then be changed accordingly.)
> 
> OK, I installed the second patch with modifications along the lines that you 
> suggested, updated the documentation accordingly, and am closing this bug 
> report. The patch that I installed is attached.
> 
> As the default Emacs configuration still has a significant security hole, this 
> patch changes 'configure' to warn about the problem if present. Although many 
> distributors and/or installers will no doubt ignore the warning, at least we can 
> later say in our defense that 'configure' warned them.

Thanks.

Message #53 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 26102 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Fri, 17 Mar 2017 11:49:13 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> As the default Emacs configuration still has a significant security
> hole, this patch changes 'configure' to warn about the problem if
> present.

Is there any reason rmail doesn't just use pop3.el instead of the
movemail binary when speaking to pop3 servers?

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

Message #56 received at 26102 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: eggert <at> cs.ucla.edu, 26102 <at> debbugs.gnu.org, hengaini2055 <at> qq.com
Subject: Re: bug#26102: movemail can't connect mail server
Date: Fri, 17 Mar 2017 12:56:25 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 17 Mar 2017 11:49:13 +0100
> Cc: eggert <at> cs.ucla.edu, hengaini2055 <at> qq.com
> 
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
> 
> > As the default Emacs configuration still has a significant security
> > hole, this patch changes 'configure' to warn about the problem if
> > present.
> 
> Is there any reason rmail doesn't just use pop3.el instead of the
> movemail binary when speaking to pop3 servers?

I guess because no one wrote the code to support that.  movemail
supports many different protocols, including /var/mail files etc., so
Rmail needs just rudimentary understanding of the inbox syntax spec to
invoke movemail correctly.  To single out POP3 would need a bit more
code, but nothing too complicated, of course.

Patches welcome.  (For backward compatibility, the old code that uses
movemail for POP3 should still be kept, I think, subject to some user
option.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.