bop:/users/cao/cedric/c/net>cat popit/README
What is this ?
==============
popit is just a little toy to view what's
in my pop3 account.
Why do I need it ? I hate big mail programs,
I don't need so much complexity. 'pine' is
nice, but for a pop3 account, I never could
use it (I must be some kind of asshole). So,
I used to use telnet, but I made a lot of
errors, and typing all the time "top" and
"dele" is boring, especially nowadays with
all those fucking spammers of my ass.
A little gtk stuff is nice, no ?
What does it give to me ?
=========================
You will see the 20 first lines of your
pop3 mails (the server has to understand
'top', which should not be a problem
nowadays). You can mark them for deletion,
and when you leave the program, they are
deleted from the server.
The mails are not interpreted, so it's
raw output. I don't like all those mail
agent flashing all around. telnet is ok,
but boring to use.
Also your password won't be sent in
clear over the network, by use of APOP
if available on your mail server. (You
will need to edit pop3.c and remove a few
lines if you want to force popit to work
in non-apop mode.)
How to use it ?
===============
First, give your login/password in the
first window, then you will see the
second window, with the messages. Select
a message in the left part of the window
to see the first 20 lines of it (and
see the header too). You can click on
the messages you want to mark for delete.
Quit with "OK" for deleting the marked
messages, "Cancel" to quit without delete
anything. Click "Save" and the current
message will be save in the current
directory (in the file m.XX).
Simple, huh ?
Where to get it ?
=================
http://sed.free.fr/popit
It is released in the public domain.

bop:/users/cao/cedric/c/net>cat popit/INSTALL
You should edit main.c and replace
'pop.free.fr' with your own pop3
server.
popit works with gtk+ 2.0, so you
need it.
Then do a "make", and put the
"popit" executable where you
want. You are done.
The program can work for Windows.
Ask if you can't build it. You will
need MinGW. Edit the Makefile and go.

bop:/users/cao/cedric/c/net>cat popit/NOISE
Sat May 24 17:32:09 MET DST 2003
Starting this little utility.
Sat May 24 21:09:00 MET DST 2003
POP3 code finished. Not tested yet, maybe buggy, but gcc compiles it.
Let's start gtk code.
Sat May 24 23:54:54 MET DST 2003
Initial screen finished. Must do the message list stuff.
Sun May 25 10:12:26 MET DST 2003
All seems to be done. 17 hours. Long and short. Will have
to test it in a real situation now. Let's kick some sleep.
Thu, 08 Jan 2009 10:35:11 +0100
Adding APOP mode. Hell, free.fr exists for more than ten years
and they don't provide cryptographic access to the mail system...
BUGS
====
MINOR BUGS .
All warnings and errors from the compiler are
considered minor bugs.
Warnings include things like using '=' instead
of '==' (found once), not #include'ing some
headers, and the like.
Errors include typo errors (I had a ')' in the
middle of nowhere), forgetting ')' in if constructs,
using a variable without declaring it before,
and the like.
Minor stuff.
BUG #0 .
I edited a file twice, saving here and there, thus
leading to a loss of code. Don't remember when. My
vi is too old, at school, vi says you edit twice,
here no.
BUG #1 .
in static int recv_line(popit *p)
again:
size = read(p->fd, buf, 4096);
if (ret <= 0)
return -SEE_ERRNO;
size gets the result of read, but I test ret.
This bug comes because I wanted a better handling
of errors, with a report to the user by a little
popup window, so I must handle error codes. "ret"
is used for this purpose. In this function "ret"
was previously where I know use "size", and I did
not change the code below. It's a semantical bug.
(It was present later in the code too, corrected
while correcting this first occurence.)
Found Sat May 24 23:31:15 MET DST 2003.
BUG #2 .
static int recv_line(popit *p)
was buggy, I wrongly handled "cr" and "lf" stuff.
I wanted to allow "cr", "lf", "cr lf" and "lf cr"
as end-of-line from the server, with possibly
a more than 4096 bytes input buffer, so the logic
was too tricky, I bugged it. Once again, semantical
bug.
Found Sat May 24 23:47:44 MET DST 2003.
BUG #3 .
in send_line
I put (10, 13) in the buffer before sending,
it should be (13, 10).
Bad knowledge of what means "cr" and "lf".
Found Sat May 24 23:53:19 MET DST 2003.
BUG #4 .
in action_toggle_row
sending ret instead of -ret when calling get_error_message.
Bad memory of the convention adopted only some hours ago.
This is the beginner's bug... never handled errors this
way...
Found Sun May 25 05:59:36 MET DST 2003.
BUG #5 .
recv_line was wrong logic. When I get a packet from the
socket, it is not said to end at the line boundary, as I
though, using this "feature" to test if the data was
correct. Had to create "read_socket" which handles its
own buffer, and gives data byte per byte to the out world.
This is a common error, what a shame to do it...
Found Sun May 25 06:18:27 MET DST 2003.
BUG #6 .
Not really a bug, but troubles with utf-8. gtk wants utf8
and I gave it iso-latin-1 stuff. Had to encode it, so adding
"read_raw_socket" and a "minibuf" to handle this. But then,
in action_toggle_row I gave f->data->mess[m].size instead
of "...].size - 1", so it included the ending 0, which
gtk did not like at all. So, all in all, it is a misunderstanding
bug I would say.
Found Sun May 25 07:11:05 MET DST 2003.
gave a wrong size to
BUG #7 .
Simply copied a g_signal_connect, but forgot to change
the parameter. It was 0, I waited "f", so it crashed
when the callback was called. I must be tired I guess.
I did not sleep this night.
Found Sun May 25 09:08:59 MET DST 2003.
BUG #8 .
The logic of recv_line was wrong. Now handling 'cr lf'
a more correct way. Well, I hope so...
BUG #9 .
Forgot a gtk_tree_path_free in interface.c:action_toggle_row.
Hell of me.
Found Thu, 08 Jan 2009 10:34:16 +0100.
BUG #10 .
Bad use of 'offset' in gtk_text_buffer_get_iter_at_offset. I used what
GTK+ calls 'index' so bad coloring for messages with characters out
of ASCII. Had to add some more logic and a global variable to get
rid of this one (check for 'char_count' in pop3.c). Dirty hack, but
this program is just that, so no big deal...
Found Mon, 01 Feb 2010 09:59:45 +0100.