Notes
Please note the following font definitions:
Incoming line from server
Outgoing line to server
Special

 •Authentication Types
When a client first logs on to a server it receives a similar response to below:

250-pioneer.host-serve.net
250-AUTH=LOGIN CRAM-MD5
250-AUTH LOGIN CRAM-MD5
250-PIPELINING
250 8BITMIME

The lines that we are interested in are the AUTH lines. Most servers do the AUTH and AUTH= line I assume that there was some disagreement in the RFC as to how this was supposed to be parsed so both lines are included. Other servers also put the AUTH commands on seperate lines so just be prepared to see anything. My server is telling me that it will accept LOGIN and CRAM-MD5 authentication methods. There are three main methods with the last being PLAIN which is what old servers ask for.

 •Inform the sever we wish to use AUTH
To let the server know that we want to use authentication we send the command:

AUTH ***

Where the *** is filled in with one of the servers available AUTH methods such as LOGIN.

 •PLAIN
First let us look at the PLAIN log in type. After we send the AUTH PLAIN command we receive the line:

334 Username:

We then send the username in plain text and we receive the next line:

334 Password:

We then send the password in plain text and if everything is correct we receive the line:

235 Go Ahead

If we sent the wrong user/pass combination we receive:

535 auth failure

As you can see the PLAIN method offers no protection from packet sniffers seeing your password.

 •LOGIN
This offers only slightly more protection from packet sniffing. To start we send the server the following line:

AUTH LOGIN

And we receive the line:

334 VXNlcm5hbWU6

Which Username: encoded in base64. We then send the server our username encoded in base64 and we receive the line:

334 UGFzc3dvcmQ6

Whic is Password: encoded in base64. We then send the server our password encoded in base64 and we receive the following line:

235 Go Ahead

If we sent a bad combination we receive the line:

535 auth failure

As you can see LOGIN only provides a mask of your username and password. However an intelligent person can still view the packets for this and unencode your username and password, or even just reuse it since the encoding never changes.

 •CRAM-MD5
This method provides real undecryptable authetication that changes with every login. To start this we tell the server:

AUTH CRAM-MD5

We then receive a similar line to the following:

334 PDIzODkxLjEwMTU5ODM0OTNAcGlvbmVlci5ob3N0LXNlcnZlLm5ldApaAj4=

If we decode base64 this line it should say:

<23891.1015983493@pioneer.host-serve.net>

(However my server has a glitch in its CRAM-MD5 authentication and it sends extra characters that mess up the authentication). We then respond with the following line:

ZGVtbyBlMDRjMDkyMDA5NzY3MWE3NmM3YzAyMzhkMjU2ZTdjMg==

If we base64 decode this line it says:

demo e04c0920097671a76c7c0238d256e7c2

We can see that it says demo which is my username and some junk after it. But what is this junk? The junk is the previous server ticket, that funny line that looks like an email address of numbers. Hashed and CRAM-MD5 encoded with my password. The server ticket changes every millisecond so my response never looks the same and the CRAM-MD5 cannot be undone. So how does the server verify me? It does the same process on its end and looks at the two responses, if they match you can enter. Basically your password changes every millisecond and only the server and you know how to create the new password each millisecond. If authentication works we get the following message:

235 Go Ahead

If we sent a bad combination we receive the line:

535 auth failure