You don't say what you think is wrong with c-client, so I have to guess.
I assume that you're complaining that c-client has no knowledge of local
newlines. That's quite by design. c-client is an API, not an application.
Its only concept of newline is the Internet standard CR/LF newline. It is up
to the application main program to worry about local newline handling. It has
no concept of any kind of local file I/O other than in the various mailbox
drivers; it cannot ``MIME attach a file'' without main program assistance.
In other words, when converting text -> base64, the application main program
is responsible for presenting CR/LF encoded data to c-client. When converting
base64 -> text, the application main program receives CR/LF encoded data from
c-client.
This is design, not a bug. This is expressly to encourage portability in main
programs, since the main program knows it will *ALWAYS* receive consistant
data from c-client no matter what platform it is running on. Pine running on
Unix (LF newlines) and DOS (CR/LF newlines) deals in identical strings.
Now, you may argue that the strcrlfcpy() function in the osdep file is
knowledge of a local newline, but that function has only one purpose; to
assist the local file drivers in transmogrifying file data into Internet
standard. If people make an issue out of it, I'll delete the function and
wire in that method directly into the Unix file drivers. I had some hope,
someday, of perhaps making the Unix file drivers run on other operating
systems -- but not at the cost of getting bogged down in this issue.
Or, you may drag in the issue of hard vs. soft newline. The answer to this is
that on most platforms the distinction is useless. There is no way on UNIX to
represent an Internet file in a completely reversible form, unless you
actually use the Internet representation. Similar arguments apply to the
concept of file records. If you care about preserving the bytes of the data
and distinguishing between CR, CR/LF, LF, and newline, you're going to have to
treat the data as binary since text does not provide a non-damagaging
transfer.