View Full Version : Socket-level POP3

Sir Penguin
05-04-2004, 06:51:44
I'm trying to write a program that will check my email account and alert me if I have new mail. I've known how to talk to a POP3 server for a long time, and I'm pretty comfortable with the basic commands (user, pass, list, retr, etc.). I can check my email through telnet.

So I make a socket to the email server over port 110, and tell the Python interactive prompt to run a thread that prints anything the POP3 server sends to me. It prints '+OK POP3 cascara.uvic.ca v2002.81 server ready\r\n', like it's supposed to.

I send "USER nrqm". It should be saying something about that user being in the system, but it doesn't (that's why I put the receive output into a thread, so that it didn't freeze).

Does anyone know if there's something extra I'm supposed to send, or what's going on?


Sir Penguin
05-04-2004, 06:53:11
I checked the source for fetchmail, and it sends just the regular command through a function called gen_transact. I couldn't find the full function definition, just the prototype in fetchmail.h or socket.h or something.


05-04-2004, 18:18:37
Yeah, that's the problem I ran into.

Sir Penguin
05-04-2004, 19:40:52
How did you solve it?


05-04-2004, 19:47:49
I believe by taking another swig of Thunderbird and crawling back into his stinking matted blankets in his box.

Sir Penguin
05-04-2004, 20:01:15
I don't have any Thunderbird. :(


06-04-2004, 00:30:00
I dunno. If there's no response coming back from the server (try looking at the modem lights or using something like KDE System Guard to monitor network connections), maybe it's on a MS system and wants a different kind of newline.

Sir Penguin
06-04-2004, 01:27:17
Oh my God, I can't believe I forgot the newlines. :bash:

Thanks. :)


06-04-2004, 15:48:46

Sir Penguin
06-04-2004, 18:41:19
\r\n on some Windows servers.


06-04-2004, 22:41:34
Socket level pop3? You pervert.

06-04-2004, 22:44:29
Gob level Thunderbird, or socket level Pop ? Decisions decisions...

09-04-2004, 10:45:39
Is there any danger of this thread being translated into English from Geek?

09-04-2004, 11:14:44
Doesn't need to be, perfectly understandable. :D

10-04-2004, 07:38:57

15-04-2004, 04:04:08
Penguin, Own Goal. that should be \l\r or \r\l. \n = \l\r

Sir Penguin
15-04-2004, 04:17:09
Own goal in return. Are you sure you know C? The newline, \n is the same character as the linefeed (I assume that's what \l means). It's ASCII 10, and means that the cursor moves to the next line. The \r, or carriage return, character returns the cursor to the first column in the line. Windows uses \n\r (or \r\n maybe) because it makes historical sense in terms of the keyboard's typewriter roots. UNIX uses just \n because it's intuitive and makes dealing with binary files easier. Some compilers and interpreters (for example, Python's) translate a \n literal in the source into \n\r on Windows machines.


15-04-2004, 04:29:38
Completely Le Wrong, SP.

\l means line.
\r means carriage return.

\n = 13, not 10. It is expanded when going to disk as \l\r in classic stream text modes.

\l = Line. It instructs teletypes to advance the paper one line.
\r = Carriage Return. It instructs teletypes to return the printer head to the zero position.

To reach a new line for normal printing, it took the combined output of \l\r.

\n = New Line

It was added after some period of time. It is always expanded into \l\r when you are talking following conventions.

\n\r = New line, carriage return. Once expanded, it means:
\l\r\r = Line Feed, Carriage return, carriage return.

This works, but is a waste of a \r. the \n does this.

If you did \l\n, you'd get \l\l\r, and that would result in going down 2 lines.

You just failed basic CS, Sir Penguin. Perhaps you can make up for it later on? I bet you can.

Now, any compilers and interpreters that us \n\r are pieces of shit, and should be avoided at all cost. If they cannot follow standards (check out any commercial documentation, such as at MSDN on \n, how it expands when dumped to file streams, and how file streams get their \l\r (10-14) turned into \n (13)... it's an important point that 1 character turns to 2 when dealing with your own buffers and such.

Most text, not just UNIX, uses \n. It's just easier on the programmers. But in older UNIX file systems, you need to translate all \n to \l\r or some of the system apps will have problems and print out garbage, instead of doing an actual newline. You won't see such a system, unless you end up working for the government somewhere. ;)

Sir Penguin
15-04-2004, 04:58:23
Dec: 10
Hex: A
Oct: 012
Char: LF (NL line feed, new line)

Dec: 13
Hex: D
Oct: 015
Char: CR (carriage return)

If \n is equivalent to \l\r, how come \n is a single character in C?


15-04-2004, 05:26:58
Because the programmers decided to make a standard character for \l\r since that was what they used whenever they wanted a new line.

Check this link out:


10 = LF
13 = CR

That's ASCII... you know, ANSI Standard Characters.

As I said, the original coders created \n to do the job of all those \l\r. But they retained \l and \r as there were reasons to use them seperately in the future, as well as maintain backward capability.

You can try it out for yourself, Penguin. Do a printout of \l\r and compare the results to \n.

If you want to examine the behavior, output a few \t\t first so you can see where the cursor ends up.

Try: "\t\tHello World\l\rHello World Again\nGood bye world!"

That will result in:

Hello World
Hello World Again
Good bye world!

Then play around with the the results.

A string of "\t\tHello World\lHello World Again\nGood bye world!"

for instance, results in:

Hello World
Hello World Again
Good bye world!

If \n = \l, then you should have gotten:

Hello World
Hello World Again
Good bye world!

But you won't.

Do some reading on text file mode versus binary file mode. In Text File mode, all \n's are translated to \l\r going to disk and all \l\rs are translated to \n's coming from disk.

It's standard ANSI C, not some special vendor convention.

Sir Penguin
15-04-2004, 05:49:30
OK, first off your link and my link both say that character 14 is Shift-Out. Your table doesn't even have NL anywhere, it just has LF and CR.

Secondly, I compiled the following code in Visual Studio 2003 Pro:
#include <stdio.h>

int main()
char line[100];
printf("\t\tHello World\l\rHello World Again\nGood bye world!");
return 0;
It printed the following text:
Hello World Againello Worldl
Good bye world!
This means that your '\l\r' "character" printed an l and returned the cursor to the beginning of the line, whereas your '\n' character moved the cursor down a line and to column 0.

The task list had one line, and it said, "c:\Documents and Settings\nrqm\My Documents\Visual Studio Projects\test2\test.c(6): warning C4129: 'l' : unrecognized character escape sequence". Clearly, standard ANSI C doesn't understand the \l escape.


15-04-2004, 06:23:18
I'll check it tomorrow at work. I think you are just totally screwed, as I've had to fix too many buffer overruns from idiots that didn't understand that \n gets translated to the \l\r in ANSI C when using certain file modes.

Sir Penguin
15-04-2004, 06:55:53
You mean like writing to a binary file opened in ASCII mode in Windows? The function fopen("filename","w"); transforms writes of \n into \n\r in Windows (I assume; that's how it works in Python). The function fopen("filename,"wb"); doesn't transform, it just writes 00001010. It could be that reads from a file opened as "r" instead of "rb" do a similar conversion.


15-04-2004, 07:12:43
Yeah. But I don't remember it being \newline\return . I remember it being \linefeed\return translated to \newline. There's an actual replacement of 2 characters to 1 when going from disk to display and 1 to 2 when going from display to disk.

Like I said, I'll check it out at work tomorrow.

16-04-2004, 05:23:40
Well, I checked it out. Seems I was wrong. Sorry about that Penguin.

When I get a chance, I'm going to go digging through my old source code and see what the hell I was thinking about. But I won't get a good chance to do that until at least Wednesday, if not later. Got a Monday deadline for coding, Tuesday deadline for testing/debuging a new set of enhancements. And Wednesday, we roll it all out to production. Bleah. It freakin takes 2 weeks to properly TEST the section we are touching, but the lead wants it out and done, so as to "enchant" the last release and fix the holes in his last "enchantment".

See what happens when people get bored and in a hurry to be done with a project? They just don't bother doing the job right.

Sir Penguin
16-04-2004, 05:32:12
What would happen if you hadn't written your code to specifications? ;)


16-04-2004, 05:37:23
He'd have gotten fired. I'd have been promoted to lead on the project.

Real World, SP.

Of course, I don't want to be lead on that project. Too much damn paper work and holding management's hand. And with the new contract, our paper-work demands have just increased by at least 500% (and they are expected to continue to climb as "we get into full step". :( )

16-04-2004, 21:59:14
Hm. I thought that the linefeed was the standard UNIX newline.

Sir Penguin
16-04-2004, 22:04:08
It is! But linefeed and newline are the same thing!


17-04-2004, 04:10:20
Oh. Okay. This is why somebody should just invent the perfect platform and a perfect charset to go with it. :)