Re: 'message contains bare newlines' - was Re: cyrus imapd 1.6.25 beta version

2000-12-21 Thread Lawrence Greenfield

   Date: Fri, 15 Dec 2000 14:48:50 -0500
   From: "David L. Parsley" <[EMAIL PROTECTED]>

[...]
   I remember people saying bare newlines violated RFC's, but shouldn't
   cyrus be as lenient as possible in what it accepts, and as compliant as
   possible in what it sends/produces?

The authors of Cyrus have historically been leading proponents of "be
liberal considered harmful", since it just leads to more software
generated non-compliant protocol and we all end up in a bigger mess.

The bare newlines-rejection has never been a problem for us; could it
be that there's some local piece of software that tends to generate
them a lot that should be fixed?

I can't think of any ramifications to your fix, but it's unlikely
we'll incorporate it into the base distribution.

Larry




Re: 'message contains bare newlines' - was Re: cyrus imapd 1.6.25 beta version

2000-12-15 Thread Ken Murchison



"David L. Parsley" wrote:
> 
> I've tried to dig through the archives a few times, but haven't found
> good info on the problems people were having with 'message contains bare
> newlines'.  I get several of these a week from the linux kernel mailing
> list.
> 
> Messages like this get abandoned in /var/spool/mqueue; i.e., 'mailq'
> doesn't list 'em, but 'ls /var/spool/mqueue' sure does!  Essentially, it
> seems like cyrus+sendmail just lets these messages drop on the floor -
> yech!
> 
> Any clue whether this behavior was fixed in .25beta?  I took a quick
> look at the code; nothing in the vicinity of the bare-newline check
> appeared to have changed.  So I just put in an (UGLY) little hack, which
> munges a bare newline to an 'X'.  I guess it would also be easy to make
> cyrus just ignore these, but I thought an X might stand out so I'd see
> where it's occuring.  (not yet)
> 
> I remember people saying bare newlines violated RFC's, but shouldn't
> cyrus be as lenient as possible in what it accepts, and as compliant as
> possible in what it sends/produces?

I didn't do anything, nor do I know of anything that was done regarding
bare newlines.  I'll defer to Larry on this one.

Ken
-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp



'message contains bare newlines' - was Re: cyrus imapd 1.6.25 beta version

2000-12-15 Thread David L. Parsley

I've tried to dig through the archives a few times, but haven't found
good info on the problems people were having with 'message contains bare
newlines'.  I get several of these a week from the linux kernel mailing
list.

Messages like this get abandoned in /var/spool/mqueue; i.e., 'mailq'
doesn't list 'em, but 'ls /var/spool/mqueue' sure does!  Essentially, it
seems like cyrus+sendmail just lets these messages drop on the floor -
yech!

Any clue whether this behavior was fixed in .25beta?  I took a quick
look at the code; nothing in the vicinity of the bare-newline check
appeared to have changed.  So I just put in an (UGLY) little hack, which
munges a bare newline to an 'X'.  I guess it would also be easy to make
cyrus just ignore these, but I thought an X might stand out so I'd see
where it's occuring.  (not yet)

I remember people saying bare newlines violated RFC's, but shouldn't
cyrus be as lenient as possible in what it accepts, and as compliant as
possible in what it sends/produces?

regards,
David

P.S. Thanks for all the work you guys are doing on cyrus - other than a
few glitches early on, it's been working real well here at the college.

Ken Murchison wrote:
> 
> John Holman wrote:
> >
> > > I've thrown a tarball containing cyrus imapd 1.6.25 at
> > >
> > > ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/BETA/cyrus-imapd-1.6.25.tar.gz
> > >
> > > If no one has any (serious) complaints in the next two days, I'll move
> > > this file up one level and announce it widely.
> >
> > I can't find any such announcement - what's the current status? Is there a
> > list of changes between this and 1.6.24?
> 
> Here's the list of changes that I *know* are in 1.6.25 because I checked
> them in myself.  What (if anything) else Larry might have put in, I
> don't know.  I'm now running 2.x, so I haven't looked at the 1.6 code in
> a while.  If you're *really* curious, just check CVS yourself.
> 
>- added tcl 8.2 to configure
>- 'const'-ified deliver/timsieved/test to match sieve prototypes
>- added 'singleinstancestore', 'sendmail', 'postmaster' and
>  'imapidresponse' imapd.conf options
>- added sendmail error strings
>- fixed sendmail child process bug (vacation, redirect, reject)
>- use empty return address for sieve actions which use sendmail
>- added in-reply-to header to vacation responses
>- changed auto-submitted header keyword to auto-replied
>  (matches upcoming sendmail 8.12)
>- fixed ending boundary for vacation MIME responses
>- more paranoid ID implementation
>- SEARCH HEADER fix (only searches header content)
>- mboxname fix (tjs's UTF-7 fix)
>- installsieve/timsieved disable script fixes
>- sieve fixes:
>* makefile fixes
>* subaddress fixes
>* vacation fixes
>* STOP fix
> 
> Ken
> --
> Kenneth Murchison Oceana Matrix Ltd.
> Software Engineer 21 Princeton Place
> 716-662-8973 x26  Orchard Park, NY 14127
> --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp

-- 
David L. Parsley
Network Administrator
Roanoke College