Found no mail! [sgnus 0.17]

Found no mail! [sgnus 0.17]

[Steven L. Baur]

Take great precautions before trusting your mail to 0.17.  There looks
like there might be a problem in nnmail.el.

-- 
steve@miranova.com baur

Re: Found no mail! [sgnus 0.17]

[Steven L. Baur]

It's not a Gnus problem.  The ``fix'' applies to any late model Emacs.

If you don't set mail-use-rfc822 to t, and try to save an article with
a From line that looks something like:

From: joeluser@aol.com (Joe "Stupid" Luser)

The Emacs mail utilies will, when saving to mailbox format, convert it
into a From_ line that looks like:

>From joeluser@aol.com (JoeLuser) ...

Which will cause Gnus to bomb when attempting to deal with it later
(as in nnmail-process-unix-mail-format putting it into an nnml group)
since it does not match the ugly rmail-unix-mail-delimiter regular
expression.

This applies to anything in Emacs calling the standard mail-utils to
save in mailbox format.

Regards,
-- 
steve@miranova.com baur

Re: Found no mail! [sgnus 0.17]

[Erik Selberg]

> It's not a Gnus problem.  The ``fix'' applies to any late model Emacs.
> If you don't set mail-use-rfc822 to t, and try to save an article with
> a From line that looks something like:

I'm still getting it. Here are symptoms:

upon clean startup, things work fine.

"Found no mail!" appears upon subsequet calls to
gnus-group-get-new-news. I believe this to be the case due to a
.gnus-crash-box file which is generated and empty. Apparently, gnus
believes that this contains the contents of a spool file (seems that
it's trying to read it).

"Found no mail!" also appears if the spool file exists, but is
zero-length, a common occurance around here (as spool files are
symlinked). 

-Erik

Re: Found no mail! [sgnus 0.17]

[Lars Magne Ingebrigtsen]

steve@miranova.com (Steven L. Baur) writes:

> If you don't set mail-use-rfc822 to t, and try to save an article with
> a From line that looks something like:
> 
> From: joeluser@aol.com (Joe "Stupid" Luser)
> 
> The Emacs mail utilies will, when saving to mailbox format, convert it
> into a From_ line that looks like:
> 
> >From joeluser@aol.com (JoeLuser) ...

How odd.  But when does Gnus use functions that have this...
interesting (yuck) feature?  And... why does this happen?  The
documentation to that variable doesn't say anything specific about
when it's used:

mail-use-rfc822's value is nil

Documentation:
*If non-nil, use a full, hairy RFC822 parser on mail addresses.
Otherwise, (the default) use a smaller, somewhat faster, and
often correct parser.

-- 
Home is where the cat is.

Re: Found no mail! [sgnus 0.17]

[Steven L. Baur]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    Lars> steve@miranova.com (Steven L. Baur) writes:
    >> If you don't set mail-use-rfc822 to t ...(Emacs can barf)

    Lars> How odd.  But when does Gnus use functions that have this...
    Lars> interesting (yuck) feature?

The one that bit me was gnus-summary-save-in-mail, but anything which
calls rmail-output.  The only other function I see doing it is
gnus-author-copy-saver.

    Lars> And... why does this happen?

As near as I can tell it strips exactly one level of quotes out at
the most nested level.  This works quite well unless someone is
taking full advantage of RFC822 syntax ...

    Lars> The documentation to that variable doesn't say anything
    Lars> specific about when it's used:

I just did a grep on mail-use-rfc822 in the emacs lisp directories,
and I've changed my mind.  It is a Gnus bug.  The variable itself is
only read in mail-utils.el, in the function mail-strip-quoted-names,
which is used to build From_ lines.

It is set to t temporarily in rmail.el in rmail-make-in-reply-to-field.
It is also set to t in a pair of (let)s in vm-reply.el and vm-summary.el.
[From vm-reply.el]
          (let ((mail-use-rfc822 t))
            (and to (setq to (mail-strip-quoted-names to)))
            (and cc (setq cc (mail-strip-quoted-names cc)))))

I think you *should* protect all calls to rmail-output in gnus in the
same fashion.  (Patch appended).

    Lars> mail-use-rfc822's value is nil

    Lars> Documentation: *If non-nil, use a full, hairy RFC822 parser
    Lars> on mail addresses.  Otherwise, (the default) use a smaller,
    Lars> somewhat faster, and often correct parser.

It works exactly as advertised.

I vote for correctness since the consequences are so unpleasant.

Patch follows:
===================================================================
RCS file: RCS/ChangeLog,v
retrieving revision 1.8
diff -u -r1.8 ChangeLog
--- 1.8	1995/12/03 20:10:13
+++ ChangeLog	1995/12/04 03:42:21
@@ -1,5 +1,10 @@
 Sun Dec  3 11:44:08 1995  Steven L. Baur  <steve@miranova.com>
 
+	* gnus-msg.el (gnus-inews-do-fcc): Protect call to rmail-output by
+	temporarily setting mail-use-rfc822 to t.
+
+	* gnus.el (gnus-summary-save-in-mail): Ditto.
+
 	* gnus.el (gnus-slave-no-server): New Function.
 	(gnus-no-server): Add optional slave parameter.
 
===================================================================
RCS file: RCS/gnus.el,v
retrieving revision 1.9
diff -u -r1.9 gnus.el
--- 1.9	1995/12/03 20:44:46
+++ gnus.el	1995/12/04 03:41:34
@@ -11670,7 +11670,8 @@
 	 (widen)
 	 (if (and (file-readable-p filename) (mail-file-babyl-p filename))
 	     (gnus-output-to-rmail filename)
-	   (rmail-output filename 1 t t)))))
+	   (let ((mail-use-rfc822 t))
+	     (rmail-output filename 1 t t))))))
     ;; Remember the directory name to save articles.
     (setq gnus-newsgroup-last-mail filename)))
 
===================================================================
RCS file: RCS/gnus-msg.el,v
retrieving revision 1.6
diff -u -r1.6 gnus-msg.el
--- 1.6	1995/12/04 03:37:10
+++ gnus-msg.el	1995/12/04 03:39:19
@@ -1286,7 +1286,8 @@
 		(funcall gnus-author-copy-saver file)
 	      (if (and (file-readable-p file) (mail-file-babyl-p file))
 		  (gnus-output-to-rmail file)
-		(rmail-output file 1 t t)))))))))
+		(let ((mail-use-rfc822 t))
+		  (rmail-output file 1 t t))))))))))
 
 (defun gnus-inews-path ()
   "Return uucp path."

-- 
steve@miranova.com baur

General sgnus 0.17 problems [Was: Found no mail! [sgnus 0.17]]

[Sten Drescher]

steve@miranova.com (Steven L. Baur) said:

SLB> Take great precautions before trusting your mail to 0.17.  There
SLB> looks like there might be a problem in nnmail.el.

	Looks like there might be lots of problems.  Finding the best
unread group doesn't work in the Groups buffer (it goes to the end of
the buffer) or the Summary buffer (it returns to the Group buffer instead),
reading the next article in the thread doesn't work in the summary
buffer (it goes to the first unread article in the buffer), ...

-- 
#include <disclaimer.h>				/* Sten Drescher */
To get my PGP public key, send me email with your public key and
	Subject: PGP key exchange
Key fingerprint =  90 5F 1D FD A6 7C 84 5E  A9 D3 90 16 B2 44 C4 F3

Re: Found no mail! [sgnus 0.17]

[Erik Selberg]

Steven L Baur writes:

> The patch you posted to the list solves the wrong problem too late.
> Having a zero length file in nnmail-process-unix-mail-format means
> that nnmail-prepare-incoming-hook has already been called on it *and*
> the prior zero-length checks have been botched.

I don't know about prior zero-length hooks, but my
nnmail-prepare-incoming-hook is nil. Perhaps there's a problem?

> I do see a problem with symbolic links to spool files.  I have been
> unable to make that [mis]feature work at all.  Eg. a symbolic link to
> either a zero length file, or to a file containing valid mail is
> missed in the spool scan *and* a specific M-g scan.  This behavior is
> identical under both XEmacs 19.13 and Emacs 19.30.

curious; my spool file is a symbolic link. Perhaps ding is not reading
it as such?

> The question is why do they work/bomb for you at all?

> The first place to look is ange FTP, since it has weird hooks into all
> the file checks.

> What version of ange FTP are you using?  You should be using the
> version supplied with Emacs.  Check every directory in your load-path
> to be sure.

> Are you using file names with colons in them?

I'm using standard emacs 19.30; I took ange-ftp out of my local libs
when 19 was available on our system. No colons or nuthin either. 

-Erik

Symbolic Links for mailboxes in Gnus

[Steven L. Baur]

(Code examples taken from nnmail.el)

1)  If you're using procmail for mail splitting, symbolic links in the
procmail directory are automagically removed from consideration by the
following code in nnmail-get-spool-files:
      ;; Remove any directories that inadvertantly match the procmail
      ;; suffix, which might happen if the suffix is "".
      (while p
	(and (or (file-directory-p (car p))
>>>>		 (file-symlink-p (car p)))
	     (setq procmails (delete (car p) procmails)))
	(setq p (cdr p)))

This is as it should be, IMHO.  However, the incorrect comment should
be changed to reflect the fact that symbolic links are ditched too.


2)  If you are not using procmail, the the following code loses when
the mailbox is a symbolic link (from nnmail-get-new-mail):
      ;; The we go through all the existing spool files and split the
      ;; mail from each.
      (while spools
	(setq spool (pop spools))
	;; We read each spool file if either the spool is a POP-mail
	;; spool, or the file exists.  We can't check for the
	;; existance of POPped mail.
	(when (or (string-match "^po:" spool)
		  (and (file-exists-p spool)
>>>>		       (> (nth 7 (file-attributes spool)) 0)))

The idiom (nth 7 (file-attributes ...)) returns the file size, but
with a symbolic link, it will return the length in characters of the
filename the link is pointing to (always > 0).

In order to make this code work with symbolic links it must be changed to:
		       (> (nth 7 (file-attributes (file-truename spool))) 0)))

Now the code will work with symbolic links, which also seem to not
bother movemail.

Do we really want Gnus to encourage this unsafe practice?
-- 
steve@miranova.com baur

Re: Symbolic Links for mailboxes in Gnus

[Erik Selberg]

Steven L Baur writes:

> 2)  If you are not using procmail, the the following code loses when
> the mailbox is a symbolic link (from nnmail-get-new-mail):
>       ;; The we go through all the existing spool files and split the
>       ;; mail from each.
>       (while spools
> 	(setq spool (pop spools))
> 	;; We read each spool file if either the spool is a POP-mail
> 	;; spool, or the file exists.  We can't check for the
> 	;; existance of POPped mail.
> 	(when (or (string-match "^po:" spool)
> 		  (and (file-exists-p spool)
>>>>> (> (nth 7 (file-attributes spool)) 0)))

> The idiom (nth 7 (file-attributes ...)) returns the file size, but
> with a symbolic link, it will return the length in characters of the
> filename the link is pointing to (always > 0).

> In order to make this code work with symbolic links it must be changed to:
> 		       (> (nth 7 (file-attributes (file-truename spool))) 0)))

> Now the code will work with symbolic links, which also seem to not
> bother movemail.

yup... just tried it, and things are working well without the patch I
previously posted.

> Do we really want Gnus to encourage this unsafe practice?

I misunderstand how this can be termed "unsafe." Could you elaborate?
Here at UW, it's nearly a necessity because of our completely outdated
spool system.

-Erik