Subject: POP3 daemon truncates messages

From: Gunther Anderson <[email-masked]>
Date: Wed, 19 Oct 1994 16:17:52 GMT

One of my users just noticed that the POP3 daemon (which is the only one
anyone here is using) that comes with the IMAP package in Pine truncates
the last few characters off the end of a message.  This isn't so bad by
itself, but if the last few characters happens to be the "\n}\n" at the
end of a shell script or something, it makes for somebody's extra work.  I
pulled my old 3.90 code out of someone else's closet, and demonstrated the
problem exists there, too. 

I don't quite know where to look in the ipop3d.c source, but I think 
there might be troubles in blat().  Anyone ever seen and/or treated this 
malady?  I am using MMDF mailboxes on a SCO 3.2.4.2 system, so maybe 
there's another weirdness with the four ^A's at the beginning of the 
message or somesuch nonsense.

No - wait a second, here's the code, right in blat():

  puts ("\015");                /* output newline instead of last 2 chars */
  return ++ret;

Anyone want to tell me why?  I'm going to pull it myself right now, but 
I'd like to know what I'm breaking when I do.

Gunther Anderson

---

From: Mark Crispin <[email-masked]>
Date: Wed, 19 Oct 1994 20:41:58 -0700

Not so fast!!

The code in ipop3d is that way because the POP3 protocol insists that a 
message must be an integral number of *lines*.  The code ensures that the 
last two bytes are CR LF.  If the last two bytes are anything else, then 
the POP3 client will not see the end of session marker and the session 
will *hang*.  If a CR LF is added, then the byte count (required by 
the POP3 protocol) will be incorrect *and* you'll have an extra newline 
in returned messages in the normal case.

Note that by the time the text gets to blat(), newlines are normalized to 
the CR LF format.

It is theoretically possible in the Tenex and MTX formats for messages to
be a non-integral number of lines; that is, for a message to end with
something other than a newline.  Normally, this does not happen.

It should be impossible in the MMDF format for a message to be a 
non-integral number of lines.  If this is happening, then something is 
wrong with the message size calculation in MMDF format.

In other words, the bug is in the mmdf driver, *NOT* in ipop3d.  Please 
send me a sample message which demonstrates this problem as a Pine 
attachment, and I will fix the bug.