* bug#26102: movemail can't connect mail server
@ 2017-03-15 1:14 �ž��
2017-03-15 15:49 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: �ž�� @ 2017-03-15 1:14 UTC (permalink / raw)
To: 26102
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 6204 bytes --]
From: hengaini2055@qq.com
To: bug-gnu-emacs@gnu.org
Subject: 25.1;
Date: Wed, 15 Mar 2017 09:11:30 +0800
Message-ID: <8760jb1gzh.fsf@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@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@163.177.72.198:995' Test.mbox 'password'
> movemail -p 'pop://hengaini2055@163.177.72.198:995' Test.mbox 'password'
> movemail: Invalid argument for 'pop://hengaini2055@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))
[-- Attachment #2: Type: text/html, Size: 7892 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 1:14 bug#26102: movemail can't connect mail server �ž��
@ 2017-03-15 15:49 ` Eli Zaretskii
2017-03-15 17:30 ` Paul Eggert
2017-03-16 0:15 ` Glenn Morris
2 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-15 15:49 UTC (permalink / raw)
To: hengaini2055; +Cc: 26102
> From: hengaini2055@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@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@163.177.72.198:995' Test.mbox 'password'
> > movemail -p 'pop://hengaini2055@163.177.72.198:995' Test.mbox 'password'
> > movemail: Invalid argument for 'pop://hengaini2055@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 1:14 bug#26102: movemail can't connect mail server �ž��
2017-03-15 15:49 ` Eli Zaretskii
@ 2017-03-15 17:30 ` Paul Eggert
2017-03-15 17:48 ` Eli Zaretskii
2017-03-16 0:15 ` Glenn Morris
2 siblings, 1 reply; 16+ messages in thread
From: Paul Eggert @ 2017-03-15 17:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: hengaini2055, 26102
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 17:30 ` Paul Eggert
@ 2017-03-15 17:48 ` Eli Zaretskii
2017-03-15 18:15 ` Glenn Morris
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-15 17:48 UTC (permalink / raw)
To: Paul Eggert; +Cc: hengaini2055, 26102
> Cc: hengaini2055@qq.com, 26102@debbugs.gnu.org
> From: Paul Eggert <eggert@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 17:48 ` Eli Zaretskii
@ 2017-03-15 18:15 ` Glenn Morris
2017-03-15 18:20 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2017-03-15 18:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Paul Eggert, 26102, hengaini2055
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 18:15 ` Glenn Morris
@ 2017-03-15 18:20 ` Eli Zaretskii
2017-03-15 20:03 ` Noam Postavsky
2017-03-15 22:48 ` Paul Eggert
0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-15 18:20 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, 26102, hengaini2055
> From: Glenn Morris <rgm@gnu.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>, hengaini2055@qq.com, 26102@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 18:20 ` Eli Zaretskii
@ 2017-03-15 20:03 ` Noam Postavsky
2017-03-16 3:31 ` Eli Zaretskii
2017-03-15 22:48 ` Paul Eggert
1 sibling, 1 reply; 16+ messages in thread
From: Noam Postavsky @ 2017-03-15 20:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Paul Eggert, 26102, hengaini2055
On Wed, Mar 15, 2017 at 2:20 PM, Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 18:20 ` Eli Zaretskii
2017-03-15 20:03 ` Noam Postavsky
@ 2017-03-15 22:48 ` Paul Eggert
2017-03-16 15:31 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Paul Eggert @ 2017-03-15 22:48 UTC (permalink / raw)
To: Eli Zaretskii, Glenn Morris; +Cc: hengaini2055, 26102
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
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.
[-- Attachment #2: 0001-Drop-POP-from-movemail.patch --]
[-- Type: application/x-patch, Size: 70902 bytes --]
[-- Attachment #3: 0002-Emacs-movemail-is-now-a-configure-time-option.patch --]
[-- Type: application/x-patch, Size: 12270 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 1:14 bug#26102: movemail can't connect mail server �ž��
2017-03-15 15:49 ` Eli Zaretskii
2017-03-15 17:30 ` Paul Eggert
@ 2017-03-16 0:15 ` Glenn Morris
2017-03-16 15:33 ` Eli Zaretskii
2 siblings, 1 reply; 16+ messages in thread
From: Glenn Morris @ 2017-03-16 0:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: eggert, 26102, hengaini2055
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. :)
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 20:03 ` Noam Postavsky
@ 2017-03-16 3:31 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-16 3:31 UTC (permalink / raw)
To: Noam Postavsky; +Cc: eggert, 26102, hengaini2055
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Wed, 15 Mar 2017 16:03:18 -0400
> Cc: Glenn Morris <rgm@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>, 26102@debbugs.gnu.org,
> hengaini2055@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-15 22:48 ` Paul Eggert
@ 2017-03-16 15:31 ` Eli Zaretskii
2017-03-17 7:23 ` Paul Eggert
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-16 15:31 UTC (permalink / raw)
To: Paul Eggert; +Cc: hengaini2055, 26102
> Cc: hengaini2055@qq.com, 26102@debbugs.gnu.org
> From: Paul Eggert <eggert@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-16 0:15 ` Glenn Morris
@ 2017-03-16 15:33 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-16 15:33 UTC (permalink / raw)
To: Glenn Morris; +Cc: eggert, 26102, hengaini2055
> From: Glenn Morris <rgm@gnu.org>
> Cc: eggert@cs.ucla.edu, hengaini2055@qq.com, 26102@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-16 15:31 ` Eli Zaretskii
@ 2017-03-17 7:23 ` Paul Eggert
2017-03-17 8:58 ` Eli Zaretskii
2017-03-17 10:49 ` Lars Ingebrigtsen
0 siblings, 2 replies; 16+ messages in thread
From: Paul Eggert @ 2017-03-17 7:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: hengaini2055, 26102-done
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
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.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Emacs-movemail-is-now-a-configure-time-option.patch --]
[-- Type: text/x-diff; name="0001-Emacs-movemail-is-now-a-configure-time-option.patch", Size: 22303 bytes --]
From e82b72bdd72f0b3ab3f5bc67840cbd65e98ef443 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 16 Mar 2017 23:50:37 -0700
Subject: [PATCH] Emacs 'movemail' is now a configure-time option
The new configure option --with-mailutils lets the builder say
that Emacs should assume that GNU Mailutils is installed, instead
of continuing to build and install its own limited and insecure
substitute for 'movemail'.
* INSTALL, etc/NEWS, etc/PROBLEMS: Mention --with-mailutils.
* configure.ac: Add --with-mailutils option.
(with_mailutils): New variable.
Do not bother configuring 'movemail' when not building it.
Warn about issues relating to --with-mailutils.
* doc/emacs/rmail.texi (Movemail): Mention --with-mailutils.
(Movemail, Remote Mailboxes): Document port numbers in
POP and IMAP URLs.
* lib-src/Makefile.in (with_mailutils): New macro.
(UTILITIES): Use it.
---
INSTALL | 22 +++++--
configure.ac | 177 ++++++++++++++++++++++++++++++---------------------
doc/emacs/rmail.texi | 82 ++++++++++++------------
etc/NEWS | 6 ++
etc/PROBLEMS | 1 +
lib-src/Makefile.in | 6 +-
6 files changed, 175 insertions(+), 119 deletions(-)
diff --git a/INSTALL b/INSTALL
index 10b1756..a99f107 100644
--- a/INSTALL
+++ b/INSTALL
@@ -259,12 +259,23 @@ inconvenient for Emacs when running as daemon or running via a remote
ssh connection. In order to completely prevent the use of D-Bus, configure
Emacs with the options '--without-dbus --without-gconf --without-gsettings'.
+To read email via a network protocol like IMAP or POP, you can
+configure Emacs with the option '--with-mailutils', so that it always
+uses the GNU Mailutils 'movemail' program to retrieve mail. Otherwise
+the Emacs build procedure builds and installs an auxiliary 'movemail'
+program, a limited and insecure substitute that Emacs can use when
+Mailutils is not installed; when this happens, there are several
+configure options such as --without-pop that provide fine-grained
+control over Emacs 'movemail' construction.
+
The Emacs mail reader RMAIL is configured to be able to read mail from
a POP3 server by default. Versions of the POP protocol older than
-POP3 are not supported. For Kerberos-authenticated POP add
-'--with-kerberos', for Hesiod support add '--with-hesiod'. While POP3
-is always enabled, whether Emacs actually uses POP is controlled by
-individual users--see the Rmail chapter of the Emacs manual.
+POP3 are not supported. While POP3 support is typically enabled,
+whether Emacs actually uses POP3 is controlled by individual users;
+see the Rmail chapter of the Emacs manual. Unless you configure
+--with-mailutils, it is a good idea to configure --without-pop so that
+users are less likely to inadvertently read email via insecure
+channels.
For image support you may have to download, build, and install the
appropriate image support libraries for image types other than XBM and
@@ -538,7 +549,8 @@ information on this.
Emacs info files.
8) If your system uses lock files to interlock access to mailer inbox files,
-then you might need to make the movemail program setuid or setgid
+and if you did not configure --with-mailutils, then you might need to
+make the Emacs-specific 'movemail' program setuid or setgid in order
to enable it to write the lock files. We believe this is safe.
9) You are done! You can remove executables and object files from
diff --git a/configure.ac b/configure.ac
index 4d9ba96..47d0e5c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -240,6 +240,18 @@ AC_DEFUN
m4_bpatsubst([with_$1], [[^0-9a-z]], [_])=$with_features])dnl
])dnl
+# FIXME: The default options '--without-mailutils --with-pop' result
+# in a movemail implementation that supports only unencrypted POP3
+# connections. Encrypted connections should be the default.
+
+OPTION_DEFAULT_OFF([mailutils],
+ [rely on GNU Mailutils being installed; this makes the options
+ --without-pop through --with-mailhost irrelevant)])
+if test "$with_mailutils" = no; then
+ with_mailutils=
+fi
+AC_SUBST([with_mailutils])
+
OPTION_DEFAULT_ON([pop],[don't support POP mail retrieval with movemail])
if test "$with_pop" = yes; then
AC_DEFINE(MAIL_USE_POP)
@@ -3789,87 +3801,91 @@ AC_DEFUN
AC_SUBST(LIBXML2_LIBS)
AC_SUBST(LIBXML2_CFLAGS)
-# Check for mail-locking functions in a "mail" library. Probably this should
-# have the same check as for liblockfile below.
-AC_CHECK_LIB(mail, maillock, have_mail=yes, have_mail=no)
-if test $have_mail = yes; then
- LIBS_MAIL=-lmail
- AC_DEFINE(HAVE_LIBMAIL, 1, [Define to 1 if you have the 'mail' library (-lmail).])
-
- OLD_LIBS=$LIBS
- LIBS="$LIBS_MAIL $LIBS"
- AC_CHECK_FUNCS(touchlock)
- LIBS=$OLD_LIBS
-else
- LIBS_MAIL=
-fi
-dnl Debian, at least:
-AC_CHECK_LIB(lockfile, maillock, have_lockfile=yes, have_lockfile=no)
-if test $have_lockfile = yes; then
- LIBS_MAIL=-llockfile
- AC_DEFINE(HAVE_LIBLOCKFILE, 1, [Define to 1 if you have the 'lockfile' library (-llockfile).])
-else
-# If we have the shared liblockfile, assume we must use it for mail
-# locking (e.g. Debian). If we couldn't link against liblockfile
-# (no liblockfile.a installed), ensure that we don't need to.
- dnl This works for files generally, not just executables.
- dnl Should we look elsewhere for it? Maybe examine /etc/ld.so.conf?
- AC_CHECK_PROG(liblockfile, liblockfile.so, yes, no,
- /usr/lib:/lib:/usr/local/lib:$LD_LIBRARY_PATH)
- if test $ac_cv_prog_liblockfile = yes; then
- AC_MSG_ERROR([Shared liblockfile found but can't link against it.
+BLESSMAIL_TARGET=
+LIBS_MAIL=
+if test ! "$with_mailutils"; then
+ # Check for mail-locking functions in a "mail" library. Probably this should
+ # have the same check as for liblockfile below.
+ AC_CHECK_LIB([mail], [maillock], [have_mail=yes], [have_mail=no])
+ if test $have_mail = yes; then
+ LIBS_MAIL=-lmail
+ AC_DEFINE([HAVE_LIBMAIL], [1],
+ [Define to 1 if you have the 'mail' library (-lmail).])
+
+ OLD_LIBS=$LIBS
+ LIBS="$LIBS_MAIL $LIBS"
+ AC_CHECK_FUNCS([touchlock])
+ LIBS=$OLD_LIBS
+ fi
+ dnl Debian, at least:
+ AC_CHECK_LIB([lockfile], [maillock], [have_lockfile=yes], [have_lockfile=no])
+ if test $have_lockfile = yes; then
+ LIBS_MAIL=-llockfile
+ AC_DEFINE([HAVE_LIBLOCKFILE], [1],
+ [Define to 1 if you have the 'lockfile' library (-llockfile).])
+ else
+ # If we have the shared liblockfile, assume we must use it for mail
+ # locking (e.g. Debian). If we couldn't link against liblockfile
+ # (no liblockfile.a installed), ensure that we don't need to.
+ dnl This works for files generally, not just executables.
+ dnl Should we look elsewhere for it? Maybe examine /etc/ld.so.conf?
+ AC_CHECK_PROG([liblockfile], [liblockfile.so], [yes], [no],
+ [/usr/lib:/lib:/usr/local/lib:$LD_LIBRARY_PATH])
+ if test "$ac_cv_prog_liblockfile" = yes; then
+ AC_MSG_ERROR([Shared liblockfile found but can't link against it.
This probably means that movemail could lose mail.
There may be a 'development' package to install containing liblockfile.])
+ fi
fi
-fi
-AC_CHECK_HEADERS_ONCE(maillock.h)
-AC_SUBST(LIBS_MAIL)
+ AC_CHECK_HEADERS([maillock.h])
-## Define MAIL_USE_FLOCK (or LOCKF) if the mailer uses flock (or lockf) to
-## interlock access to the mail spool. The alternative is a lock file named
-## /usr/spool/mail/$USER.lock.
-mail_lock=no
-case "$opsys" in
- aix4-2) mail_lock="lockf" ;;
-
- gnu|freebsd|dragonfly|netbsd|openbsd|darwin) mail_lock="flock" ;;
-
- ## On GNU/Linux systems, both methods are used by various mail programs.
- ## I assume most people are using newer mailers that have heard of flock.
- ## Change this if you need to.
- ## Debian contains a patch which says: "On Debian/GNU/Linux systems,
- ## configure gets the right answers, and that means *NOT* using flock.
- ## Using flock is guaranteed to be the wrong thing. See Debian Policy
- ## for details." and then uses '#ifdef DEBIAN'. Unfortunately the
- ## Debian maintainer hasn't provided a clean fix for Emacs.
- ## movemail.c will use 'maillock' when MAILDIR, HAVE_LIBMAIL and
- ## HAVE_MAILLOCK_H are defined, so the following appears to be the
- ## correct logic. -- fx
- ## We must check for HAVE_LIBLOCKFILE too, as movemail does.
- ## liblockfile is a Free Software replacement for libmail, used on
- ## Debian systems and elsewhere. -rfr.
- gnu-*)
- mail_lock="flock"
- if test $have_mail = yes || test $have_lockfile = yes; then
- test $ac_cv_header_maillock_h = yes && mail_lock=no
- fi
- ;;
+ ## Define MAIL_USE_FLOCK (or LOCKF) if the mailer uses flock (or lockf) to
+ ## interlock access to the mail spool. The alternative is a lock file named
+ ## /usr/spool/mail/$USER.lock.
+ mail_lock=no
+ case $opsys in
+ aix4-2) mail_lock="lockf" ;;
+
+ gnu|freebsd|dragonfly|netbsd|openbsd|darwin) mail_lock="flock" ;;
+
+ ## On GNU/Linux systems, both methods are used by various mail programs.
+ ## I assume most people are using newer mailers that have heard of flock.
+ ## Change this if you need to.
+ ## Debian contains a patch which says: "On Debian/GNU/Linux systems,
+ ## configure gets the right answers, and that means *NOT* using flock.
+ ## Using flock is guaranteed to be the wrong thing. See Debian Policy
+ ## for details." and then uses '#ifdef DEBIAN'. Unfortunately the
+ ## Debian maintainer hasn't provided a clean fix for Emacs.
+ ## movemail.c will use 'maillock' when MAILDIR, HAVE_LIBMAIL and
+ ## HAVE_MAILLOCK_H are defined, so the following appears to be the
+ ## correct logic. -- fx
+ ## We must check for HAVE_LIBLOCKFILE too, as movemail does.
+ ## liblockfile is a Free Software replacement for libmail, used on
+ ## Debian systems and elsewhere. -rfr.
+ gnu-*)
+ mail_lock="flock"
+ if test $have_mail = yes || test $have_lockfile = yes; then
+ test $ac_cv_header_maillock_h = yes && mail_lock=no
+ fi ;;
- mingw32)
- mail_lock="none-needed" ;;
-esac
+ mingw32)
+ mail_lock="none-needed" ;;
+ esac
-BLESSMAIL_TARGET=
-case "$mail_lock" in
- flock) AC_DEFINE(MAIL_USE_FLOCK, 1, [Define if the mailer uses flock to interlock the mail spool.]) ;;
+ case $mail_lock in
+ flock) AC_DEFINE([MAIL_USE_FLOCK], [1],
+ [Define if the mailer uses flock to interlock the mail spool.]);;
- lockf) AC_DEFINE(MAIL_USE_LOCKF, 1, [Define if the mailer uses lockf to interlock the mail spool.]) ;;
+ lockf) AC_DEFINE([MAIL_USE_LOCKF], [1],
+ [Define if the mailer uses lockf to interlock the mail spool.]);;
- none-needed) ;;
+ none-needed) ;;
- *) BLESSMAIL_TARGET="need-blessmail" ;;
-esac
-AC_SUBST(BLESSMAIL_TARGET)
+ *) BLESSMAIL_TARGET="need-blessmail" ;;
+ esac
+fi
+AC_SUBST([BLESSMAIL_TARGET])
+AC_SUBST([LIBS_MAIL])
OLD_LIBS=$LIBS
LIBS="$LIB_PTHREAD $LIB_MATH $LIBS"
@@ -5469,4 +5485,21 @@ AC_DEFUN
AC_OUTPUT
+if test ! "$with_mailutils"; then
+ emacs_use_mailutils="use '$0 --with-mailutils'"
+ case `(movemail --version) 2>/dev/null` in
+ *Mailutils*) ;;
+ *) emacs_use_mailutils="install GNU Mailutils
+<http://mailutils.org> and $emacs_use_mailutils";;
+ esac
+ if test "$with_pop" = yes; then
+ AC_MSG_WARN([This configuration installs a 'movemail' program
+that retrieves POP3 email via only insecure channels.
+To fix this you can $emacs_use_mailutils.])
+ else
+ AC_MSG_NOTICE([This configuration installs a 'movemail' program that cannot
+retrieve POP3 email. You might want to $emacs_use_mailutils.])
+ fi
+fi
+
test "$MAKE" = make || AC_MSG_NOTICE([Now you can run '$MAKE'.])
diff --git a/doc/emacs/rmail.texi b/doc/emacs/rmail.texi
index d463982..b64ec22 100644
--- a/doc/emacs/rmail.texi
+++ b/doc/emacs/rmail.texi
@@ -1380,15 +1380,17 @@ Movemail
your Rmail file (@pxref{Rmail Inbox}). When loaded for the first time,
Rmail attempts to locate the @code{movemail} program and determine its
version. There are two versions of the @code{movemail} program: the
-native one, shipped with GNU Emacs (the Emacs version) and the one
-included in GNU mailutils (the mailutils version,
-@pxref{movemail,,,mailutils,GNU mailutils}). They support the same
+GNU Mailutils version (@pxref{movemail,,,mailutils,GNU mailutils}),
+and an Emacs-specific version that is built and installed unless Emacs
+was configured using the @option{--with-mailutils} option.
+The two @command{mailtool} versions support the same
command line syntax and the same basic subset of options. However, the
Mailutils version offers additional features.
- The Emacs version of @code{movemail} is able to retrieve mail from
-the usual Unix mailbox formats and from remote mailboxes using the
-POP3 protocol.
+ The Emacs version of @command{movemail} can retrieve mail from the
+usual Unix mailbox formats. Although it can also use the POP3
+protocol, this is not recommended because it does not support POP3 via
+encrypted TLS channels.
The Mailutils version is able to handle a wide set of mailbox
formats, such as plain Unix mailboxes, @code{maildir} and @code{MH}
@@ -1401,7 +1403,7 @@ Movemail
@acronym{URL} is:
@smallexample
-@var{proto}://[@var{user}[:@var{password}]@@]@var{host-or-file-name}
+@var{proto}://[@var{user}[:@var{password}]@@]@var{host-or-file-name}[:@var{port}]
@end smallexample
@noindent
@@ -1422,6 +1424,9 @@ Movemail
@item host-or-file-name
Hostname of the remote server for remote mailboxes or file name of a
local mailbox.
+
+@item port
+Optional port number, if not the default for that protocal.
@end table
@noindent
@@ -1429,19 +1434,20 @@ Movemail
@table @code
@item mbox
-Usual Unix mailbox format. In this case, neither @var{user} nor
-@var{pass} are used, and @var{host-or-file-name} denotes the file name
-of the mailbox file, e.g., @code{mbox://var/spool/mail/smith}.
+Usual Unix mailbox format. In this case, @var{user}, @var{pass} and
+@var{port} are not used, and @var{host-or-file-name} denotes the file
+name of the mailbox file, e.g., @code{mbox://var/spool/mail/smith}.
@item mh
-A local mailbox in the @acronym{MH} format. @var{user} and
-@var{pass} are not used. @var{host-or-file-name} denotes the name of
-@acronym{MH} folder, e.g., @code{mh://Mail/inbox}.
+A local mailbox in the @acronym{MH} format. @var{user}, @var{pass}
+and @var{port} are not used. @var{host-or-file-name} denotes the name
+of @acronym{MH} folder, e.g., @code{mh://Mail/inbox}.
@item maildir
-A local mailbox in the @acronym{maildir} format. @var{user} and
-@var{pass} are not used, and @var{host-or-file-name} denotes the name of
-@code{maildir} mailbox, e.g., @code{maildir://mail/inbox}.
+A local mailbox in the @acronym{maildir} format. @var{user},
+@var{pass} and @var{port} are not used, and @var{host-or-file-name}
+denotes the name of @code{maildir} mailbox, e.g.,
+@code{maildir://mail/inbox}.
@item file
Any local mailbox format. Its actual format is detected automatically
@@ -1451,15 +1457,15 @@ Movemail
A remote mailbox to be accessed via POP3 protocol. @var{user}
specifies the remote user name to use, @var{pass} may be used to
specify the user password, @var{host-or-file-name} is the name or IP
-address of the remote mail server to connect to; e.g.,
-@code{pop://smith:guessme@@remote.server.net}.
+address of the remote mail server to connect to, and @var{port} is the
+port number; e.g., @code{pop://smith:guessme@@remote.server.net:995}.
@item imap
A remote mailbox to be accessed via IMAP4 protocol. @var{user}
specifies the remote user name to use, @var{pass} may be used to
specify the user password, @var{host-or-file-name} is the name or IP
-address of the remote mail server to connect to;
-e.g., @code{imap://smith:guessme@@remote.server.net}.
+address of the remote mail server to connect to, and @var{port} is the
+port number; e.g., @code{imap://smith:guessme@@remote.server.net:993}.
@end table
Alternatively, you can specify the file name of the mailbox to use.
@@ -1483,44 +1489,40 @@ Remote Mailboxes
@pindex movemail
Some sites use a method called POP for accessing users' inbox data
-instead of storing the data in inbox files. By default, the @code{Emacs
-movemail} can work with POP (unless the Emacs @code{configure} script
-was run with the option @samp{--without-pop}).
-
-Similarly, the Mailutils @code{movemail} by default supports POP, unless
-it was configured with the @samp{--disable-pop} option.
-
-Both versions of @code{movemail} only work with POP3, not with older
-versions of POP.
+instead of storing the data in inbox files. The Mailutils
+@command{movemail} by default supports POP with TLS encryption.
+Although the @command{Emacs movemail} supports unencrypted POP, this
+is not recommended due to the lack of encryption. Both versions of
+@command{movemail} work only with POP3, not with older versions of
+POP.
@cindex @env{MAILHOST} environment variable
@cindex POP mailboxes
- No matter which flavor of @code{movemail} you use, you can specify
+ You can specify
a POP inbox by using a POP @dfn{URL} (@pxref{Movemail}). A POP
@acronym{URL} is of the form
-@samp{pop://@var{username}@@@var{hostname}}, where
-@var{hostname} is the host name or IP address of the remote mail
+@samp{pop://@var{username}@@@var{hostname}:@var{port}}, where
+@var{hostname} and @var{port} are the host name (or IP address)
+and port number of the remote mail
server and @var{username} is the user name on that server.
Additionally, you may specify the password in the mailbox @acronym{URL}:
-@samp{pop://@var{username}:@var{password}@@@var{hostname}}. In this
+@samp{pop://@var{username}:@var{password}@@@var{hostname}:@var{port}}. In this
case, @var{password} takes preference over the one set by
@code{rmail-remote-password} (see below). This is especially useful
if you have several remote mailboxes with different passwords.
For backward compatibility, Rmail also supports an alternative way of
specifying remote POP mailboxes. Specifying an inbox name in the form
-@samp{po:@var{username}:@var{hostname}} is equivalent to
-@samp{pop://@var{username}@@@var{hostname}}. If you omit the
+@samp{po:@var{username}:@var{hostname}:@var{port}} is equivalent to
+@samp{pop://@var{username}@@@var{hostname}:@var{port}}. If you omit the
@var{:hostname} part, the @env{MAILHOST} environment variable specifies
the machine on which to look for the POP server.
-@c FIXME mention --with-hesiod "support Hesiod to get the POP server host"?
-
@cindex IMAP mailboxes
Another method for accessing remote mailboxes is IMAP@. This method is
supported only by the Mailutils @code{movemail}. To specify an IMAP
mailbox in the inbox list, use the following mailbox @acronym{URL}:
-@samp{imap://@var{username}[:@var{password}]@@@var{hostname}}. The
+@samp{imap://@var{username}[:@var{password}]@@@var{hostname}:@var{port}}. The
@var{password} part is optional, as described above.
@vindex rmail-remote-password
@@ -1550,9 +1552,7 @@ Remote Mailboxes
@cindex Kerberos POP authentication
The @code{movemail} program installed at your site may support
-Kerberos authentication (the Emacs @code{movemail} does so if Emacs was
-configured with the option @code{--with-kerberos} or
-@code{--with-kerberos5}). If it is supported, it is used by default
+Kerberos authentication. If it is supported, it is used by default
whenever you attempt to retrieve POP mail when
@code{rmail-remote-password} and @code{rmail-remote-password-required}
are unset.
diff --git a/etc/NEWS b/etc/NEWS
index 88ae7cf..f047aa8 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -37,6 +37,12 @@ Use 'configure --with-gnutls=no' to build even when GnuTLS is missing.
** GnuTLS version 2.12.2 or later is now required, instead of merely
version 2.6.6 or later.
+** The new option 'configure --with-mailutils' causes Emacs to rely on
+GNU Mailutils 'movemail' to retrieve email. By default, the Emacs
+build procedure continues to build and install a limited and insecure
+'movemail' substitute. Although --with-mailutils is recommended, it
+is not yet the default due to backward-compatibility concerns.
+
** The new option 'configure --enable-gcc-warnings=warn-only' causes
GCC to issue warnings without stopping the build. This behavior is
now the default in developer builds. As before, use
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index b892320..eddae12 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -323,6 +323,7 @@ or set the variable 'cannot-suspend' to a non-nil value.
*** movemail compiled with POP support can't connect to the POP server.
+This problem can occur if you do not configure --with-mailutils.
Make sure that the 'pop' entry in /etc/services, or in the services
NIS map if your machine uses NIS, has the same port number as the
entry on the POP server. A common error is for the POP server to be
diff --git a/lib-src/Makefile.in b/lib-src/Makefile.in
index d0aa9cc..b2cd66c 100644
--- a/lib-src/Makefile.in
+++ b/lib-src/Makefile.in
@@ -100,6 +100,9 @@ bindir=
# --libexecdir option to '../configure'.
libexecdir=@libexecdir@
+# Nonempty if Emacs can assume Mailutils is installed.
+with_mailutils=@with_mailutils@
+
# Directory for local state files for all programs.
localstatedir=@localstatedir@
@@ -160,7 +163,8 @@ INSTALLABLES =
# Things that Emacs runs internally, or during the build process,
# which should not be installed in bindir.
-UTILITIES = profile${EXEEXT} movemail${EXEEXT} hexl${EXEEXT} \
+UTILITIES = profile${EXEEXT} hexl${EXEEXT} \
+ $(if $(with_mailutils), , movemail${EXEEXT}) \
$(and $(use_gamedir), update-game-score${EXEEXT})
DONT_INSTALL= make-docfile${EXEEXT}
--
2.9.3
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-17 7:23 ` Paul Eggert
@ 2017-03-17 8:58 ` Eli Zaretskii
2017-03-17 10:49 ` Lars Ingebrigtsen
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-17 8:58 UTC (permalink / raw)
To: Paul Eggert; +Cc: hengaini2055, 26102-done
> Cc: rgm@gnu.org, hengaini2055@qq.com, 26102-done@debbugs.gnu.org
> From: Paul Eggert <eggert@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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-17 7:23 ` Paul Eggert
2017-03-17 8:58 ` Eli Zaretskii
@ 2017-03-17 10:49 ` Lars Ingebrigtsen
2017-03-17 10:56 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2017-03-17 10:49 UTC (permalink / raw)
To: 26102; +Cc: eggert, hengaini2055
Paul Eggert <eggert@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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#26102: movemail can't connect mail server
2017-03-17 10:49 ` Lars Ingebrigtsen
@ 2017-03-17 10:56 ` Eli Zaretskii
0 siblings, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2017-03-17 10:56 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: eggert, 26102, hengaini2055
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 17 Mar 2017 11:49:13 +0100
> Cc: eggert@cs.ucla.edu, hengaini2055@qq.com
>
> Paul Eggert <eggert@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.)
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-03-17 10:56 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-15 1:14 bug#26102: movemail can't connect mail server �ž��
2017-03-15 15:49 ` Eli Zaretskii
2017-03-15 17:30 ` Paul Eggert
2017-03-15 17:48 ` Eli Zaretskii
2017-03-15 18:15 ` Glenn Morris
2017-03-15 18:20 ` Eli Zaretskii
2017-03-15 20:03 ` Noam Postavsky
2017-03-16 3:31 ` Eli Zaretskii
2017-03-15 22:48 ` Paul Eggert
2017-03-16 15:31 ` Eli Zaretskii
2017-03-17 7:23 ` Paul Eggert
2017-03-17 8:58 ` Eli Zaretskii
2017-03-17 10:49 ` Lars Ingebrigtsen
2017-03-17 10:56 ` Eli Zaretskii
2017-03-16 0:15 ` Glenn Morris
2017-03-16 15:33 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).