Stephen> Raymond Toy writes: Stephen> There shouldn't be. Please file a bug either with M-x Stephen> report-xemacs-bug or directly to tracker.xemacs.org. Not sure what's going on. I restarted xemacs and tried sending mail. I get an error in the smtp trace buffer that I need to start STARTTLS. But starttls-use-gnutls is nil. Various experiments to investigate don't help, but I finally decided to just byte-compile smtpmail.el again. And then suddenly a fresh xemacs will automatically start starttls. Hurray! I still get the error about being unable to delete the process near the end of smtpmail-via-smtp. I stuck a (message "Deleteing process") and (sit-for 1) just before (delete-process process). I don't have this problem anymore. Some kind of race condition? Ray _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Stephen> Raymond Toy writes: Stephen> This is weird. Same error as before? Stephen> BTW, ISTR that there was a report of issues with smtpmail/gnutls on Stephen> emacs-devel. They've recently started linking to the underlying Stephen> library instead of using a process, maybe it was something to do with Stephen> that switchover, but maybe it was associated with the same Stephen> start-process method we use. Stephen> Maybe the byte compiler (more likely some macro?) is evaluating Stephen> starttls-use-gnutls and stashing the value in the byte-compiled file. Stephen> That's quite possibly the reason for byte-compiled code failing where Stephen> interpreted code doesn't. The race condition might be aggravated by Stephen> multicore systems, too, if smtpmail isn't properly waiting for the Stephen> subprocess to terminate, but assumes that it will do so "fast enough". What is the correct xemacs way to wait for a process to terminate? Ray _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

>>>>> "Stephen" == Stephen J Turnbull <stephen(a)xemacs.org&gt; writes: Stephen> Raymond Toy writes: Stephen> That's quite possibly the reason for byte-compiled code failing where Stephen> interpreted code doesn't. The race condition might be aggravated by Stephen> multicore systems, too, if smtpmail isn't properly waiting for the Stephen> subprocess to terminate, but assumes that it will do so "fast enough". Raymond> What is the correct xemacs way to wait for a process to terminate? Raymond> Still don't know how to do that, but here is what I did. Sorry, no Raymond> patch right now. Sorry for taking so long, but Here is a proper patch for what I've done. I haven't had any problems with sending mail out with this patch. Ray --- smtpmail.el-orig 2013-11-09 21:47:30.000000000 -0800 +++ smtpmail.el-rlt 2013-11-09 21:45:26.000000000 -0800 ＠＠ -799,15 +799,21 ＠＠ (with-current-buffer (process-buffer process) (smtpmail-send-command process "QUIT") (smtpmail-read-response process) + ; (if (or (null (car (setq response-code (smtpmail-read-response process)))) ; (not (integerp (car response-code))) ; (>= (car response-code) 400)) ; (throw 'done nil) ; ) - (delete-process process) - (unless smtpmail-debug-info - (kill-buffer process-buffer))))))) + ;;(message "Delete process\n") + (set-process-sentinel process 'smtpmail-process-sentinel)))))) + +(defun smtpmail-process-sentinel (process event) + (message event) + (delete-process process) + (unless smtpmail-debug-info + (kill-buffer process-buffer))) (defun smtpmail-process-filter (process output) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Stephen> Raymond Toy writes: Stephen> Thanks for the patch. What do you know about the EVENT that triggers Stephen> the sentinel? It makes me nervous that you just delete the process the string "finished\n". And (process-status process) is exit. Stephen> and kill the buffer on *any* event. I confess that I don't know the sentinel stuff at all, but since the sentinel is set only when smtpmail is sending the QUIT message to the smtp server after the entire message has been sent, perhaps it's not so bad. And the original code always deleted the process and killed the buffer. The check for the response is commented out in the original code. I'm happy to supply a new patch not to kill the process and buffer if the process-status is not exit. Ray _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Stephen> Raymond Toy writes: Stephen> If I say it's just event-driven (callback-based) code, does that help? Stephen> The point is that the sentinel receives all events, and it receives Stephen> them concurrently -- you can't know what state the server is in when Stephen> the sentinel is activated. I don't know if the process ever emits Stephen> events other than "stop" (or whatever it's called), but if it does it Stephen> presumably could do so "simultaneously" with the QUIT message. Stephen> Yes, please. After some more experience maybe we will decide that the Appended. The process and buffer are deleted only if the process status is 'exit. This seems to be the normal status. Ray _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Uwe Brauer writes: STARTTLS *is* SSL. See RFC 2487. If Gmail has a different way of supporting SMTP over SSL, I don't know about it. I suppose you could have a dedicated port where TLS authentication/privacy negotiation is done *before* connecting to the mail server, but a quick look doesn't show any documentation for it. Are you sure that's not port 465? The standard port for smtps is 465. This page: http://www.scottro.net/qnd/qnd-gmail.html says it's port 465. He also says he's never gotten it to work, nor have most of the people he knows who have tried. (Scott is a friend of mine, and quite reliable.) Port 587 is a different protocol (the mail submission protocol, RFC 2476), which happens to use SMTP for its wire protocol. (Perhaps that's confusing -- all the new restrictions are on what the receiving MSA is allowed to do, so it doesn't actually need a new wire protocol.) That RFC doesn't actually permit use of STARTTLS, but I guess that's because it was published before 2487 was. My commiserations. Seems like a very stupid thing to do to me, but I don't know what their situation is. I suspect that they just block *everything* under 1024 (or maybe everything period) except for a few ports known to have strong authentication (like 22, ssh) or considered organizationally essential (like 80 and/or 442, http and https). I doubt they really care about the difference between 587 and 465 (or 464). Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Post is tl;dr, but if anybody else thinks XEmacs really should get raw SSL/TLS connections, please speak up, priorities can be changed. Uwe Brauer writes: I suspect that what happened was that port 465 was assigned as an SSL-only version of SMTP, where the SSL connection is established externally and SMTP is tunneled over that. Then the community discovered that this wasn't a great idea, and developed the STARTTLS RFC to address the problems. The short answer is "GNU Emacs has 10x as many developers as we do and Mozilla has 100x". In Emacs, evidently until very recently this was implemented by calling openssl or gnutls-cli to open the stream (rather than asking the MTA to do STARTTLS negotiation, which is trivial to implement). Then Ted Z implemented a direct call to gnutls in v24. Either way, you then have to start talking to the remote MTA, and I'm not sure how that works. Since we can depend on gnutls-cli, I don't suppose it would be hard to port enough of GNU Emacs's capabilities to allow XEmacs to talk to dedicated SSL ports like https, nntps, and smtps. Unfortunately I don't have time at the moment. But this would surely be good enough for you since you evidently have gnutls installed (Emacs won't use OpenSSL as a matter of principle). No problem, just wanted to make sure it wasn't that simple. :-) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Raymond Toy writes: That doesn't surprise me. gnutls, like most GNU Project programs, goes out of its way to be incompatible with other programs (I think it's actually just a permissive attitude toward incompatibility coming from RMS's copyright paranoia, but when it annoys me I tend to take it personally:-). *sigh* We probably should sync this with Emacs. gnutls is well-established now, although I suppose *most* systems with XEmacs on them will have OpenSSL too. Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Jerry James writes: By "sync this", I meant making gnutls-cli work. I do too, and I haven't even looked at the code yet. ;-) I have no doubt at all that Ted Z is capable of that. :-/ Certainly that's that right approach IMO. Surely we can match the Emacs API in Lisp, although it might be in some cost of security or efficiency. I don't mind the incompatibility if we have full support of things like STARTTLS negotiation for protocols that support STARTTLS, etc. *sigh* That's a completely different set of issues. Let's stop doing this to ourselves. If it's a mistake not to emulate Ted Z, we can pay for it later. Do what you think is right. OK, I can see the rationale (although I'd never heard of NSS vs OpenSSL and GNUTLS, the FIPS certification is a killer argument in favor of it as a leading candidate). Do you know why GNUTLS is favored over OpenSSL? The latter is older, and from what I'm hearing on emacs-devel, more stable. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Jerry James writes: Work on what you think is important, or just what's important to you. ;-) Sure, if you get a chance. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta