[Bug: 21.4.18] startls gets stuck

[Simon Josefsson]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

>>>>>> "Uwe" == Uwe Brauer <oub at mat.ucm.es> writes:
>
>     Uwe> The odd thing is that everything seems to work, I am asked
>     Uwe> for the password, then the gmail smtp mail server sends the
>     Uwe> mail, *but* then gnus (and xemacs) gets stuck: the last
>     Uwe> message which appears is something like:
>
>     Uwe> 250 2.0.0 OK 1154349802 o45sm7514984nfa
>
> Sounds like an smtpmail bug to me.  :-P  Seriously, Gmail gave the
> protocol reply to say it's done, XEmacs posts it to the buffer, so the
> first guess is that smtpmail is waiting for something that never comes
> (eg, due to an overly strict regexp in the comint filter).  If Simon
> says not, I guess he's in the best position to diagnose since he knows
> the internals of smtpmail best.

Did you see the backtrace?  smtpmail.el blocked XEmacs, and C-g
generated a backtrace:

Debugger entered--Lisp error: (quit)
  accept-process-output(#<process "SMTP" pid 13724 state:exit>)
  smtpmail-read-response(#<process "SMTP" pid 13724 state:exit>)
...

I think XEmacs should return from accept-process-output if the server
has closed the connection (I believe that is what happened), instead
of waiting for more input that will never arrive.  If this happened, I
think smtpmail.el would handle the situation correctly.

The code looks like:

	(while (not (search-forward "\r\n" nil t))
	  (unless (memq (process-status process) '(open run))
	    (throw 'done nil))
	  (accept-process-output process)
	  (goto-char smtpmail-read-point))

So it will check the process status and return, if a-p-o would return
control to smtpmail.el.

Alternatively, smtpmail.el is inflooping here, but then I think it
would be a bug in process-status that says the connection is open/run
when it is in fact closed.

>     Uwe> Any help is appreciated, sending works but archiving not and
>     Uwe> I am not sure whether this is a bug or a wrong setting.
>
> You still have the mail in the buffer (and for Gnus, in the draft
> folder), right?  If not, that's a bug.  However, whether the archiving
> to the FCC folder happens or not is a design decision; as far as the
> MUA knows, the mail was not successfully posted, so the transaction is
> still active.  The MUA should preserve the message *somewhere*, but
> it's up to the MUA to decide how and where to do that.  Some users
> might get annoyed if their archives got cluttered up with duplicates
> in cases where the mail *did* fail and they had to resent.

Right.

>     Uwe> According to Simon Josefsson the author of smtpmail.el this
>     Uwe> seems to be an (X)Emacs bug.
>
> So, Simon, what do you think is going wrong?  Or are you just in a
> hurry to go skydiving? ;-)

Right, I don't have much time to debug this...  but from the
backtrace, it seems XEmacs is blocking, not smtpmail.el.

/Simon