0.16 Mail Lossage Alert

0.16 Mail Lossage Alert

[Lars Magne Ingebrigtsen]

September 0.16 will lose mail under certain circumstances.  (In
specific, if a mail contains a Content-Lenght header all subsequent
mails will try to use that content lenght, leading to some mails
slurping other mails into their bodies.  So your important mail might
be appended to some mail in your mail.junk group that you have a five
second expiry on.)

Here's a patch:

*** nnmail.el.~1~	Thu Nov 23 20:21:47 1995
--- nnmail.el	Mon Nov 27 18:03:08 1995
***************
*** 505,510 ****
--- 505,511 ----
  	  (insert "Message-ID: " (setq message-id (nnmail-message-id)) "\n"))
  	;; Look for a Content-Length header.
  	(goto-char (point-min))
+ 	(setq content-length nil)
  	(when (re-search-forward "^Content-Length: \\([0-9]+\\)" nil t)
  	  (setq content-length (string-to-int (match-string 1)))
  	  ;; We destroy the header, since none of the backends ever 

If you have used 0.16 to do mail splitting, I'd suggest grepping
through your entire mail spool for lines with "^From " (note trailing
space).  (This is for nnml and nnmh.  nnfolder, nnmbox and nnbabyl
should sort themselves out after a while automatically, I think.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: 0.16 Mail Lossage Alert

[Steven L. Baur]

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

    Lars> So your important mail might be appended to some
    Lars> mail in your mail.junk group that you have a five second
    Lars> expiry on.)

I thought expiration only worked on an integral number of days,
rounded.  At least that is how it appears to behave.

While on the topic of expiration, (after experimenting with the
nnmail-expiry-wait-function), I think I'd like something that I can
tie into the group parameters to feed that function.  I have a very
simple-minded one -- nothing more than a big cond.

-- 
steve@miranova.com baur

Re: 0.16 Mail Lossage Alert

[Lars Magne Ingebrigtsen]

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

>     Lars> So your important mail might be appended to some
>     Lars> mail in your mail.junk group that you have a five second
>     Lars> expiry on.)
> 
> I thought expiration only worked on an integral number of days,
> rounded.  At least that is how it appears to behave.

Yes.  But if you have expiry set to -1, Gnus will expire the article
the first chance it gets, which might be 5 seconds after it receives
the mail.

> While on the topic of expiration, (after experimenting with the
> nnmail-expiry-wait-function), I think I'd like something that I can
> tie into the group parameters to feed that function.  I have a very
> simple-minded one -- nothing more than a big cond.

Yes, expiry is something that one probably should be able to specify
in the group parameters.  What did you have in mind?  `(expiry . 5)'
to override `nnmail-expiry-wait-function' for that group or something
more complex? 

-- 
Home is where the cat is.

Re: 0.16 Mail Lossage Alert

[Steven L. Baur]

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

    >> While on the topic of expiration, (after experimenting with the
    >> nnmail-expiry-wait-function), I think I'd like something that I
    >> can tie into the group parameters to feed that function.  I
    >> have a very simple-minded one -- nothing more than a big cond.

    Lars> Yes, expiry is something that one probably should be able to
    Lars> specify in the group parameters.  What did you have in mind?
    Lars> `(expiry . 5)' to override `nnmail-expiry-wait-function' for
    Lars> that group or something more complex?

I like the idea (and usage so far) of group parameters *a lot*, so I'm
biased in that direction.

(expiry . 5) or (expiry-wait . 5)
would be great.

I don't want it complex.  Rather than using a negative number to
indicate immediate expire, would it be too difficult to extend the
value space to include special atoms like 'immediate and 'never?

(expiry . 'immediate)

(defun expiry-function (group)
  (cond ((string= group "junk") 'immediate)
	((string= group "gnus-list") 'never)
...

Since nnmail-expiry-wait-function has no way of returning that it
should not apply to a group, it would be best to not let it override
the group parameters by default.

-- 
steve@miranova.com baur

Re: 0.16 Mail Lossage Alert

[Lars Magne Ingebrigtsen]

"Steven L. Baur" <steve@miranova.com> writes:

> I don't want it complex.  Rather than using a negative number to
> indicate immediate expire, would it be too difficult to extend the
> value space to include special atoms like 'immediate and 'never?

No, that makes sense.  I've added both this and the `expiry-wait'
group parameter to the todo list.  The parameter will override all the
other expiry variables for the groups that have such a parameter.

-- 
Home is where the cat is.

0.16 Mail Lossage Alert

[Lars Magne Ingebrigtsen]

September 0.16 will lose mail under certain circumstances.  (In
specific, if a mail contains a Content-Lenght header all subsequent
mails will try to use that content lenght, leading to some mails
slurping other mails into their bodies.  So your important mail might
be appended to some mail in your mail.junk group that you have a five
second expiry on.)

Here's a patch:

*** nnmail.el.~1~	Thu Nov 23 20:21:47 1995
--- nnmail.el	Mon Nov 27 18:03:08 1995
***************
*** 505,510 ****
--- 505,511 ----
  	  (insert "Message-ID: " (setq message-id (nnmail-message-id)) "\n"))
  	;; Look for a Content-Length header.
  	(goto-char (point-min))
+ 	(setq content-length nil)
  	(when (re-search-forward "^Content-Length: \\([0-9]+\\)" nil t)
  	  (setq content-length (string-to-int (match-string 1)))
  	  ;; We destroy the header, since none of the backends ever 

If you have used 0.16 to do mail splitting, I'd suggest grepping
through your entire mail spool for lines with "^From " (note trailing
space).  (This is for nnml and nnmh.  nnfolder, nnmbox and nnbabyl
should sort themselves out after a while automatically, I think.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen