GNU bug report logs - #38066
26.1; X-Message-SMTP-Method header does not affect smtpmail-stream-type

Previous Next

Package: emacs;

Reported by: Ryan Tate <ryantate <at> ryantate.com>

Date: Tue, 5 Nov 2019 04:49:02 UTC

Severity: normal

Tags: fixed

Found in version 26.1

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 04:49:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ryan Tate <ryantate <at> ryantate.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 05 Nov 2019 04:49:02 GMT) Full text and rfc822 format available.

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

From: Ryan Tate <ryantate <at> ryantate.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1;
 X-Message-SMTP-Method header does not affect smtpmail-stream-type
Date: Mon, 04 Nov 2019 23:45:52 -0500
The internal emacs mail header X-Message-SMTP-Method is described in
section 3.3 of the manual as a way to get "some messages to go via one
mail server, and other messages to go through another." Both examples
given show that this header can be used to communicate a method, server
name, and port.
https://www.gnu.org/software/emacs/manual/html_node/message/Mail-Variables.html

However, emacs, in particular gnus/message.el when sending through
smtpmail.el, fails to adjust the variable smtpmail-smtp-stream type to
match the port. So, for example, if a user selects port 465, the
connection will fail as this is the port for SMTP connections with
TLS.

Port 587 will happen to work as this is the port for SMTP with STARTTLS,
and STARTTLS upgrades can happen in a plain stream type (the smtpmail
default). But emacs will not (and does not provide an option to) force
STARTTLS when port 587 is specified as would occur if 'ssl were supplied
as the value for smtpmail-stream-type. This provides an avenue under
which encryption may be silently dropped. 

There is no warning in the manual that port 465 will not function as
expected using the X-Message-SMTP-Method header.

There is also no mechanism through which a stream may be user specified
via the X-Message-SMTP-Method header.

I believe the ideal solution here is for emacs to either auto-associate
ports with their usual stream types (465->'ssl, 587->'starttls, 25->nil)
or provide a mechanism for stream type to be specified in the header as
the fifth value (after method, machine, port, alt username). Or
auto-associate by default and provide a config variable through which to
override stream type by machine and port.

Personally I am working around this with the following hook. (Due to
changes to emacs in subsequent versions, it needs to work with both
strings and numbers as the port):

(defun set-smtpmail-stream-type-from-port ()
  (when (or (equal smtpmail-smtp-service "465")
	    (equal smtpmail-smtp-service 465))
    (setq smtpmail-stream-type 'ssl))
  (when (or (equal smtpmail-smtp-service "587")
	    (equal smtpmail-smtp-service 587))
    (setq smtpmail-stream-type 'starttls))
  (when (or (equal smtpmail-smtp-service "25")
	    (equal smtpmail-smtp-service 25))
    (setq smtpmail-stream-type nil))
  )

(add-hook 'message-send-mail-hook #'set-smtpmail-stream-type-from-port)



In GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.4)
 of 2019-02-03, modified by Debian built on zam904
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description:	Debian GNU/Linux 10 (buster)

Recent messages:
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set [4 times]
Auto-saving...done

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-26.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Message[Notmuch]

Minor modes in effect:
  diff-auto-refine-mode: t
  mml-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-show hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-show
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-jump hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-jump
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-crypto hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-crypto
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/coolj hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/coolj
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-draft hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-draft
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-compat hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-compat
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-autoloads hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-autoloads
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-company hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-company
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-query hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-query
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-hello hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-hello
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-message hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-message
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/make-deps hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/make-deps
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-address hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-address
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-parser hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-parser
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-print hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-print
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-tag hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-tag
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-lib hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-lib
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-wash hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-wash
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-maildir-fcc hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-maildir-fcc
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-pkg hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-pkg
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-tree hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-tree
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-version hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-version
/usr/share/emacs/site-lisp/elpa/notmuch-0.28.4/notmuch-mua hides /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28.4/notmuch-mua

Features:
(shadow emacsbug sendmail sort gnus-alias mail-extr notmuch hl-line
notmuch-message notmuch-hello wid-edit notmuch-tree notmuch-show
notmuch-print notmuch-crypto notmuch-mua notmuch-draft
notmuch-maildir-fcc notmuch-address notmuch-company notmuch-parser
notmuch-wash diff-mode easy-mmode coolj notmuch-query goto-addr
thingatpt icalendar diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs notmuch-tag edmacro kmacro crm notmuch-lib advice
notmuch-version notmuch-compat cl message rmc puny dired dired-loaddefs
format-spec rfc822 mml mailabbrev gmm-utils mailheader mm-view mml-smime
mml-sec epa derived epg gnus-util rmail rmail-loaddefs mail-utils smime
dig mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047
rfc2045 mm-util ietf-drums mail-prsvr elec-pair finder-inf info package
easymenu epg-config url-handlers url-parse auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache url-vars seq byte-opt
gv bytecomp byte-compile cconv cl-loaddefs cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 260049 19820)
 (symbols 48 29943 6)
 (miscs 40 184 580)
 (strings 32 83885 3752)
 (string-bytes 1 2093686)
 (vectors 16 25869)
 (vector-slots 8 656309 21192)
 (floats 8 58 202)
 (intervals 56 493 19)
 (buffers 992 14))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 10:19:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Ryan Tate <ryantate <at> ryantate.com>
Cc: 38066 <at> debbugs.gnu.org
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Tue, 05 Nov 2019 11:18:21 +0100
>>>>> On Mon, 04 Nov 2019 23:45:52 -0500, Ryan Tate said:

    Ryan> I believe the ideal solution here is for emacs to either auto-associate
    Ryan> ports with their usual stream types (465->'ssl, 587->'starttls, 25->nil)
    Ryan> or provide a mechanism for stream type to be specified in the header as
    Ryan> the fifth value (after method, machine, port, alt username). Or
    Ryan> auto-associate by default and provide a config variable through which to
    Ryan> override stream type by machine and port.

Iʼm not so sure about the auto association. How about we allow people
to ask for auto-detection? Something like the following (and then we
can discuss whether to turn it on by default, and I can argue that
STARTTLS is evil and we should force everyone to use 465 :-) )

Alternatively we could put this kind of code in open-network-stream,
to allow other protocols to benefit from the same kind of detection.

diff --git a/lisp/mail/smtpmail.el b/lisp/mail/smtpmail.el
index 9cf28fbe8a..75b15a99aa 100644
--- a/lisp/mail/smtpmail.el
+++ b/lisp/mail/smtpmail.el
@@ -98,11 +98,13 @@ smtpmail-stream-type
   "Type of SMTP connections to use.
 This may be either nil (upgrade with STARTTLS if possible),
 `starttls' (refuse to send if STARTTLS isn't available),
-`plain' (never use STARTTLS), or `ssl' (to use TLS/SSL)."
-  :version "24.1"
+`plain' (never use STARTTLS), or `ssl' (to use TLS/SSL), or
+`auto' to derive the stream-type from the port number."
+  :version "27.1"
   :type '(choice (const :tag "Possibly upgrade to STARTTLS" nil)
 		 (const :tag "Always use STARTTLS" starttls)
 		 (const :tag "Never use STARTTLS" plain)
+                 (const :tag "Derive from port number" auto)
 		 (const :tag "Use TLS/SSL" ssl)))
 
 (defcustom smtpmail-sendto-domain nil
@@ -666,6 +668,16 @@ smtpmail-user-mail-address
 	      (string-match "\\." (cadr parts))
 	      user-mail-address))))
 
+(defun smtpmail-derive-stream-type (stream-type port)
+  (if (equal stream-type 'auto)
+      (cdr (assoc port '((465 . ssl)
+                         ("465" . ssl)
+                         (587 . starttls)
+                         ("587" . starttls)
+                         (25 . nil)
+                         ("25" . nil))))
+    stream-type))
+
 (defun smtpmail-via-smtp (recipient smtpmail-text-buffer
 				    &optional ask-for-password
                                     send-attempts)
@@ -712,7 +724,9 @@ smtpmail-via-smtp
           ;; FIXME: Should we use raw-text-dos coding system to handle the r\n
           ;; for us?
 	  (let ((coding-system-for-read 'binary)
-		(coding-system-for-write 'binary))
+                (coding-system-for-write 'binary)
+                (smtpmail-stream-type
+                 (smtpmail-derive-stream-type smtpmail-stream-type port)))
 	    (setq result
 		  (open-network-stream
 		   "smtpmail" process-buffer host port




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 17:25:02 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Ryan Tate <ryantate <at> ryantate.com>
Cc: 38066 <at> debbugs.gnu.org
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Tue, 05 Nov 2019 18:24:16 +0100
(please keep 38066 <at> debbugs.gnu.org in the CC)

>>>>> On Tue, 05 Nov 2019 11:16:16 -0500, Ryan Tate <ryantate <at> ryantate.com> said:

    >> Alternatively we could put this kind of code in open-network-stream,
    >> to allow other protocols to benefit from the same kind of detection.

    Ryan> I don't know enough about the open-network-stream corner of emacs so won't argue either
    Ryan> way. At the very least, I think it certainly makes sense with regard to the X-Message-SMTP-Method
    Ryan> header because this is a convenience feature (so some small amount "magic"
    Ryan> seems permissable) and there is no existing way to set the stream type
    Ryan> here. I imagine it could be useful elsewhere in emacs though.

If we do it in the lower layers, then everyone gets to use it, not
just people using X-Message-SMTP-Method or smtpmail-stream-type.

    Ryan> Your patches look good, thank you for writing them! (Do I need to submit
    Ryan> them formally as a patch on this list?)

No, if they gain traction I can commit them. I took a look at
open-network-stream, and itʼs not too hard to do the equivalent there,
although it probably needs to be conditioned on the specified :type
being nil rather than unconditionally overriding it.

diff --git i/lisp/net/gnutls.el w/lisp/net/gnutls.el
index 9b13adaefe..a083e9df6c 100644
--- i/lisp/net/gnutls.el
+++ w/lisp/net/gnutls.el
@@ -202,6 +202,7 @@ open-gnutls-stream
          (process (open-network-stream
                    name buffer host service
                    :nowait nowait
+                   :auto-tls (plist-get parameters :auto-tls)
                    :tls-parameters
                    (and nowait
                         (cons 'gnutls-x509pki
diff --git i/lisp/net/network-stream.el w/lisp/net/network-stream.el
index 4050c83eb0..8b4bd66ef4 100644
--- i/lisp/net/network-stream.el
+++ w/lisp/net/network-stream.el
@@ -73,6 +73,35 @@ network-stream-use-client-certificates
   :type 'boolean
   :version "27.1")
 
+(defcustom network-stream-auto-tls nil
+  "Whether to automatically try with TLS for certain port
+numbers.  See `network-stream-auto-tls-alist' for the default
+settings."
+  :group 'network
+  :type 'boolean
+  :version "27.1")
+
+(defcustom network-stream-auto-tls-alist
+  '((465 . tls)
+    (587 . starttls)
+    (993 . tls))
+  "Alist used for mapping ports to TLS usage.
+Specifies which port number to map to which TLS behaviour.  See
+`open-network-stream' for a full explanation of the possible
+behaviours."
+  :group 'network
+  :type '(alist :key-type integer
+                :value-type (choice
+                             (const :tag "Possibly upgrade to STARTTLS" nil)
+                             (const :tag "Always use STARTTLS" starttls)
+                             (const :tag "Never use STARTTLS" plain)
+                             (const :tag "Use TLS/SSL" tls)))
+  :version "27.1")
+
 ;;;###autoload
 (defun open-network-stream (name buffer host service &rest parameters)
   "Open a TCP connection to HOST, optionally with encryption.
@@ -175,7 +204,19 @@ open-network-stream
   (unless (featurep 'make-network-process)
     (error "Emacs was compiled without networking support"))
   (let ((type (plist-get parameters :type))
-	(return-list (plist-get parameters :return-list)))
+	(return-list (plist-get parameters :return-list))
+        mapped-type)
+    (when (and network-stream-auto-tls (not (plist-get parameters :auto-tls)))
+      (setq mapped-type (assoc (if (integerp service)
+                                   service
+                                 (string-to-number service))
+                               network-stream-auto-tls-alist))
+      (when mapped-type
+        (setq type (cdr mapped-type)
+              parameters (plist-put
+                          (plist-put parameters :auto-tls t)
+                          :type (cdr mapped-type)))))
+    (message "Auto-TLS %s %s" type mapped-type)
     (if (and (not return-list)
 	     (or (eq type 'plain)
 		 (and (memq type '(nil network))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 17:43:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 38066 <at> debbugs.gnu.org, Ryan Tate <ryantate <at> ryantate.com>
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Tue, 05 Nov 2019 18:42:39 +0100
Robert Pluim <rpluim <at> gmail.com> writes:

> +(defcustom network-stream-auto-tls-alist
> +  '((465 . tls)
> +    (587 . starttls)
> +    (993 . tls))

I'm not sure I understand the rationale hre.  465 is defined as a TLS
port, so that's what Emacs should talk on that port.  It's like port
443 -- it's also TLS.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 17:54:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38066 <at> debbugs.gnu.org, Ryan Tate <ryantate <at> ryantate.com>
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Tue, 05 Nov 2019 18:53:33 +0100
>>>>> On Tue, 05 Nov 2019 18:42:39 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> Robert Pluim <rpluim <at> gmail.com> writes:
    >> +(defcustom network-stream-auto-tls-alist
    >> +  '((465 . tls)
    >> +    (587 . starttls)
    >> +    (993 . tls))

    Lars> I'm not sure I understand the rationale hre.  465 is defined as a TLS
    Lars> port, so that's what Emacs should talk on that port.  It's like port
    Lars> 443 -- it's also TLS.

465 is just a port. And eg

(open-network-stream "google" nil "mail.google.com" 465)

will attempt a STARTTLS connection (and incidentally hang my emacs
:-)). You can override that by passing in :type tls, but in some
situations you canʼt do that, hence the proposed patch.

Unless youʼre suggesting that we unconditionally use tls for 465/443?
Thatʼs another option, but itʼs sure to break someone's setup.

Robert




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 17:58:02 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 38066 <at> debbugs.gnu.org, Ryan Tate <ryantate <at> ryantate.com>
Subject: Re: bug#38066: 26.1;
 X-Message-SMTP-Method header does not affect smtpmail-stream-type
Date: Tue, 05 Nov 2019 18:57:17 +0100
On Nov 05 2019, Robert Pluim wrote:

> +(defcustom network-stream-auto-tls nil
> +  "Whether to automatically try with TLS for certain port

The first line should be a complete sentence.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 18:25:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ryan Tate <ryantate <at> ryantate.com>
Cc: 38066 <at> debbugs.gnu.org
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Tue, 05 Nov 2019 19:23:58 +0100
Robert Pluim <rpluim <at> gmail.com> writes:

>     Lars> I'm not sure I understand the rationale hre.  465 is defined as a TLS
>     Lars> port, so that's what Emacs should talk on that port.  It's like port
>     Lars> 443 -- it's also TLS.
>
> 465 is just a port. And eg
>
> (open-network-stream "google" nil "mail.google.com" 465)
>
> will attempt a STARTTLS connection (and incidentally hang my emacs
> :-)). You can override that by passing in :type tls, but in some
> situations you canʼt do that, hence the proposed patch.
>
> Unless youʼre suggesting that we unconditionally use tls for 465/443?
> Thatʼs another option, but itʼs sure to break someone's setup.

465 is a TLS port in an SMTP context, and 443 is a TLS port in an HTTP
context.  Outside those contexts, they're not anything in particular, of
course.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Tue, 05 Nov 2019 20:11:02 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38066 <at> debbugs.gnu.org, Ryan Tate <ryantate <at> ryantate.com>
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Tue, 05 Nov 2019 21:09:59 +0100
>>>>> On Tue, 05 Nov 2019 19:23:58 +0100, Lars Ingebrigtsen <larsi <at> gnus.org> said:

    Lars> Robert Pluim <rpluim <at> gmail.com> writes:
    Lars> I'm not sure I understand the rationale hre.  465 is defined as a TLS
    Lars> port, so that's what Emacs should talk on that port.  It's like port
    Lars> 443 -- it's also TLS.
    >> 
    >> 465 is just a port. And eg
    >> 
    >> (open-network-stream "google" nil "mail.google.com" 465)
    >> 
    >> will attempt a STARTTLS connection (and incidentally hang my emacs
    >> :-)). You can override that by passing in :type tls, but in some
    >> situations you canʼt do that, hence the proposed patch.
    >> 
    >> Unless youʼre suggesting that we unconditionally use tls for 465/443?
    >> Thatʼs another option, but itʼs sure to break someone's setup.

    Lars> 465 is a TLS port in an SMTP context, and 443 is a TLS port in an HTTP
    Lars> context.  Outside those contexts, they're not anything in particular, of
    Lars> course.

So youʼre suggesting we do autodetection in smtpmail and nnimap only
(and probably a few more besides)?

Robert




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Fri, 08 Nov 2019 20:57:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ryan Tate <ryantate <at> ryantate.com>
Cc: 38066 <at> debbugs.gnu.org
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Fri, 08 Nov 2019 21:56:37 +0100
Robert Pluim <rpluim <at> gmail.com> writes:

>     Lars> 465 is a TLS port in an SMTP context, and 443 is a TLS port
>     Lars> in an HTTP context.  Outside those contexts, they're not
>     Lars> anything in particular, of course.
>
> So youʼre suggesting we do autodetection in smtpmail and nnimap only
> (and probably a few more besides)?

When smtpmail contacts port 465, it should set the type to 'ssl, yes.
(And the same for nnimap and 993.)

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#38066; Package emacs. (Thu, 20 Aug 2020 15:06:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ryan Tate <ryantate <at> ryantate.com>
Cc: 38066 <at> debbugs.gnu.org
Subject: Re: bug#38066: 26.1; X-Message-SMTP-Method header does not affect
 smtpmail-stream-type
Date: Thu, 20 Aug 2020 17:05:22 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Robert Pluim <rpluim <at> gmail.com> writes:
>
>>     Lars> 465 is a TLS port in an SMTP context, and 443 is a TLS port
>>     Lars> in an HTTP context.  Outside those contexts, they're not
>>     Lars> anything in particular, of course.
>>
>> So youʼre suggesting we do autodetection in smtpmail and nnimap only
>> (and probably a few more besides)?
>
> When smtpmail contacts port 465, it should set the type to 'ssl, yes.
> (And the same for nnimap and 993.)

I've now done this on the trunk.

I think Robert's suggestion to add more DWIM logic at a lower level is
interesting, but I think it makes sense to handle this at a higher
(protocol) level -- and I think the Message level is the most flexible.

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




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 20 Aug 2020 15:06:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 38066 <at> debbugs.gnu.org and Ryan Tate <ryantate <at> ryantate.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 20 Aug 2020 15:06:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 18 Sep 2020 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 214 days ago.

Previous Next


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