bug#31990: 26.1; Stuck in loop trying to send bug report

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

--text follows this line--: --text follows this line--

Hi,

        While trying to send a bug report with long lines I
        got stuck in a loop.

        Here's what the *Messages* contained:

Sending...
Mark set
Fix continuation lines? (y or n) n
Send anyway? (y or n) y
Fix continuation lines? (y or n) n
Send anyway? (y or n) y
Fix continuation lines? (y or n) n
Send anyway? (y or n) y
Fix continuation lines? (y or n) n
Send anyway? (y or n) y
Fix continuation lines? (y or n) n
Send anyway? (y or n) y
Quit


        The SMTP trace log contained:

220 smtp.mail.yahoo.com ESMTP ready
250-smtp422.mail.bf1.yahoo.com Hello localhost.localdomain [73.16.70.190])
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE 41697280
250 STARTTLS
220 2.0.0 Ready to start TLS
250-smtp422.mail.bf1.yahoo.com Hello localhost.localdomain [73.16.70.190])
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE 41697280
250 AUTH PLAIN LOGIN XOAUTH2 OAUTHBEARER XYMCOOKIE
MAIL FROM:<nyc4bos@aol.com> SIZE=5830
450 Requested mail action not taken: mailbox unavailable
QUIT
221 Service Closing transmission


    As you can see, the STARTTLS capability is available
    (resultant code "250 STARTTLS") but a STARTTLS command was
    NOT subsequently issued (oppurtunistically).

    Not sure whether or not this was related to the loop responding
    to sending a bug report with long lines and selecting "n" to
    NOT fix up and "y" to send anyway.

    Thanks.
 

In GNU Emacs 26.1 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.20.6)
 of 2018-06-26 built on localhost.localdomain
Windowing system distributor 'Fedora Project', version 11.0.11803000
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure 'CFLAGS=-DMAIL_USE_LOCKF -O0 -ggdb3 -pipe -Wall
 -Werror=format-security -fexceptions -fstack-protector-strong
 --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
 LDFLAGS=-Wl,-z,relro --disable-dependency-tracking
 --prefix=/tmp/nff/de2/fedora-emacs-src/emacs-26.1 --with-dbus
 --with-gif --with-jpeg --with-png --with-rsvg --with-lcms2 --with-tiff
 --with-xft --with-xpm --with-x-toolkit=gtk3 --with-gpm=yes
 --with-xwidgets --with-modules'

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 MODULES THREADS XWIDGETS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair 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 xwidget-internal
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 95555 7613)
 (symbols 48 20390 1)
 (miscs 40 39 119)
 (strings 32 28362 1522)
 (string-bytes 1 748849)
 (vectors 16 14653)
 (vector-slots 8 497388 7244)
 (floats 8 49 211)
 (intervals 56 248 0)
 (buffers 992 12)
 (heap 1024 34948 1057))

bug#31990: 26.1; Stuck in loop trying to send bug report

[Eli Zaretskii]

> From: Live System User <nyc4bos@aol.com>
> Date: Wed, 27 Jun 2018 18:41:13 -0400
> Cc: nyc4bos@aol.com
> 
>         While trying to send a bug report with long lines I
>         got stuck in a loop.
> 
>         Here's what the *Messages* contained:
> 
> Sending...
> Mark set
> Fix continuation lines? (y or n) n
> Send anyway? (y or n) y
> Fix continuation lines? (y or n) n
> Send anyway? (y or n) y
> Fix continuation lines? (y or n) n
> Send anyway? (y or n) y
> Fix continuation lines? (y or n) n
> Send anyway? (y or n) y
> Fix continuation lines? (y or n) n
> Send anyway? (y or n) y
> Quit

Were you really stuck or just impatient?  message.el asks these
questions for every single line that it wants to fix.  Each time you
answer, it should move to the next line before it asks the same
question.  Are you saying it didn't move in your case?

If it did move, then I think this is working as designed, and if you'd
continued to answer the questions, you'd eventually get to sending the
message.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

--text follows this line--: --text follows this line--
Eli Zaretskii <eliz@gnu.org> writes: 

>> From: Live System User <nyc4bos@aol.com>
>> Date: Wed, 27 Jun 2018 18:41:13 -0400
>> Cc: nyc4bos@aol.com
>> 
>>         While trying to send a bug report with long lines I
>>         got stuck in a loop.
>> 
>>         Here's what the *Messages* contained:
>> 
>> Sending...
>> Mark set
>> Fix continuation lines? (y or n) n
>> Send anyway? (y or n) y
>> Fix continuation lines? (y or n) n
>> Send anyway? (y or n) y
>> Fix continuation lines? (y or n) n
>> Send anyway? (y or n) y
>> Fix continuation lines? (y or n) n
>> Send anyway? (y or n) y
>> Fix continuation lines? (y or n) n
>> Send anyway? (y or n) y
>> Quit
>
> Were you really stuck or just impatient?  message.el asks these
> Were you really stuck or just impatient?  message.el asks these
> questions for every single line that it wants to fix.  Each time you
> answer, it should move to the next line before it asks the same
> question.  Are you saying it didn't move in your case?

  I don't remember whether or not I moved to the next line as I was
  having various problems sending email.

  I originally tried to send an email with a new version of Emacs 26.1.
  When that failed due to Emacs not issuing a STARTTLS command, I
  decided to create a "report-emacs-bug" about it.  That would
  probably also fail for the same reason but at least I would have
  a bug report message in the format of "report-emacs-bug" in a
  buffer that I could cut&paste and thus send outside of Emacs.

  Since I had the "report-emacs-bug" message, I might as well attempt
  to send it within Emacs -- the worse that could happen is tbat
  semding mail would fail again.

  This time I got the 'Fix continuation lines?'' query, to which I
  kept answering "n".

  You'll notice that it says "...lines".  That's plural, i.e. more
  than one.  To me, that meant that ALL lines would be fixed up.

  I had no idea that "lines" really meant "line and that I would
  have to answer each one indvidually.

  If there were visual clues, i.e. movement, I must have misse it.
  Perhaps that query could be augment with the words "..this line"?

  Additionally, perhap a way to specify ALL remaining occurences,
  similar to the way "query-replace" works?
  
> If it did move, then I think this is working as designed, and if you'd
> continued to answer the questions, you'd eventually get to sending the
> message.

`Unfortunally not because of Emacs not issuing a STARTTLS  command...

 Thanks
 

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

>
> `Unfortunally not because of Emacs not issuing a STARTTLS  command...

Could you show us your emacs mail configuration? Gnus normally does
opportunistic TLS upgrade, and I thought that was the default for
open-network-stream as well. [1]

Regards

Robert

Footnotes:
[1]  Iʼm not a big fan of STARTTLS, as itʼs vulnerable to
     man-in-the-middle capability stripping. I use direct TLS
     connections to port 465 instead.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>>
>> `Unfortunally not because of Emacs not issuing a STARTTLS  command...
>
> Could you show us your emacs mail configuration? Gnus normally does
> opportunistic TLS upgrade, and I thought that was the default for
> open-network-stream as well. [1]
>
> Regards
>
> Robert
>
> Footnotes:
> [1]  Iʼm not a big fan of STARTTLS, as itʼs vulnerable to
>      man-in-the-middle capability stripping. I use direct TLS
>      connections to port 465 instead.

       Thanks for this footnote.  I used it to rule out whether
       or not STARTTLS was rhe (main) problem,

       Turns out it wasn't: a direct TLS connrction yielded the
       same unsuccessful results.  This caused me to look more
       closely at the first SMTP transaction log whicn should
       have issued a STARTTLS command.

       Unfortunately, Emacs only records in its
       *trace of SMTP sesssion to...* buffer the responses from
       the SMTP server and mot also what commands are sent to it.
       So while I presumed that a STARTTLS command wasn't being
       issued because it failed and I wasn't being asked to
       provide a password, a now closer look reveals that it
       apparently was sent.

       So it's failing for another reason which a direct TLS
       connection helps to confirm.

       It appears I have a similar problem as Ulrich Mueller
       which he reported back April of last year in bug#26359;

           https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26359

      His workaround. a `defadvice` also works for me.

      Hopefully. a fix will solve these issues and allow one to
      designatre for a partiular network connection that a
      password is required (supplied or prompted for) upon an
      initial connection and not just only after an initial
      unauthenticated connetion failure;

      Not sure if this bug report should be merged with bug#26359
      as I have more than just one issue or should I open up  new
      bug report for those?
      
      Thanks.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

>        Unfortunately, Emacs only records in its
>        *trace of SMTP sesssion to...* buffer the responses from
>        the SMTP server and mot also what commands are sent to it.
>        So while I presumed that a STARTTLS command wasn't being
>        issued because it failed and I wasn't being asked to
>        provide a password, a now closer look reveals that it
>        apparently was sent.
>
>        So it's failing for another reason which a direct TLS
>        connection helps to confirm.
>
>        It appears I have a similar problem as Ulrich Mueller
>        which he reported back April of last year in bug#26359;
>
>            https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26359
>
>       His workaround. a `defadvice` also works for me.
>
>       Hopefully. a fix will solve these issues and allow one to
>       designatre for a partiular network connection that a
>       password is required (supplied or prompted for) upon an
>       initial connection and not just only after an initial
>       unauthenticated connetion failure;
>

This is already in place, and it works for me, but itʼs not working
correctly for you. Could you provide more details on how youʼre
specifying your username/password? Based on looking at the code, this
situation could arise if you only set smtpmail-smtp-user without
having an entry in .authinfo.

Thanks

Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>>        Unfortunately, Emacs only records in its
>>        *trace of SMTP sesssion to...* buffer the responses from
>>        the SMTP server and mot also what commands are sent to it.
>>        So while I presumed that a STARTTLS command wasn't being
>>        issued because it failed and I wasn't being asked to
>>        provide a password, a now closer look reveals that it
>>        apparently was sent.
>>
>>        So it's failing for another reason which a direct TLS
>>        connection helps to confirm.
>>
>>        It appears I have a similar problem as Ulrich Mueller
>>        which he reported back April of last year in bug#26359;
>>
>>            https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26359
>>
>>       His workaround. a `defadvice` also works for me.
>>
>>       Hopefully. a fix will solve these issues and allow one to
>>       designatre for a partiular network connection that a
>>       password is required (supplied or prompted for) upon an
>>       initial connection and not just only after an initial
>>       unauthenticated connetion failure;
;>>
>
> This is already in place, and it works for me, but itʼs not working
> correctly for you. Could you provide more details on how youʼre
> specifying your username/password? Based on looking at the code, this
> situation could arise if you only set smtpmail-smtp-user without
> having an entry in .authinfo.

  That's my situation.

  I don't have and don't want that entry saved on disk.
  
  Thanks.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

>> This is already in place, and it works for me, but itʼs not working
>> correctly for you. Could you provide more details on how youʼre
>> specifying your username/password? Based on looking at the code, this
>> situation could arise if you only set smtpmail-smtp-user without
>> having an entry in .authinfo.
>
>   That's my situation.
>
>   I don't have and don't want that entry saved on disk.

Which entry? Thereʼs no need to store the password, a .authinfo with
just

machine my.mail.provider login myname port 465

should be enough to get auth-source to prompt you for the password
straight after the SMTP server sends its capabilities (and this will
not cause the password to be stored on disk).

Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>>> This is already in place, and it works for me, but itʼs not working
>>> correctly for you. Could you provide more details on how youʼre
>>> specifying your username/password? Based on looking at the code, this
>>> situation could arise if you only set smtpmail-smtp-user without
>>> having an entry in .authinfo.
>>
>>   That's my situation.
>>
>>   I don't have and don't want that entry saved on disk.
>
> Which entry?

  The emtire SMTP server entry.
  
>              Thereʼs no need to store the password, a .authinfo with
> just
>
> machine my.mail.provider login myname port 465
>
> should be enough to get auth-source to prompt you for the password
> straight after the SMTP server sends its capabilities (and this will
> not cause the password to be stored on disk).

  I have serveral emtries in my .authinfo.gpg -- most without a
  password stored.

  There are two 2 servers that I don't want ANY information about
  stored on disk -- not even in an encrypted .authinfo.gpg file.

  Previously, one used `smtpmail-auth-credentials' for this.

  Thanks.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Eli Zaretskii]

> From: Live System User <nyc4bos@aol.com>
> Cc: 31990@debbugs.gnu.org
> Date: Wed, 11 Jul 2018 16:47:32 -0400
> 
>   Previously, one used `smtpmail-auth-credentials' for this.

But smtpmail-auth-credentials was saved on your .emacs on disk, wasn't
it?  Or did you define it manually anew in each session you started?

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Live System User <nyc4bos@aol.com>
>> Cc: 31990@debbugs.gnu.org
>> Date: Wed, 11 Jul 2018 16:47:32 -0400
>> 
>>   Previously, one used `smtpmail-auth-credentials' for this.
>
> But smtpmail-auth-credentials was saved on your .emacs on disk, wasn't
> it?  Or did you define it manually anew in each session you started?

  It was done manually anew in each session, yes.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Eli Zaretskii]

> From: Live System User <nyc4bos@aol.com>
> Cc: 31990@debbugs.gnu.org
> Date: Thu, 09 Aug 2018 17:54:34 -0400
> 
> >>   Previously, one used `smtpmail-auth-credentials' for this.
> >
> > But smtpmail-auth-credentials was saved on your .emacs on disk, wasn't
> > it?  Or did you define it manually anew in each session you started?
> 
>   It was done manually anew in each session, yes.

Then you should be able to manually set the variables derived from the
auth file, no?

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Live System User <nyc4bos@aol.com>
>> Cc: 31990@debbugs.gnu.org
>> Date: Thu, 09 Aug 2018 17:54:34 -0400
>> 
>> >>   Previously, one used `smtpmail-auth-credentials' for this.
>> >
>> > But smtpmail-auth-credentials was saved on your .emacs on disk, wasn't
>> > it?  Or did you define it manually anew in each session you started?
>> 
>>   It was done manually anew in each session, yes.
>
> Then you should be able to manually set the variables derived from the
> auth file, no?

  Unfortunately, no, as there is only the variable `smtpmail-smtp-user'
  and no "smtpmail-smtp-password"-like variable...

  Thanks.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Eli Zaretskii]

> From: Live System User <nyc4bos@aol.com>
> Cc: 31990@debbugs.gnu.org
> Date: Fri, 10 Aug 2018 04:53:16 -0400
> 
> >>   It was done manually anew in each session, yes.
> >
> > Then you should be able to manually set the variables derived from the
> > auth file, no?
> 
>   Unfortunately, no, as there is only the variable `smtpmail-smtp-user'
>   and no "smtpmail-smtp-password"-like variable...

Then perhaps we should add them.

I do consider yours a very strange use case, btw.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Live System User <nyc4bos@aol.com>
>> Cc: 31990@debbugs.gnu.org
>> Date: Fri, 10 Aug 2018 04:53:16 -0400
>> 
>> >>   It was done manually anew in each session, yes.
>> >
>> > Then you should be able to manually set the variables derived from the
>> > auth file, no?
>> 
>>   Unfortunately, no, as there is only the variable `smtpmail-smtp-user'
>>   and no "smtpmail-smtp-password"-like variable...
>
> Then perhaps we should add them.

  Yes, although I would prefer that the solution would be more
  comprehensive and allow users to make first-time *authenicated*
  connections instead of retrying (with a subsequent prompt for
  the password) only after a first-time *unauthenicated* connection
  failure.

  This would better solve this issue and for bug#26359 as well.

> I do consider yours a very strange use case, btw.

  I do it for my sense of privacy (as little as it may be).

  To each's own...
  
  Thanks.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Live System User <nyc4bos@aol.com>
>>> Cc: 31990@debbugs.gnu.org
>>> Date: Fri, 10 Aug 2018 04:53:16 -0400
>>> 
>>> >>   It was done manually anew in each session, yes.
>>> >
>>> > Then you should be able to manually set the variables derived from the
>>> > auth file, no?
>>> 
>>>   Unfortunately, no, as there is only the variable `smtpmail-smtp-user'
>>>   and no "smtpmail-smtp-password"-like variable...
>>
>> Then perhaps we should add them.

And then people go 'but I want different values for different
accounts', and weʼre back at the .authinfo solution.

>   Yes, although I would prefer that the solution would be more
>   comprehensive and allow users to make first-time *authenicated*
>   connections instead of retrying (with a subsequent prompt for
>   the password) only after a first-time *unauthenicated* connection
>   failure.
>
>   This would better solve this issue and for bug#26359 as well.
>
>> I do consider yours a very strange use case, btw.
>
>   I do it for my sense of privacy (as little as it may be).

Adding just the smtp username into .authinfo is really that much of an
issue for you? Given that youʼre using initially-unencrypted SMTP
connections, I fail to see the benefit to your privacy.

>   To each's own...

Indeed.

Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Noam Postavsky]

Robert Pluim <rpluim@gmail.com> writes:

>>>>   Unfortunately, no, as there is only the variable `smtpmail-smtp-user'
>>>>   and no "smtpmail-smtp-password"-like variable...
>>>
>>> Then perhaps we should add them.
>
> And then people go 'but I want different values for different
> accounts', and weʼre back at the .authinfo solution.

Maybe an auth-source-backend which stores to an Emacs variable?  It
could be independently useful as a sort of "simplest example of an
auth-source-backend".

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Live System User <nyc4bos@aol.com>
>>>> Cc: 31990@debbugs.gnu.org
>>>> Date: Fri, 10 Aug 2018 04:53:16 -0400
>>>> 
>>>> >>   It was done manually anew in each session, yes.
>>>> >
>>>> > Then you should be able to manually set the variables derived from the
>>>> > auth file, no?
>>>> 
>>>>   Unfortunately, no, as there is only the variable `smtpmail-smtp-user'
>>>>   and no "smtpmail-smtp-password"-like variable...
>>>
>>> Then perhaps we should add them.
>
> And then people go 'but I want different values for different
> accounts', and weʼre back at the .authinfo solution.
>
>>   Yes, although I would prefer that the solution would be more
>>   comprehensive and allow users to make first-time *authenicated*
>>   connections instead of retrying (with a subsequent prompt for
>>   the password) only after a first-time *unauthenicated* connection
>>   failure.
>>
>>   This would better solve this issue and for bug#26359 as well.
>>
>>> I do consider yours a very strange use case, btw.
>>
>>   I do it for my sense of privacy (as little as it may be).
>
> Adding just the smtp username into .authinfo is really that much of an
> issue for you?

  I don't want that information for 2 accounts *stored on disk*.

>                Given that youʼre using initially-unencrypted SMTP
> connections,

  This issue is *also* present in an initially-*ENCRYPTED* TlS SMTP
  connection (port 465).

>              I fail to see the benefit to your privacy.

  Would you use similiar arguments for those who chose NOT to store
  their SMTP pasword in an (encrypted) .authinfo file?

>>   To each's own...
>
> Indeed.

  Then, nopefully, this option will be restored back in Emacs.

  Thanks.

>
> Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Live System User <nyc4bos@aol.com> writes:
>>>   I don't have and don't want that entry saved on disk.
>>
>> Which entry?
>
>   The emtire SMTP server entry.
>   
>>              Thereʼs no need to store the password, a .authinfo with
>> just
>>
>> machine my.mail.provider login myname port 465
>>
>> should be enough to get auth-source to prompt you for the password
>> straight after the SMTP server sends its capabilities (and this will
>> not cause the password to be stored on disk).
>
>   I have serveral emtries in my .authinfo.gpg -- most without a
>   password stored.
>
>   There are two 2 servers that I don't want ANY information about
>   stored on disk -- not even in an encrypted .authinfo.gpg file.

Then how do you expect emacs to know that for those 2 particular
servers it should prompt straight away? Or are you asking for a
generic 'if AUTH in capabilities then prompt username and password'
feature?

>   Previously, one used `smtpmail-auth-credentials' for this.

Which as Eli points out needed to be stored somewhere as well.

Regards

Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>> Robert Pluim <rpluim@gmail.com> writes:
>>
>>> Live System User <nyc4bos@aol.com> writes:
>>>>   I don't have and don't want that entry saved on disk.
>>>
>>> Which entry?
>>
>>   The emtire SMTP server entry.
>>   
>>>              Thereʼs no need to store the password, a .authinfo with
>>> just
>>>
>>> machine my.mail.provider login myname port 465
>>>
>>> should be enough to get auth-source to prompt you for the password
>>> straight after the SMTP server sends its capabilities (and this will
>>> not cause the password to be stored on disk).
>>
>>   I have serveral emtries in my .authinfo.gpg -- most without a
>>   password stored.
>>
>>   There are two 2 servers that I don't want ANY information about
>>   stored on disk -- not even in an encrypted .authinfo.gpg file.
>
> Then how do you expect emacs to know that for those 2 particular
> servers it should prompt straight away?

  Because (I believe) that the protocol requires a "password" or
  certificate.

>                                         Or are you asking for a
> generic 'if AUTH in capabilities then prompt username and password'
> feature?

  I'm requesting to restore the capability that
  `smtpmail-auth-credentials' provided previously.

>
>>   Previously, one used `smtpmail-auth-credentials' for this.
>
> Which as Eli points out needed to be stored somewhere as well.

  But it doesn't have to be stored on *disk*.

  It can be defined anew each Emacs session and thus only "stored"
  in *memory*.

  Thanks.
  
>
> Regards
>
> Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

>> Then how do you expect emacs to know that for those 2 particular
>> servers it should prompt straight away?
>
>   Because (I believe) that the protocol requires a "password" or
>   certificate.

Thatʼs unfortunately not the way SMTP authentication works, itʼs very
much optional (and some servers change their authentication
requirements based on the recipient of the mail youʼre trying to
send).

>
>>                                         Or are you asking for a
>> generic 'if AUTH in capabilities then prompt username and password'
>> feature?
>
>   I'm requesting to restore the capability that
>   `smtpmail-auth-credentials' provided previously.
>
>>
>>>   Previously, one used `smtpmail-auth-credentials' for this.
>>
>> Which as Eli points out needed to be stored somewhere as well.
>
>   But it doesn't have to be stored on *disk*.
>
>   It can be defined anew each Emacs session and thus only "stored"
>   in *memory*.

I would find it very annoying to have to do that, but to each his
own. I doubt that having the username in memory is any more secure
than having it in an encrypted file.

Having said that, there might be a case that smtpmail should prompt
for authentication if smtpmail-smtp-user is set even without a
corresponding .authinfo setting. Iʼll take a look.

Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

> Live System User <nyc4bos@aol.com> writes:
>
>>> Then how do you expect emacs to know that for those 2 particular
>>> servers it should prompt straight away?
>>
>>   Because (I believe) that the protocol requires a "password" or
>>   certificate.
>
> Thatʼs unfortunately not the way SMTP authentication works,

  I thought from my original message that you responded to that
  you understood that the "protocol" I'm referring to (above) is
  TLS (in conjunction with SMTP), not SMTP separately or in the
  absense of a TLS connection.

  Perhaps we are miscommunicating?

>                        itʼs very
> much optional

  I believe that either a "password" or a certicate is needed
  to establish a TLS conection and not optional.

>               (and some servers change their authentication
> requirements based on the recipient of the mail youʼre trying to
> send).

  Are we still talking about TLS connectons?
  
  Unless there is NO authenication required, a changed authenication
  requirement is still an authenication requiring a "password" or
  certificate if it involves TLS, nonetheless.

  That valid "password" can even be blank, an email address or anything
  (including the recipient) depending on the server's valid authenication
  method.

  I'm saying that I believe the SSL/TLS or STARTTLS protocols require
  a "password" or certficate.  Are you saying that's incorrect or it's
  not necessarily so?
>
>>
>>>                                         Or are you asking for a
>>> generic 'if AUTH in capabilities then prompt username and password'
>>> feature?
>>
>>   I'm requesting to restore the capability that
>>   `smtpmail-auth-credentials' provided previously.
>>
>>>
>>>>   Previously, one used `smtpmail-auth-credentials' for this.
>>>
>>> Which as Eli points out needed to be stored somewhere as well.
>>
>>   But it doesn't have to be stored on *disk*.
>>
>>   It can be defined anew each Emacs session and thus only "stored"
>>   in *memory*.
>
> I would find it very annoying to have to do that, but to each his
> own. I doubt that having the username in memory is any more secure
> than having it in an encrypted file.

  I'm sure that there are those that feel that same way about passwords.

  And even so they still feel more comfortable not storing their
  passsword, even in an encryped file, on disk.
>
> Having said that, there might be a case that smtpmail should prompt
> for authentication if smtpmail-smtp-user is set even without a
> corresponding .authinfo setting. Iʼll take a look.

  `smtpmail-auth-credentials' use to facilitate this.

  A similiar methodology would suffice.

>                                  Iʼll take a look.

  Thanks.
>
> Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

Live System User <nyc4bos@aol.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Live System User <nyc4bos@aol.com> writes:
>>
>>>> Then how do you expect emacs to know that for those 2 particular
>>>> servers it should prompt straight away?
>>>
>>>   Because (I believe) that the protocol requires a "password" or
>>>   certificate.
>>
>> Thatʼs unfortunately not the way SMTP authentication works,
>
>   I thought from my original message that you responded to that
>   you understood that the "protocol" I'm referring to (above) is
>   TLS (in conjunction with SMTP), not SMTP separately or in the
>   absense of a TLS connection.
>
>   Perhaps we are miscommunicating?

We are. Iʼm only talking about SMTP authentication, not TLS. Without
going back and rereading, my memory says that it turned out you were
not having a TLS issue.

>
>>                        itʼs very
>> much optional
>
>   I believe that either a "password" or a certicate is needed
>   to establish a TLS conection and not optional.
>

You need a certificate on the server side for TLS. For SMTP auth you
need a password. The two are completely separate protocols.

>>               (and some servers change their authentication
>> requirements based on the recipient of the mail youʼre trying to
>> send).
>
>   Are we still talking about TLS connectons?
>   
>   Unless there is NO authenication required, a changed authenication
>   requirement is still an authenication requiring a "password" or
>   certificate if it involves TLS, nonetheless.
>
>   That valid "password" can even be blank, an email address or anything
>   (including the recipient) depending on the server's valid authenication
>   method.
>
>   I'm saying that I believe the SSL/TLS or STARTTLS protocols require
>   a "password" or certficate.  Are you saying that's incorrect or it's
>   not necessarily so?
>>

As noted above, Iʼm only talking about SMTP authentication.

Robert

bug#31990: 26.1; Stuck in loop trying to send bug report

[Live System User]

Robert Pluim <rpluim@gmail.com> writes:

[...]

>         Iʼm only talking about SMTP authentication,

  I look forward to the restoration of first-time authenticatd
  (i.e. the password initially supplied) SMTP connections.

  Thanks.

bug#31990: 26.1; Stuck in loop trying to send bug report

[Robert Pluim]

>>>>> On Tue, 21 Aug 2018 12:02:22 -0400, Live System User <nyc4bos@aol.com> said:

    Live> Robert Pluim <rpluim@gmail.com> writes:
    Live> [...]

    >> Iʼm only talking about SMTP authentication,

    Live>   I look forward to the restoration of first-time authenticatd
    Live>   (i.e. the password initially supplied) SMTP connections.

Lars just added 'smtptmail-servers-requiring-authorization' to
emacs-27, which I believe should solve this for you if you set it to
".*".

Robert