NEW: (2011-07-11) fix colors of From: and Subject: lines, the foreground was left to default which is almost invisible with white-on-black color schemes.

NEW: (2010-05-11) a new button Full to get the full message directly in the window.

NEW: (2010-03-17) works on 64 bits computers. It was not my fault! the MD5 code I use was thinking that unsigned long is 32 bits...

NEW: (2010-01-28) some colors to emphasize From: and Subject: lines (first occurence only, should be in the header).

Oh, and you can download full emails, but that was already present in the previous version. Just forgot to announce it...

NEW: (2009-01-23) does APOP, so you don't send the password in clear over the network. (You must edit pop3.c if you want popit to work in non-APOP mode.)

bop:/users/cao/cedric/c/net>ls -al
total 25
drwxr-xr-x    3 cedric   games         512 May 26 16:34 .
drwxr-xr-x   16 cedric   games         512 May 26 12:31 ..
-rw-r--r--    1 cedric   games        1238 May 26 16:31 login.png
-rw-r--r--    1 cedric   games       10122 May 26 16:30 main_window.png
drwxr-xr-x    2 cedric   games         512 May 26 16:33 popit
-rw-r--r--    1 sed      sed         17790 2011-07-11 16:15 popit.tar.gz

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 ?


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

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...


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)
  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
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
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.


Creation time: Mon, 26 May 2003 16:39:51 +0200
Last update: Mon, 11 Jul 2011 16:16:18 +0200

Powered by a human brain, best viewed with your eyes (or your fingers if you are blind).