unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* smtpmail.el and 1msg
@ 2004-03-04 21:29 jglauner
  2004-03-08 16:51 ` Simon Josefsson
  0 siblings, 1 reply; 14+ messages in thread
From: jglauner @ 2004-03-04 21:29 UTC (permalink / raw)


I'd like to propose a patch (and I'm not sure I'm in the right place)
for smtpmail.el.  

The problem I experienced was that smtpmail would spin, waiting for
response from the "QUIT" command.  It would appear that my ISP changed
its mail software and now has configured an option called 1msg which
closes the connection when the end of "DATA" has been reached.  The
smtpmail package was still trying to read from the process, even
though the process had closed.  So I created a binding for a variable
called smtpmail-1msg, parsing the greeting string, looking for the
1msg token to set and later use when deciding whether or not to bother
sending "QUIT".

Here's my diff:


diff -c /usr/share/emacs/21.2/lisp/mail/smtpmail.el /home/jglauner/emacs/smtpmail.el
*** /usr/share/emacs/21.2/lisp/mail/smtpmail.el	Fri Mar 22 11:02:55 2002
--- /home/jglauner/emacs/smtpmail.el	Fri Feb 20 09:35:48 2004
***************
*** 349,355 ****
  	response-code
  	greeting
  	process-buffer
! 	(supported-extensions '()))
      (unwind-protect
  	(catch 'done
  	  ;; get or create the trace buffer
--- 349,356 ----
  	response-code
  	greeting
  	process-buffer
! 	(supported-extensions '())
! 	(smtpmail-1msg nil))
      (unwind-protect
  	(catch 'done
  	  ;; get or create the trace buffer
***************
*** 374,386 ****
  	    (make-local-variable 'smtpmail-read-point)
  	    (setq smtpmail-read-point (point-min))
  
- 	    
  	    (if (or (null (car (setq greeting (smtpmail-read-response process))))
  		    (not (integerp (car greeting)))
  		    (>= (car greeting) 400))
  		(throw 'done nil)
  	      )
  
  	    ;; EHLO
  	    (smtpmail-send-command process (format "EHLO %s" (smtpmail-fqdn)))
  
--- 375,388 ----
  	    (make-local-variable 'smtpmail-read-point)
  	    (setq smtpmail-read-point (point-min))
  
  	    (if (or (null (car (setq greeting (smtpmail-read-response process))))
  		    (not (integerp (car greeting)))
  		    (>= (car greeting) 400))
  		(throw 'done nil)
  	      )
  
+ 	    (setq smtpmail-1msg (string-match "1msg/" (cadr greeting)))
+ 
  	    ;; EHLO
  	    (smtpmail-send-command process (format "EHLO %s" (smtpmail-fqdn)))
  
***************
*** 521,527 ****
  ;	    (and (null (car (smtpmail-read-response process)))
  ;		 (throw 'done nil))
  	    t ))
!       (if process
  	  (save-excursion
  	    (set-buffer (process-buffer process))
  	    (smtpmail-send-command process "QUIT")
--- 523,529 ----
  ;	    (and (null (car (smtpmail-read-response process)))
  ;		 (throw 'done nil))
  	    t ))
!       (if (and process (not smtpmail-1msg))
  	  (save-excursion
  	    (set-buffer (process-buffer process))
  	    (smtpmail-send-command process "QUIT")

Diff finished at Fri Feb 20 09:36:00


Cheers!

--Jonathan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-04 21:29 smtpmail.el and 1msg jglauner
@ 2004-03-08 16:51 ` Simon Josefsson
  2004-03-09 22:36   ` Simon Josefsson
  2004-03-11 14:37   ` Stefan Monnier
  0 siblings, 2 replies; 14+ messages in thread
From: Simon Josefsson @ 2004-03-08 16:51 UTC (permalink / raw)


jglauner@sbum.org writes:

> I'd like to propose a patch (and I'm not sure I'm in the right place)
> for smtpmail.el.

Thanks!  I believe this also explains a few bug reports I've got, with
the exact same symptoms as the ones you describe.

> The problem I experienced was that smtpmail would spin, waiting for
> response from the "QUIT" command.  It would appear that my ISP changed
> its mail software and now has configured an option called 1msg which
> closes the connection when the end of "DATA" has been reached.

Does anyone know what motivate people to do this?  It sounds to me
like a rather disruptive thing to do.

> The smtpmail package was still trying to read from the process, even
> though the process had closed.  So I created a binding for a
> variable called smtpmail-1msg, parsing the greeting string, looking
> for the 1msg token to set and later use when deciding whether or not
> to bother sending "QUIT".

Do you have of a reference to this 1msg stuff?  It would be good to
include a reference to it in smtpmail.el.  I'm particularly worried
that we might not be conforming to the intention of 1msg fully.
Perhaps there is some deep idea behind it.  (Though I doubt that..)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-08 16:51 ` Simon Josefsson
@ 2004-03-09 22:36   ` Simon Josefsson
  2004-03-10 18:15     ` jglauner
  2004-03-11 14:37   ` Stefan Monnier
  1 sibling, 1 reply; 14+ messages in thread
From: Simon Josefsson @ 2004-03-09 22:36 UTC (permalink / raw)
  Cc: emacs-devel

[This is a resend, is something wrong with the mailing list?  Or gmane?]

jglauner@sbum.org writes:

> I'd like to propose a patch (and I'm not sure I'm in the right place)
> for smtpmail.el.

Thanks!  I believe this also explains a few bug reports I've got, with
the exact same symptoms as the ones you describe.

> The problem I experienced was that smtpmail would spin, waiting for
> response from the "QUIT" command.  It would appear that my ISP changed
> its mail software and now has configured an option called 1msg which
> closes the connection when the end of "DATA" has been reached.

Does anyone know what motivate people to do this?  It sounds to me
like a rather disruptive thing to do.

> The smtpmail package was still trying to read from the process, even
> though the process had closed.  So I created a binding for a
> variable called smtpmail-1msg, parsing the greeting string, looking
> for the 1msg token to set and later use when deciding whether or not
> to bother sending "QUIT".

Do you have of a reference to this 1msg stuff?  It would be good to
include a reference to it in smtpmail.el.  I'm particularly worried
that we might not be conforming to the intention of 1msg fully.
Perhaps there is some deep idea behind it.  (Though I doubt that..)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-09 22:36   ` Simon Josefsson
@ 2004-03-10 18:15     ` jglauner
  2004-03-10 22:51       ` Simon Josefsson
  0 siblings, 1 reply; 14+ messages in thread
From: jglauner @ 2004-03-10 18:15 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:

  > Thanks!  I believe this also explains a few bug reports I've got,
  > with the exact same symptoms as the ones you describe.

  > Does anyone know what motivate people to do this?  It sounds to me
  > like a rather disruptive thing to do.

It would appear that it's a spam-prevention measure.

  > Do you have of a reference to this 1msg stuff?  

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=53a824b6.0402031144.54558593%40posting.google.com&rnum=30&prev=/groups%3Fq%3D1msg%26start%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D53a824b6.0402031144.54558593%2540posting.google.com%26rnum%3D30

Sorry about the long URL there, but I that thread was as close as I
could find.  Basically, SBC came in and made some changes that aren't
compatible with various mailers including Mozilla, Eudora, and Emacs
smtpmail...  If I use smtpauth.sbcglobal.net and use AUTH LOGIN, I can
send just fine and it waits for QUIT just like it's supposed to.  

Ultimately, I suspect that other ISPs are going to use the 1msg option
to help stop spammers.  *eyeroll* Not sure how it should be
incorporated...  all I know for sure is that my patch Works For Me.
;-)

--Jon

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 18:15     ` jglauner
@ 2004-03-10 22:51       ` Simon Josefsson
  2004-03-10 23:05         ` Jonathan Glauner
  0 siblings, 1 reply; 14+ messages in thread
From: Simon Josefsson @ 2004-03-10 22:51 UTC (permalink / raw)
  Cc: emacs-devel

jglauner@sbum.org writes:

>   > Do you have of a reference to this 1msg stuff?  
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=53a824b6.0402031144.54558593%40posting.google.com&rnum=30&prev=/groups%3Fq%3D1msg%26start%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D53a824b6.0402031144.54558593%2540posting.google.com%26rnum%3D30
>
> Sorry about the long URL there, but I that thread was as close as I
> could find.  Basically, SBC came in and made some changes that aren't
> compatible with various mailers including Mozilla, Eudora, and Emacs
> smtpmail...  If I use smtpauth.sbcglobal.net and use AUTH LOGIN, I can
> send just fine and it waits for QUIT just like it's supposed to.  
>
> Ultimately, I suspect that other ISPs are going to use the 1msg option
> to help stop spammers.  *eyeroll* Not sure how it should be
> incorporated...  all I know for sure is that my patch Works For Me.
> ;-)

Thanks for the reference.  I'm not sure about your patch -- it appears
wrong to look for /1msg.  I think the right fix would be to fix the
code so that smtpmail.el doesn't hang forever waiting for response to
QUIT.  So it should work without detecting "/1msg".  Does this patch
help?  If not, can you pinpoint exactly where does smtpmail.el hang,
using (setq debug-on-quit t) and pressing C-g when it spins?

--- smtpmail.el.~1.65.~	2004-02-11 13:34:59.000000000 +0100
+++ smtpmail.el	2004-03-10 23:50:06.000000000 +0100
@@ -1,6 +1,6 @@
 ;;; smtpmail.el --- simple SMTP protocol (RFC 821) for sending mail
 
-;; Copyright (C) 1995, 1996, 2001, 2002, 2003 Free Software Foundation, Inc.
+;; Copyright (C) 1995, 1996, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 
 ;; Author: Tomoji Kagatani <kagatani@rbc.ncl.omron.co.jp>
 ;; Maintainer: Simon Josefsson <simon@josefsson.org>
@@ -778,10 +778,12 @@
 	(response-continue t)
 	(return-value '(nil ()))
 	match-end)
-
+    (catch 'done
     (while response-continue
       (goto-char smtpmail-read-point)
       (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))
 
@@ -817,10 +819,8 @@
 	    (setq smtpmail-read-point match-end)
 	    (setq response-continue nil)
 	    (setq return-value
-		  (cons nil (nreverse response-strings)))
-	    )
-	  )))
-    (setq smtpmail-read-point match-end)
+		    (cons nil (nreverse response-strings)))))))
+      (setq smtpmail-read-point match-end))
     return-value))

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 22:51       ` Simon Josefsson
@ 2004-03-10 23:05         ` Jonathan Glauner
  2004-03-10 23:11           ` Simon Josefsson
  2004-03-12 13:42           ` Stefan Monnier
  0 siblings, 2 replies; 14+ messages in thread
From: Jonathan Glauner @ 2004-03-10 23:05 UTC (permalink / raw)
  Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]


>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:

  > Thanks for the reference.  I'm not sure about your patch -- it
  > appears wrong to look for /1msg.  I think the right fix would be
  > to fix the code so that smtpmail.el doesn't hang forever waiting
  > for response to QUIT.  So it should work without detecting
  > "/1msg".  

Agreed!  :-)

  > Does this patch help?  If not, can you pinpoint exactly
  > where does smtpmail.el hang, using (setq debug-on-quit t) and
  > pressing C-g when it spins?

The patch didn't help, and here's the backtrace from C-g:

--SNIP--

Debugger entered--Lisp error: (quit)
  accept-process-output(#<process SMTP>)
  smtpmail-read-response(#<process SMTP>)
  byte-code("\b

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 23:05         ` Jonathan Glauner
@ 2004-03-10 23:11           ` Simon Josefsson
  2004-03-10 23:24             ` Jonathan Glauner
  2004-03-10 23:38             ` Jonathan Glauner
  2004-03-12 13:42           ` Stefan Monnier
  1 sibling, 2 replies; 14+ messages in thread
From: Simon Josefsson @ 2004-03-10 23:11 UTC (permalink / raw)
  Cc: emacs-devel

Jonathan Glauner <jglauner@sbum.org> writes:

>   > Does this patch help?  If not, can you pinpoint exactly
>   > where does smtpmail.el hang, using (setq debug-on-quit t) and
>   > pressing C-g when it spins?
>
> The patch didn't help, and here's the backtrace from C-g:
>
> --SNIP--
>
> Debugger entered--Lisp error: (quit)
>   accept-process-output(#<process SMTP>)
>   smtpmail-read-response(#<process SMTP>)

How about this, then?  It add a timeout to the accept-process-output
call.

I thought accept-process-output was supposed to return if the process
died, though.  Are you using Windows or Macintosh?  I recall some
process related problems on those systems.

--- smtpmail.el.~1.65.~	2004-02-11 13:34:59.000000000 +0100
+++ smtpmail.el	2004-03-11 00:10:33.000000000 +0100
@@ -1,6 +1,6 @@
 ;;; smtpmail.el --- simple SMTP protocol (RFC 821) for sending mail
 
-;; Copyright (C) 1995, 1996, 2001, 2002, 2003 Free Software Foundation, Inc.
+;; Copyright (C) 1995, 1996, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 
 ;; Author: Tomoji Kagatani <kagatani@rbc.ncl.omron.co.jp>
 ;; Maintainer: Simon Josefsson <simon@josefsson.org>
@@ -778,11 +778,13 @@
 	(response-continue t)
 	(return-value '(nil ()))
 	match-end)
-
+    (catch 'done
     (while response-continue
       (goto-char smtpmail-read-point)
       (while (not (search-forward "\r\n" nil t))
-	(accept-process-output process)
+	  (unless (memq (process-status process) '(open run))
+	    (throw 'done nil))
+	  (accept-process-output process 1)
 	(goto-char smtpmail-read-point))
 
       (setq match-end (point))
@@ -817,10 +819,8 @@
 	    (setq smtpmail-read-point match-end)
 	    (setq response-continue nil)
 	    (setq return-value
-		  (cons nil (nreverse response-strings)))
-	    )
-	  )))
-    (setq smtpmail-read-point match-end)
+		    (cons nil (nreverse response-strings)))))))
+      (setq smtpmail-read-point match-end))
     return-value))

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 23:11           ` Simon Josefsson
@ 2004-03-10 23:24             ` Jonathan Glauner
  2004-03-10 23:38             ` Jonathan Glauner
  1 sibling, 0 replies; 14+ messages in thread
From: Jonathan Glauner @ 2004-03-10 23:24 UTC (permalink / raw)
  Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]


>>>>> "Simon" == Simon Josefsson <jas@extundo.com> writes:

  > How about this, then?  It add a timeout to the
  > accept-process-output call.

The backtrace from this patch is at the end...  it still spins after
sending.

  > I thought accept-process-output was supposed to return if the
  > process died, though.  Are you using Windows or Macintosh?  I
  > recall some process related problems on those systems.

I'm running Debian Linux on a P4 box, but I've downloaded the latest
texinfo (just to get emacs built) and the cvs version of emacs off of
savannah as of earlier today.

--backtrace--
Debugger entered--Lisp error: (quit)
  smtpmail-read-response(#<process SMTP>)
  byte-code("\b

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 23:11           ` Simon Josefsson
  2004-03-10 23:24             ` Jonathan Glauner
@ 2004-03-10 23:38             ` Jonathan Glauner
  2004-03-11 10:54               ` Simon Josefsson
  1 sibling, 1 reply; 14+ messages in thread
From: Jonathan Glauner @ 2004-03-10 23:38 UTC (permalink / raw)
  Cc: emacs-devel


Simon--

My apologies.  The first patch seems to have cured it.  I had a stale
smtpmail.elc hanging around.  I'll stick with that first patch.
Thanks again!

--Jonathan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 23:38             ` Jonathan Glauner
@ 2004-03-11 10:54               ` Simon Josefsson
  0 siblings, 0 replies; 14+ messages in thread
From: Simon Josefsson @ 2004-03-11 10:54 UTC (permalink / raw)
  Cc: emacs-devel

Jonathan Glauner <jglauner@sbum.org> writes:

> Simon--
>
> My apologies.  The first patch seems to have cured it.  I had a stale
> smtpmail.elc hanging around.  I'll stick with that first patch.
> Thanks again!

I've installed the patch, thanks.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-08 16:51 ` Simon Josefsson
  2004-03-09 22:36   ` Simon Josefsson
@ 2004-03-11 14:37   ` Stefan Monnier
  2004-03-11 18:52     ` Simon Josefsson
  1 sibling, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2004-03-11 14:37 UTC (permalink / raw)
  Cc: emacs-devel

> Thanks!  I believe this also explains a few bug reports I've got, with
> the exact same symptoms as the ones you describe.

While I think it's good to add support for 1msg, I also think it would be
worthwhile to fix the spinning problem.  After all, if the other end closes
the connection, we should detect it.  Do we?  If `no' why not and if `yes'
why does it spin?


        Stefan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-11 14:37   ` Stefan Monnier
@ 2004-03-11 18:52     ` Simon Josefsson
  2004-03-11 19:11       ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: Simon Josefsson @ 2004-03-11 18:52 UTC (permalink / raw)
  Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Thanks!  I believe this also explains a few bug reports I've got, with
>> the exact same symptoms as the ones you describe.
>
> While I think it's good to add support for 1msg, I also think it would be
> worthwhile to fix the spinning problem.  After all, if the other end closes
> the connection, we should detect it.  Do we?  If `no' why not and if `yes'
> why does it spin?

Detecting closed connections, during the spin loop, was the intention
of my patch.  They weren't detected before. What do you think?

OLD:

      (while (not (search-forward "\r\n" nil t))
	(accept-process-output process)
	(goto-char smtpmail-read-point))

NEW:

	(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))

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-11 18:52     ` Simon Josefsson
@ 2004-03-11 19:11       ` Stefan Monnier
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2004-03-11 19:11 UTC (permalink / raw)
  Cc: emacs-devel

>> While I think it's good to add support for 1msg, I also think it would be
>> worthwhile to fix the spinning problem.  After all, if the other end closes
>> the connection, we should detect it.  Do we?  If `no' why not and if `yes'
>> why does it spin?

> Detecting closed connections, during the spin loop, was the intention
> of my patch.  They weren't detected before. What do you think?

Yes, I've now seen your patch, looks fine.

> 	(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))

Isn't it possible to just check the return value of accept-process-output?
Something like

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


-- Stefan

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smtpmail.el and 1msg
  2004-03-10 23:05         ` Jonathan Glauner
  2004-03-10 23:11           ` Simon Josefsson
@ 2004-03-12 13:42           ` Stefan Monnier
  1 sibling, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2004-03-12 13:42 UTC (permalink / raw)
  Cc: emacs-devel, Simon Josefsson

> Agreed!  :-)

>> Does this patch help?  If not, can you pinpoint exactly
>> where does smtpmail.el hang, using (setq debug-on-quit t) and
>> pressing C-g when it spins?

> The patch didn't help, and here's the backtrace from C-g:

> --SNIP--

> Debugger entered--Lisp error: (quit)
>   accept-process-output(#<process SMTP>)

I think we should debug this at the C level because accept-process-output
should not hang like that when the other end has closed the connection.


        Stefan

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2004-03-12 13:42 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-04 21:29 smtpmail.el and 1msg jglauner
2004-03-08 16:51 ` Simon Josefsson
2004-03-09 22:36   ` Simon Josefsson
2004-03-10 18:15     ` jglauner
2004-03-10 22:51       ` Simon Josefsson
2004-03-10 23:05         ` Jonathan Glauner
2004-03-10 23:11           ` Simon Josefsson
2004-03-10 23:24             ` Jonathan Glauner
2004-03-10 23:38             ` Jonathan Glauner
2004-03-11 10:54               ` Simon Josefsson
2004-03-12 13:42           ` Stefan Monnier
2004-03-11 14:37   ` Stefan Monnier
2004-03-11 18:52     ` Simon Josefsson
2004-03-11 19:11       ` Stefan Monnier

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).