NEW: (2011-07-11) fix colors of
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
is 32 bits...
NEW: (2010-01-28) some colors to emphasize
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 ? ================= 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.
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).