SlideShare a Scribd company logo
1 of 45
Download to read offline
The Windows Socket
          Programming Tutorial
Welcome to the Windows socket programming tutorial. Here you'll find out how to program your own
internet applications. The guide assumes no prior knowledge of programming with Windows Sockets,
although you need a working knowledge of C. The tutorial starts off very simple and will eventually build up
to an advanced level so you can understand how to program your own code for hacking applications.

Please feel free to report any bugs, typos etc. There was one that crept into the pop client in part two of the
tutorial,       but        this       has        been       fixed         (cheers        Bone          Digger).

There's also the potential for a buffer overflow in the program (cheers mnemonix). I haven't bothered to fix
that as there are lots of areas in all the programs which need better error trapping (virtually non-existent on
purpose to keep the code easier to follow and understand). I will be putting a fully debugged and error
trapped program example in the final part of the tutorial to show how to develop all of the frameworks
illustrated into robust code. As this is going to be a custom firewall, it will need it ;)

I've had quite a few requests for C tutorials since I started this guide. There are plenty of beginners tutorials
out on the web. I've downloaded and reviewed quite a few rather than write my own. If you haven't used C
before, I would recommend the following guide :-

Coronado Enterprises C Tutor version 2

This is an excellent beginners guide and covers virtually everything you will need to know to understand the
socket programming tutorial. It's also freeware. I've included it on the menu under downloads. File size is
192kB. I did not write the C tutorial, but if you have any questions about it, I'd be more than happy to answer
them                      as                      I'm                    recommending                        it.

If you don't have a C compiler for windows, you can download the Windows port of the Linux GCC
compiler package. You will also need the RSXNTDJ package to allow you to program apps for Windows.
Both of these packages (along with many other useful tools) are freely available from
http://www.delorie.com

Part One of the Socket tutorial describes in more detail what you will need and how to set up the compiler.


                                                                                                The Rota
Internet Programming with Windows - A Tutorial

                                   Part 1

               By Gandalf Gandalf@dhamma.org.uk (c) Feb 2000




Contents

Introduction
What You Will Need
Compiler Comments
The Internet
Protocols
The Windows TCP/IP Stack
Our First Program Using TCP/IP - WHOIS.C
Conclusion and What’s Next




Introduction

I decided to write this tutorial mainly as a means of getting my head
around programming Internet applications under the Microsoft Windows
OS. This is a topic that is not always easy to understand. There are
many web sites, references and books on the subject, but it takes a
lot of hard work to plough through them all to sift the good stuff
from the junk.

Let me say one thing from the start. I don't like Windows, never have
and I suspect I never will. I've been a Unix and Linux user (Minix
before Linux came out) now for longer than I care to remember. Linux
is probably the best and easiest OS to use for developing Internet
applications. There are lots of applications and programs available
freely for Linux, most with freely available source code. Whenever
I've wanted to develop a specific tool under Linux, I've done what
probably most Linux users do...download pieces of code and patch in
whatever else is needed to perform the required task. It’s pretty easy
to do without necessarily understanding the underlying principles.
Yeah, things go wrong, but a bit of tweaking usually gets you there in
the end.

So why did I decide to do this under Windows?

Good question.

I started to use Windows more and more since Win95 came out as my
profession called for me to keep up with understanding Windows as well
as Unix. When I found myself having to develop Windows applications, I
immediately started using Visual Basic so I could code easily rather
than have to learn Windows programming with C++. I've been a C
programmer for about 15 years, but mainly on Unix. I've never used C++
much before, and until recently, I thought it was a pre-requisite for
programming under Windows (fool I hear you say).
The main problem I've got with programming under Windows is that most
freely available source code is written to use the GUI. It always
seems that 90% of the code goes towards "making things pretty" etc. To
a non-Windows guru, this can be very daunting, as it's almost
impossible for a person not used to C++ to decipher what the hell is
going on.

It came to head recently when I wanted to write an application to
allow me to retrieve multiple emails from multiple POP servers into
one big email spool. I wanted to be able to be read the spool via a
single mail editor, and have the editor fill my reply email headers
automatically.

So I decided to get to grips with both C programming for Windows and
also accessing the functions within the winsock.dll. After that, I
decided to dig deeper and delve into coding direct without using the
Winsock dll.

Anyway, enough of the ramble. This tutorial should grow on a weekly
basis (it'll take me a week or so to write each section as I decipher
my own notes I wrote whilst exploring this) and will cover Internet
programming using mainly C routines for Windows.

The plan is to start simply by accessing the Winsock dll for all
initial programs. At each stage, a brief explanation and useful
working source code will be presented to explain various concepts. All
programs have been written as command line programs. No GUI, so the
code is easier to understand.

The tutorial will build up to a much more advanced level, resulting in
the development of a complete new Winsock dll with a lot more callable
routines that the hacker and phreaker will like!

Some assembly language programming will be required for later stages
of the tutorial, but I'll be releasing these routines as a dll for
anyone who doesn't want to learn assembly, but still wants to access
the routines.

All of the way through the tutorial, explanations of the underlying
concepts of internet programming will hopefully be built up to an
advanced level. For example, from the outset various Internet
protocols will be described very briefly. Further on in the tutorial,
each of the protocols will be explored to a byte level.




What You Will Need

A basic understanding of C.
A C compiler for windows.
Suitable Windows libraries (mainly Winsock and ICMP).
Windows 95/98 or NT.
The desire to learn.

For those who have never programmed in C before (and I'm not talking
about for windows), then you will need to download one of the many C
programmers tutorials/guides/references that are freely available on
the net. Ignore any that are windows related, as I will be including a
brief chapter on using C to program Windows apps. If you can
understand Basic or any other programming language, C shouldn't be
much of a problem.

C compilers are available free for download. For learning basic C then
I would recommend Borland's TurboC. They have released version 1 (I
believe) for free download, although it won't be suitable for Windows
apps.

I use the free GCC package with RSXNTDJ (also free) for developing
Windows apps. These are downloadable from www.delorie.com. The main
reason I use this is that it is a port of the Linux GCC package, so
I'm familiar with it.

Alternatively, you can buy, beg, steal or borrow a commercial copy of
whatever compiler you want.

Windows libraries can be downloaded from Microsoft’s SDK pages
(although I couldn't find a one for ICMP). For the GCC package you
don't even need the libraries as you can convert the equivalent dll's
into .a libraries using the makelib tool supplied.

All the routines presented in this tutorial have been tested under NT4
Service Pack 5. I make no guarantees they will work with other win32
OS's although they should. If you run into problems, then email me and
I'll try to come up with a solution.




Compiler Comments

Unfortunately I will have to restrict comments in this section to the
use of GCCW32 and RSXNTDJ as I don’t have access to any other win 32
compilers. If anyone wants to give feedback on using other compilers,
then please email me and I’ll include it in the updates (along with
your email address so you can get the why doesn’t this work questions)

With these packages, you can’t use the standard Lib’s that come with
the Microsoft SDK, however there is a MAKELIB utility program that can
convert MS DLL’s into a .a library.

According to the specs, the header files included with RSXNTDJ state
that WINSOCK is supported up to and including version 2.0, however, I
could not get programs to compile with NT4.0 SP5’s wsock32.dll after I
converted it using MAKELIB. You can set up RSXNTDJ and GCCW32 to use
the MS SDK headers, but as the SDK is a hefty download I have not
tried this. I will eventually get round to trying it and will update
this section.

Until then, I am using an older version of Winsock that was left under
my system32 directory after an update and had been renamed as
wsock32n.dll. This appears to be version 1.1, but works OK.

You will need to convert both wsock32n.dll and icmp.dll into .a
libraries using the MAKELIB utility.

Unfortunately, the help file that comes with RSXNTDJ is wrong, so
here’s the protocol:-
Copy wsock32.dll and icmp.dll into your rsxntdj/lib directory, then
from a command prompt type the following: -

makelib wsock32n.dll –o libwsock.a

And also: -

makelib icmp.dll –o libicmp.a

In your makefile for gccw32, reference these as –lwsock and –licmp

E.g. for the first program that we will compile (whois.c), the
makefile looks like this: -

PROJECT = whois
OBJS = whois.o
LIBS = -lwsock
include ....rsxntmak.gnu

(Make sure the path for rsxntmak.gnu is correct for your system)




The Internet

I thought a very brief introduction to the Internet and some basic
terminology might be a good idea to jog people’s memory on certain
points, and maybe clear up a few misconceptions. This is general, the
following sections will relate specifically as to how Windows handles
Internet access. It all starts very basic, but by the end of the
tutorial it will get pretty hairy.

There are billions of computers connected to the Internet, some via
dial up when needed, and others, which have a permanent "live"
connection.

To connect to the computer you want to talk to, you need some way of
identifying this computer. It will have a unique "name" and also an IP
address, which is a 32-bit number.

The "name" will never change unless the user decides to connect to the
internet via a different dial up account, but the IP address may do,
especially for most dial up ISP’s

"Names" are specified by a convention called DNS, which stands for
Domain Name Service. RFC’s 1032, 1033, 1034 and 1035 cover DNS for
those who want to delve deeper.

OK ... let’s take a practical example.

Let’s take my account I use to post to PHUK as an example.

The unique "name" is gandalf.freeuk.com

The IP number changes every time I dial up the account.

So how are these all related?
We’ll start with the name. A DNS name has the following format: -

subdomain.subdomain.domain

There can be many of the subdomain bits. In my case, com is the
domain, freeuk is a subdomain and gandalf is the subdomain within
freeuk.

The IP Address

We will discuss the IP protocol later on in this section, but for now,
it is sufficient to say that IP stands for Internet Protocol and the
IP address is the basis for identifying all computers on the internet
(and indeed often on private networks). An IP address consists of four
octets that define a unique address e.g. 176.116.32.6

When I connect to freeuk.com and successfully login, their server
assigns an IP address to my computer. This is different every time I
login. It is a dynamic IP address, i.e. it only relates to my computer
for the duration of my connection to the Internet.

Some ISP’s issue static IP’s, where even if you aren’t connected the
same IP address is reserved for your computer.

The handling of DNS name and equivalent IP address is done by the
ISP’s Nameservers.

Part Two of the tutorial will dig deeper into IP address classes and
subnets etc.




Protocols

There are quite a few protocols that need to be understood to get to
grips with writing your own Internet applications. For this part of
the tutorial, we don’t need to know the protocols in depth. But I’ll
briefly describe some of them here. Part Two of the tutorial will
discuss all the protocols to a byte by byte level for those who really
want to know how things work.

PPP

When you use dial up networking to connect to your ISP, Windows uses
the PPP protocol to talk to the ISP’s computer. PPP stands for Point
to Point Protocol. It handles negotiation of baud rates etc and also
gets an IP address from the ISP.

IP

The Internet Protocol is responsible for transporting data packets
across the Internet and is primarily used by the routers to give them
enough information to get the data packets to their destination.
Sometimes IP may fragment data into smaller chunks, where each chunk
may arrive at the destination in any order and by different network
routes. It is the responsibility of IP to reassemble everything back
into the correct order.
TCP

IP by itself is not a very reliable protocol as it sends info out and
doesn’t ever check to see if it gets to the destination. This is
usually the job for TCP, which stands for Transmission Control
Protocol. Any Internet application that requires reliable data
transfer (e.g. HTTP, POP, SMTP etc) uses TCP to handshake the data
transfer. TCP runs on top of IP

UDP

UDP is also a transmission protocol called the User Datagram Protocol.
Unlike TCP it doesn’t use handshaking, so it is much faster but not as
reliable. It is often used for streaming audio or video over the
Internet. Like TCP, UDP runs on top of IP

ICMP

ICMP stands for Internet Control Message Protocol. It is closely
related to IP (in fact it is usually encapsulated within the IP data
packets). It is used by programs such as PING etc to check if parts of
the Internet are up and running. It is not often used for much else
(from the Windows user perspective), but it is used extensively by all
of the routers on the Internet.

That’s all we’ll say about protocols at the moment until part two of
the tutorial. We’ll present a few programs at the end of this
tutorial, which will demonstrate the use of windows socket programming
using TCP/IP and also ICMP.




The Windows TCP/IP Stack

The Windows TCP/IP stack (the Winsock dll) takes all the hard work out
of programming Internet applications. It handles lower level access
for protocols such as TCP, UDP and IP. A separate dll (icmp.dll)
handles the ICMP protocol.

We will introduce all gently to programming via the various Windows
dll’s.

This just about reaches the end of the first part of the tutorial. Hey
says all, where’s the code and examples?

Okay, the first part of the tutorial (the download you are reading
now) is a basic introduction as to why I decided to write this
tutorial. It hopefully gives a basic explanation of various protocols
that will be explored in continuing parts of the tutorial. Without
these, people who want to learn from scratch will be out of their
depth.

So, I can’t leave this without giving a bit of code for all to try.

The following program provides a template for TCP/IP access using C.
Yes, if you want to do other things, you will have to understand the
relevant RFC’s and will also need to use a few more routines from the
Winsock dll.

What we have presented so far should give you a basic framework to
allow you to layout your own programs.

Don’t worry if you don’t want to, the second tutorial is all about
implementing routines from the Winsock dll. It has plenty of examples
covering TCP/UDP and ICMP.




Our First Program Using TCP/IP - WHOIS.C

Whois will be familiar to Linux users. If you want to find out
information about a certain DNS name, you can run a whois query to
find out information on network address numbers, administrative
contact details and valid name server’s etc. Official whois servers
exist all over the world. A couple of the most useful ones are
whois.internic.net (for com, net, org and edu domains) and
whois.nic.uk (for co.uk, org.uk, ltd.uk, net.uk etc).

The program accepts one or two command line arguments: -

Whois domainname whois.server and saves any query results to a file
called whoislog.txt.

So, for example, if I wanted to query whois.internic.net about
freeuk.com, I would use: -

Whois freeuk.com whois.internic.net

If the second argument is missing, the program automatically uses
whois.internic.net.

Here is the output for a query on freeuk.com: -

Whois Session Started Sat Feb 26 23:52:33 2000.

Connecting to whois.internic.net

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to
http://www.internic.net
for detailed information.

Domain Name: FREEUK.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: NS0.FREEUK.NET
Name Server: NS1.FREEUK.NET
Name Server: NS2.CLARA.NET
Updated Date: 15-sep-1999
>>> Last update of whois database: Sat, 26 Feb 00 02:54:30 EST <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.

So what happens if I want to query my own freeuk account:-

Whois gandalf.freeuk.com

Result:-

Whois Session Started Sun Feb 27 17:33:41 2000.

Connecting to whois.internic.net

Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to
http://www.internic.net
for detailed information.

No match for "GANDALF.FREEUK.COM".

>>> Last update of whois database: Sun, 27 Feb 00 02:36:32 EST <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.

So why didn’t it find my account?

Well Internic only handles registered domains and not subdomains. We
will find out in part two of the tutorial how to query freeuk to find
out details on subdomain accounts.

Anyway, here is the program listing. There is a download section at
the end of this tutorial with links to download the source, libraries,
makefile etc for this and all subsequent programs in this tutorial.

/*
 * whois.c
 *
 * (c) Feb 2000 by Gandalf
 *
 */

#include   <stdio.h>
#include   <stdlib.h>
#include   <time.h>
#include   <windows.h>
#include   <winsock.h>

#define WIN32_LEAN_AND_MEAN          /* define win 32 only */

void handle_error(void);             /* Error handler routine */
void write_file(char *buf);          /* Write details to log file */

int main (int argc, char **argv)
{
  WORD wVersionRequested;            /* socket dll version info */
WSADATA wsaData;                    /* data for socket lib
initialisation */
  SOCKET sock;                        /*   socket details */
  const int BUF_LEN=10000;            /*   Buffer size for transfers */
  struct sockaddr_in address;         /*   socket address stuff */
  struct hostent * host;              /*   host stuff */
  int err;                            /*   error trapping */
  float socklib_ver;                  /*   socket dll version */
  char File_Buf[BUF_LEN];             /*   file buffer */
  char DomainName[100];               /*   domain name from user */
  char HostName[100];                 /*   host name from user */
  time_t now;                         /*   for date and time */

  if (argc < 2)                    /* check we have command line
options */
  {
    printf("nUseage: whois domainname [whois.server]n");
    exit(0);
  }

     strcat(DomainName, argv[1]); /* get domain name from command line */
     strcat(DomainName, "rn"); /* add crlf as whois servers expect it
*/

     if (argc == 3)
       strcat(HostName, argv[2]); /* get host name from command line */
     else
       strcat(HostName, "whois.internic.net");

      wVersionRequested = MAKEWORD( 1, 1 );

      /*
       * We need to call the WSAStartup routine BEFORE we try to use any
of
       * the Winsock dll calls.
       */

      if ( WSAStartup( wVersionRequested, &wsaData ) != 0 )
        handle_error();

      /* Check socket DLL supports 1.1 or higher */

      socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0;
      socklib_ver += LOBYTE( wsaData.wVersion );

   if ( socklib_ver < 1.1 )
   {
     printf ("nError: socket library must support 1.1 or
greater.n");
     WSACleanup(); /* clean up before exit */
     exit(0);
   }

      /* write current date and time to log file and screen */

      time(&now);
      sprintf(File_Buf, "Whois Session Started %.24s.nn", ctime(&now));
      write_file(File_Buf);

     /*
      * Open a socket. The AF_INET parameter tells windows we want to use
the
    * internet. Other parameters for different networking can be chosen
e.g.
    * for netbios, IPX etc. The SOCK_STREAM parameter lets windows know
we want
    * to use TCP rather than UDP, and the final parameter will always
be
    * zero for what we want to do and tells windows to use whatever
    * default communication protocol has been established (eg PPP and
IP)
    */

      if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET )
        handle_error();

    /* We now need to initialise a couple of variables in the address
     * structure. Once again, to tell windows we are using the
internet,
     * and also what port we want to use when connecting to a remote
     * computer. In this case it is port 43 which is the standard port
for
     * whois. The htons routine is used to convert the way Intel chips
     * store data in memory, which is different compared to many other
computers.
     * The standard is based on Motorola format.
     */

      address.sin_family=AF_INET;       /* internet */
      address.sin_port = htons(43);     /* port 43 for whois */

      /* write to the log file and screen */

      sprintf(File_Buf,"Connecting to %sn", HostName);
      write_file(File_Buf);

      /*
       * host is a pointer to a structure of the predefined type hostent.
We
    * need to call gethostbyname with the DNS name we want to use to
return
    * a pointer to a hostent structure. This is so we can resolve an
IP
    * address from our ISP's nameserver.
    */

       if ( (host=gethostbyname(HostName)) == NULL )
         handle_error();

    /* we then initialise the address structure with the resolved IP
address */

       address.sin_addr.s_addr=*((unsigned long *) host->h_addr);

       /* Now we're ready to actually connect to the whois server itself
*/

    if ( (connect(sock,(struct sockaddr *) &address, sizeof(address)))
!= 0)
      handle_error();

       /*
* We should be connected to the whois server at this point
     * so we need to send the domain name and wait for the response.
The send
     * and recv routines are always used with TCP. These enable
handshaking
     * compared to the sendto and recvfrom routines which are used for
UDP
     * protocol, ie without handshaking.
     */

    strcpy(File_Buf, DomainName);
    err=send(sock,File_Buf,strlen(File_Buf),0); /* send domain name */
    err=recv(sock,File_Buf,BUF_LEN,0);          /* discard first
response */
    err=recv(sock,File_Buf,BUF_LEN,0);          /* get query results
back */
    write_file(File_Buf);

      /* Always call WSACleanup before exiting */

      WSACleanup(); /* clean up before exit */
      exit(0);
  }

  void handle_error(void)
  {
     /*
      * Errors are handled by calling the WSAGetLastError routine which
      * will return the last error as one of the following. As we
develop
      * this tutorial, we will go into much more detail on what they
mean
      * and what caused them.
      */

    switch ( WSAGetLastError() )
    {
      case WSANOTINITIALISED :
        printf("Unable to initialise socket.n");
      break;
      case WSAEAFNOSUPPORT :
        printf("The specified address family is not supported.n");
      break;
      case WSAEADDRNOTAVAIL :
        printf("Specified address is not available from the local
machine.n");
      break;
      case WSAECONNREFUSED :
        printf("The attempt to connect was forcefully rejected.n");
        break;
      case WSAEDESTADDRREQ :
        printf("address destination address is required.n");
      break;
      case WSAEFAULT :
        printf("The namelen argument is incorrect.n");
      break;
      case WSAEINVAL :
        printf("The socket is not already bound to an address.n");
      break;
      case WSAEISCONN :
        printf("The socket is already connected.n");
break;
      case WSAEADDRINUSE :
        printf("The specified address is already in use.n");
      break;
      case WSAEMFILE :
        printf("No more file descriptors are available.n");
      break;
      case WSAENOBUFS :
        printf("No buffer space available. The socket cannot be
created.n");
      break;
      case WSAEPROTONOSUPPORT :
        printf("The specified protocol is not supported.n");
        break;
      case WSAEPROTOTYPE :
        printf("The specified protocol is the wrong type for this
socket.n");
      break;
      case WSAENETUNREACH :
        printf("The network can't be reached from this host at this
time.n");
      break;
      case WSAENOTSOCK :
         printf("The descriptor is not a socket.n");
      break;
      case WSAETIMEDOUT :
        printf("Attempt timed out without establishing a
connection.n");
      break;
      case WSAESOCKTNOSUPPORT :
         printf("Socket type is not supported in this address
family.n");
      break;
      case WSAENETDOWN :
        printf("Network subsystem failure.n");
      break;
      case WSAHOST_NOT_FOUND :
        printf("Authoritative Answer Host not found.n");
      break;
      case WSATRY_AGAIN :
        printf("Non-Authoritative Host not found or SERVERFAIL.n");
       break;
      case WSANO_RECOVERY :
         printf("Non recoverable errors, FORMERR, REFUSED,
NOTIMP.n");
      break;
      case WSANO_DATA :
        printf("Valid name, no data record of requested type.n");
      break;
        case WSAEINPROGRESS :
        printf("address blocking Windows Sockets operation is in
progress.n");
      break;
      case WSAEINTR :
        printf("The (blocking) call was canceled via
WSACancelBlockingCall().n");
      break;
      default :
        printf("Unknown error.n");
       break;
  }
WSACleanup();
    exit(0);
}

void write_file(char *buf)
{
  /* writes results to a log file and also to the screen */

    FILE *fp=fopen("whoislog.txt","a+");
    fprintf(fp,"%sn",buf);
    fclose(fp);
    printf("%sn",buf);
}

So...that was our first program using TCP/IP. It is a basic template
for virtually any program you will want to do using TCP/IP. All you
need to do is change any of the relevant details such as domain name,
port, data to send depending on what type of server you are trying to
connect to. For example, if you wanted to connect to a POP server,
then you would change the domain name to the name of the POP server
(e.g. relay.freeuk.net). You would also change the port number to 110,
and once a valid connection has been established, change the send and
recv part of the program to negotiate collection of your email. For
virtually all recognised data transfer protocols such as POP/SMTP etc,
there is an RFC that covers the required send and receive string
formats. For POP it is RFC1725 and for SMTP it is RFC1869. These are
freely available on the web.


Conclusion and What’s Next

Okay...Nothing difficult so far.

We have discussed a few protocols, and we have introduced a simple
program that can be compiled and used under windows to do a domain
name enquiry.

The basic framework won’t change for the next tutorial.

Part Two of the tutorial will illustrate further programs that access
the Winsock dll. We will also introduce accessing the ICMP dll.

Anyway, enough for now. Check back in a couple of weeks for part two
of the tutorial.

Send any feedback, errors, typos and wants to gandalf@dhamma.org.uk.



                                                                     The Rota

                                                                BlueCrab Ltd
Internet Programming with Windows - A Tutorial

                                   Part 2

               By Gandalf Gandalf@dhamma.org.uk (c) Mar 2000




Contents

Disclaimer
Introduction
RFC's
Simple POP Email Client
Sending Emails by SMTP
Using UDP/IP
Conclusion and What's Next




Disclaimer

Some of the programs presented in this tutorial may be illegal to use
unless you have permission from the owner of the server you attempt to
connect to and also to the recipient of any email's you send. If in
doubt, don't do it. You can of course use these freely on your own
network if you own one. If you want to try anything out, then consider
setting up a Linux Box to act as a server so you can experiment in
peace without any fear of reprisal. Everything presented in this
tutorial should be treated as a theoretical discussion of what is
possible. The author will not be held responsible for actions of
anyone using material from this tutorial for illegal purposes.




Introduction

Hopefully we've all survived part one of the tutorial. Part two is
going to start off pretty much where part one left off. We will start
by putting together a more advanced program using TCP/IP that will
allow you to retrieve emails from a POP account into a mail spool
file. We will also develop a program to allow you to send emails via
smtp. This will include falsifying header information. The programs
are going to be fairly rudimentary, but will provide a nice framework
for those who would like to develop their own email client.




RFC's

I've mentioned RFC's briefly in part one of the tutorial. We are now
going to use information from various RFC's in some detail.

So what are RFC's ?
Every protocol that exists on the net, whether it's for handling mail,
news, web site access or anything else you care to consider, there is
an RFC for it.

RFC stands for Request for Comments, and the whole of the internet and
it's associated protocols are based on them. If you want to develop or
understand any Internet application, you need to read the associated
RFC's.

You can find a list of all RFC's used so far in this tutorial at

http://www.exegesis.org.uk/gandalf/winsock/rfc/index.htm

The RFC's themselves are also downloadable or readable from links on
the index page.

I will eventually be putting ALL rfc's online over a period of time,
with a search facility.

OK, on with the tutorial, let's start with a bit of programming.




Simple POP Email Client

Let's continue where we left off in the first part of the tutuorial by
developing another TCP/IP program. We will put together a basic
framework to allow you to connect to, and negotiate downloading POP
mail from your POP server. As usual, we will be presenting a piece of
code that is functional rather then exhaustively error trapped to make
it easier to understand. There are comments in the code to suggest
areas that would need to be changed if you wanted to develop a robust
POP client capable of handling attachments etc, but this will do to
get you started. Later parts of the tutorial will be using this code
to develop a full multiple POP account client with SMTP posting.

The program uses a log file called poplog.txt to store what's sent to
and received back from the pop server so you can check for errors etc.
It saves all mails to a text mail spool called mailbox.txt complete
with headers.

Here's the code:-

/*
 * popclnt1.c
 *
 *
 * A very basic pop client that retrieves mail from an account into
 * a multi pop retrieval client in later parts of the tutorial with
all
 * the extra error handling that's needed. Use this as a framework to
 * develop your own pop client. This program doesn't delete any mails
 * from the pop mail server, so you can try it out without being
afraid
 * of losing any emails!
 */

#include <stdio.h>
#include    <stdlib.h>
#include    <time.h>
#include    <windows.h>
#include    <winsock.h>

#define WIN32_LEAN_AND_MEAN

void handle_error(void);
void pop_error(void);
void write_file(int file, char *p);

int main (int argc, char *argv[])
{
  const long BUF_LEN=60000;

  /* 60000 char buffer. In real life we would have to allow for a much
   * larger buffer than this to allow retrieval of long messages which
   * might have attachments. We will be doing this in one of the later
   * parts of the tutorial by using synchronised data flow with a
smaller
   * buffer that downloads mails in smaller chunks.
   */

   const char POP_ERR_MSG[]="-ERR";            /* POP Server error
response */
   const int LOG_FILE=1;                       /*   write to log file */
   const int MAIL_FILE=2;                      /*   write to mail file */
   const int SCREEN=4;                         /*   display on screen */
   WORD wVersionRequested;                     /*   socket dll version info
*/
   WSADATA wsaData;                            /* socket lib
initialisation */
   SOCKET sock;                                /*   socket details */
   struct sockaddr_in address;                 /*   socket address stuff */
   struct hostent * host;                      /*   host stuff */
   int err;                                    /*   error trapping */
   float socklib_ver;                          /*   socket dll version */
   char * File_Buf;                            /*   file buffer */
   char * Rec_Buf;                             /*   recieve buffer */

     /* Fill in to suit your own account, increase array sizes if needed
*/

     char hostname[20] = "pop.wherever.net";   /* hostname for pop server
*/
     char username[20] = "username";           /* username */
     char password[20] = "password";           /* password */

  int i,j;                                     /* general counters */
  char tempbuf[20] = "";                       /* temp string buffer for
parsing */
  int num_flag=0;                              /* string parse flag */
  time_t now;                                  /* from time.h */

     /* allocate dynamic storage from the heap */

     File_Buf = malloc(BUF_LEN * sizeof(char) + 1);
     Rec_Buf = malloc(BUF_LEN * sizeof(char) + 1);

     wVersionRequested = MAKEWORD( 1, 1 );
if ( WSAStartup( wVersionRequested, &wsaData ) != 0 )
    handle_error();

  /* Check socket DLL supports 1.1 or higher */

  socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0;
  socklib_ver += LOBYTE( wsaData.wVersion );

  if ( socklib_ver   {
    printf ("Error: socket library must support 1.1 or greatern");
    WSACleanup();
    return 0;
  }

  /* get date and time to write to log file */

  time(&now);

  sprintf(File_Buf,"Pop Client Session started %.24s.nn",
ctime(&now));
  write_file(LOG_FILE | SCREEN, File_Buf);

  /* open a socket based on TCP/IP */

  if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET )
    handle_error();

  address.sin_family=AF_INET;                  /* internet */
  address.sin_port = htons(110);               /* pop port */

  sprintf(File_Buf,"Connecting to %sn", hostname);
  write_file(LOG_FILE | SCREEN, File_Buf);

  /* DNS on hostname */

  if ( (host=gethostbyname(hostname)) == NULL )
    handle_error();

  /* IP address for hostname */

  address.sin_addr.s_addr=*((unsigned long *) host->h_addr);

  /* try to connect to pop server */

  if ( (connect(sock,(struct sockaddr *) &address, sizeof(address)))
!= 0)
  handle_error();

  sprintf(File_Buf, "Connected to %sn", hostname);
  write_file(LOG_FILE | SCREEN, File_Buf);

  err=recv(sock,Rec_Buf,BUF_LEN,0);                /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);       /* should start +OK */
  write_file(LOG_FILE, File_Buf);

  if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL )       /* check for errors */
    pop_error();

  strcpy(Rec_Buf,"USER ");
  strcat(Rec_Buf, username);
strcat(Rec_Buf, "rn");
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);        /* send username */
     sprintf(File_Buf,"sent: %s",Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     err=recv(sock,Rec_Buf,BUF_LEN,0);                /* should recieve +OK
*/
     sprintf(File_Buf,"received: %s", Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL )       /* check for errors */
       pop_error();

     strcpy(Rec_Buf,"PASS ");
     strcat(Rec_Buf, password);
     strcat(Rec_Buf, "rn");
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);        /* send password */
     sprintf(File_Buf,"sent: %s",Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     err=recv(sock,Rec_Buf,BUF_LEN,0);                /* should recieve +OK
*/
     sprintf(File_Buf,"received: %s",Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL )       /* check for errors */
       pop_error();

     strcpy(Rec_Buf,"STATrn");                     /* send stat command */
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
     sprintf(File_Buf,"sent: %s", Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     /*
      * should recieve +OK x y where x = number of messages
      * and y is total octets. Note the buffers we have allocated
      * would not be sufficient for a real pop client. They
      * should be dynamically allocated here after checking the
      * size of the waiting emails.
      */

     err=recv(sock,Rec_Buf,BUF_LEN,0);
     sprintf(File_Buf,"received: %s", Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL )       /* check for errors */
       pop_error();

     /*
      * Now we need to work out how many emails we have to retrieve
      * and set up a loop to get them all.
      */

     i = j = 0;

  while (i   {
    if (Rec_Buf[i] > '0' && Rec_Buf[i]           {
      while (Rec_Buf[i] != ' ')                         /* space is end of
number */
      {
        tempbuf[j] = Rec_Buf[i];
j++;
                 i++;
             }

             num_flag=1;
             tempbuf[j] = '0';
         }

         i++;
     }

     i = atoi(tempbuf);                               /* number of emails */

     printf("There are %d message(s) waitingrn", i);

  /*
   * At this point we should really be checking the length of each
email
   * on the POP server and then either allocate dynamic memory, or
better
   * still, try synchronised access which we will be doing in a later
   * part of the tutorial. Until then, let's keep it simple. If you do
   * have an email larger than the buffer, it won't do anything else
   * other than crash the program!
   */

     for( j=1; j<=i; j++)
     {
       sprintf(Rec_Buf, "RETR %drn", j);          /* add number */
       printf("Retrieving message number %dn", j);
       err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
       sprintf(File_Buf,"sent: %s ",Rec_Buf);
       write_file(LOG_FILE, File_Buf);

    err=recv(sock,Rec_Buf,BUF_LEN,0);                 /* +OK message will
follow */
    sprintf(File_Buf,"received: %s ",Rec_Buf);
    write_file(LOG_FILE, File_Buf);

         if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL )   /* check for errors */
           pop_error();

         err=recv(sock,Rec_Buf,BUF_LEN,0);            /* retrieve the mail
*/
         sprintf(File_Buf,"%s",Rec_Buf);
         write_file(MAIL_FILE, File_Buf);
     }

     printf ("All donenn");

     /* send quit command then clean up */

     strcpy(Rec_Buf,"QUITrn");
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
     sprintf(File_Buf,"sent: %s", Rec_Buf);
     write_file(LOG_FILE, File_Buf);

     /* deallocate buffer memory */

     free(File_Buf);
     free(Rec_Buf);
WSACleanup();
    return 0;
}

void handle_error(void)
{
  /*
   * Errors are handled by calling the WSAGetLastError routine which
   * will return the last error as one of the following. As we develop
   * this tutorial, we will go into much more detail on what they mean
   * and what caused them.
   */

  switch ( WSAGetLastError() )
  {
    case WSANOTINITIALISED :
      printf("Unable to initialise socket.n");
    break;
    case WSAEAFNOSUPPORT :
      printf("The specified address family is not supported.n");
    break;
    case WSAEADDRNOTAVAIL :
      printf("Specified address is not available from the local
machine.n");
    break;
    case WSAECONNREFUSED :
      printf("The attempt to connect was forcefully rejected.n");
      break;
    case WSAEDESTADDRREQ :
      printf("address destination address is required.n");
    break;
    case WSAEFAULT :
      printf("The namelen argument is incorrect.n");
    break;
    case WSAEINVAL :
      printf("The socket is not already bound to an address.n");
    break;
    case WSAEISCONN :
      printf("The socket is already connected.n");
    break;
    case WSAEADDRINUSE :
      printf("The specified address is already in use.n");
    break;
    case WSAEMFILE :
      printf("No more file descriptors are available.n");
    break;
    case WSAENOBUFS :
      printf("No buffer space available. The socket cannot be
created.n");
    break;
    case WSAEPROTONOSUPPORT :
      printf("The specified protocol is not supported.n");
      break;
    case WSAEPROTOTYPE :
      printf("The specified protocol is the wrong type for this
socket.n");
    break;
    case WSAENETUNREACH :
      printf("The network can't be reached from this host at this
time.n");
break;
    case WSAENOTSOCK :
       printf("The descriptor is not a socket.n");
    break;
    case WSAETIMEDOUT :
      printf("Attempt timed out without establishing a
connection.n");
    break;
    case WSAESOCKTNOSUPPORT :
       printf("Socket type is not supported in this address
family.n");
    break;
    case WSAENETDOWN :
      printf("Network subsystem failure.n");
    break;
    case WSAHOST_NOT_FOUND :
      printf("Authoritative Answer Host not found.n");
    break;
    case WSATRY_AGAIN :
      printf("Non-Authoritative Host not found or SERVERFAIL.n");
     break;
    case WSANO_RECOVERY :
       printf("Non recoverable errors, FORMERR, REFUSED, NOTIMP.n");
    break;
    case WSANO_DATA :
      printf("Valid name, no data record of requested type.n");
    break;
      case WSAEINPROGRESS :
      printf("address blocking Windows Sockets operation is in
progress.n");
    break;
    case WSAEINTR :
      printf("The (blocking) call was canceled via
WSACancelBlockingCall().n");
    break;
    default :
      printf("Unknown error.n");
     break;
  }

    WSACleanup();
    exit(0);
}

void pop_error(void)
{
  printf("POP Error, Check the Log File for Detailsrnrn");

    WSACleanup();
    exit(0);
}

void write_file(int file_type, char *p)
{
   const int LOG_FILE=1;                        /* write to log file
*/
   const int MAIL_FILE=2;                       /* write to mail file
*/
   const int SCREEN=4;                          /* display on screen
*/
if( (file_type & LOG_FILE) != 0 )           /* add to logs */
    {
      FILE *fp=fopen("poplog.txt","a+");
      fprintf(fp,"%sn",p);
      fclose(fp);
    }

    if( (file_type & MAIL_FILE) != 0 )          /* add to mailbox */
    {
      FILE *fp=fopen("mailbox.txt","a+");
      fprintf(fp,"%sn",p);
      fclose(fp);
    }

    if ( (file_type & SCREEN) != 0 )            /* screen */
    {
      printf("%sn",p);
    }
}




Log File Example after connecting to a POP Server:-

Pop Client Session started Tue Mar 28 22:27:06 2000.

Connecting to pop.freeuk.net

Connected to pop.freeuk.net

received: +OK CPOP v2.3 Ready for Action

sent: USER xxxxxxxx

received: +OK

xxxxxxxx

sent: PASS xxxxxxxx

received: +OK

xxxxxxxx

sent: STAT

received: +OK 1 7165

sent: RETR 1

received: +OK

1

sent: QUIT



Sending Email's with SMTP
Now that we've seen how to retrieve emails from a POP server, we'll
take a look at how to send them with SMTP. Once again using TCP/IP. As
for the POP client, the program is a basic framework for you to
develop further. This will be our last TCP/IP example for a while.
Hopefully, the three programs we have presented so far will allow you
to develop your own TCP/IP applications by reading the relevant RFC's
to allow you to establish and use the required protocol.

Most email programs available for windows won't allow you to modify
certain headers and often put in additional header fields you might
not want to use. With this program, you can set up the "From:" field
if you don't want your real email address to be seen. It is
theoretically possible to use it to log onto SMTP servers where you
don't have an account and send emails from their server. Many SMTP
servers do not check user details, although a large number of UK ISP's
do check you are using one of their Dial Up Accounts before letting
you use SMTP to protect themselves from email spammers. You might of
course be logged in their log files if you aren't careful!

Anyway, let's take an example. The following program sends an email to
whoever has been specified in the RCPT TO: field, in this case, it
comes to my account. However, when I recieve it it will appear to have
come from Bill Clinton and should have been sent to President Putin.

Here's the source:-

/*
 * smtp1.c
 *
 * (c) Mar 2000 by Gandalf
 *
 * A very basic smtp program to send emails from a text file. Try it
out by
 * sending an email to one of your mail accounts. Make your own email
headers
 * up with this, or add a few that maybe your current email program
doesn't
 * allow. This example will send an email to whoever you specify in
the RCPT TO
 * field, but will appear to be intended for someone else, and of
course it
 * will also appear to come from someone different to yourself!
 * This is a technique often used by spammers. I don't agree with
spamming,
 * but the technique can be useful for other purposes.
 */

#include   <stdio.h>
#include   <stdlib.h>
#include   <time.h>
#include   <windows.h>
#include   <winsock.h>

#define WIN32_LEAN_AND_MEAN

void handle_error(void);
void smtp_error(void);
void write_file(int file, char *p);

int main (int argc, char *argv[])
{
     const int BUF_LEN=5000;                  /* send and recieve buffers
*/
     const int LOG_FILE=1;                    /* write to log file */
     const int SCREEN=4;                      /* display on screen */

     WORD wVersionRequested;                  /* socket dll version info */
     WSADATA wsaData;                         /* socket lib initialisation
*/
     SOCKET sock;                             /*   socket details */
     struct sockaddr_in address;              /*   socket address stuff */
     struct hostent * host;                   /*   host stuff */
     int err;                                 /*   error trapping */
     float socklib_ver;                       /*   socket dll version */
     char * File_Buf;                         /*   file buffer */
     char * Rec_Buf;                          /*   recieve buffer */

     /* Change to use your own smtp host */

     char hostname[20] = "relay.where.net"; /* hostname for smtp server
*/

     time_t now;                              /* from time.h */

     /* allocate dynamic storage from the heap */

     File_Buf = malloc(BUF_LEN * sizeof(char) + 1);
     Rec_Buf = malloc(BUF_LEN * sizeof(char) + 1);

     wVersionRequested = MAKEWORD( 1, 1 );

     if ( WSAStartup( wVersionRequested, &wsaData ) != 0 )
       handle_error();

     /* Check socket DLL supports 1.1 or higher */

     socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0;
     socklib_ver += LOBYTE( wsaData.wVersion );

     if ( socklib_ver   {
       printf ("Error: socket library must support 1.1 or greatern");
       WSACleanup();
       return 0;
     }

     /* get date and time to write to log file */

     time(&now);
     sprintf(File_Buf,"SMTP Session started %.24s.nn", ctime(&now));
     write_file(LOG_FILE | SCREEN, File_Buf);

     /* open a socket based on TCP/IP */

     if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET )
       handle_error();

     address.sin_family=AF_INET;                   /* internet */
     address.sin_port = htons(25);                 /* smtp port */

     sprintf(File_Buf,"Connecting to %sn", hostname);
     write_file(LOG_FILE | SCREEN, File_Buf);
/* DNS on hostname */

     if ( (host=gethostbyname(hostname)) == NULL )
       handle_error();

     /* IP address for hostname */

     address.sin_addr.s_addr=*((unsigned long *) host->h_addr);

     /* Connect to smtp server */

  if ( (connect(sock,(struct sockaddr *) &address, sizeof(address)))
!= 0)
    handle_error();

     sprintf(File_Buf, "Connected to %sn", hostname);
     write_file(LOG_FILE | SCREEN, File_Buf);

  err=recv(sock,Rec_Buf,BUF_LEN,0);                  /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);         /* write to logs */
  write_file(LOG_FILE | SCREEN, File_Buf);

     /*
      * OK, now we send the usual expected string to the smtp host. This
      * should be "HELO whatever.wewant.comrn" Some smtp hosts check
      * the domain out properly, but most don't. As long as it checks a
      * rudimentary test to see if it could be a valid domain, the smtp
      * host will usually accept it!
      */

  sprintf(Rec_Buf, "HELO microsoft.comrn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);          /* send expected
response */
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  err=recv(sock,Rec_Buf,BUF_LEN,0);                  /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);         /* write to logs */
  write_file(LOG_FILE | SCREEN, File_Buf);

     sprintf(Rec_Buf, "MAIL FROM: bclinton@whitehouse.govrn");
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);     /* send who it's from
*/
     write_file(LOG_FILE | SCREEN, Rec_Buf);

  err=recv(sock,Rec_Buf,BUF_LEN,0);                  /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);         /* write to logs */
  write_file(LOG_FILE | SCREEN, File_Buf);

  sprintf(Rec_Buf, "RCPT TO: gandalf@dhamma.org.ukrn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);     /* send who it's to.
This is */
  write_file(LOG_FILE | SCREEN, Rec_Buf);       /* the last required
field */

  err=recv(sock,Rec_Buf,BUF_LEN,0);                  /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);         /* write to logs */
write_file(LOG_FILE | SCREEN, File_Buf);

  sprintf(Rec_Buf, "DATArn");                 /* Send a DATA command
which */
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);     /* tells the server
that all */
  write_file(LOG_FILE | SCREEN, Rec_Buf);       /* else we send is
going to
                                                    * be our message with
headers
                                                    * and the mesaage
body.
                                                    */

  err=recv(sock,Rec_Buf,BUF_LEN,0);             /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);    /* write to logs */
  write_file(LOG_FILE | SCREEN, File_Buf);

  /*
    * OK. At this point we can add as many headers as we want. Check
out
    * the RFC's for all common headers
    */

  sprintf(Rec_Buf, "From: Bill Clinton
<bclinton@whitehouse.gov>rn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  sprintf(Rec_Buf, "To: Putin <putin@kremlin.ru>rn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  sprintf(Rec_Buf, "Subject: Congratulationsrn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  /* Done with headers, so let's add the message body */

  sprintf(Rec_Buf, "rnDear President Putinrn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  sprintf(Rec_Buf, "rnCongratulations on your recent appointment ");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  sprintf(Rec_Buf, "to President of Russiarn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  sprintf(Rec_Buf, "rnI remain, your most faithful serventrn");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  sprintf(Rec_Buf, "rnBill");
  err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
  write_file(LOG_FILE | SCREEN, Rec_Buf);

  /*
* Once we have finished, we send a CRLF followed by a full stop and
   * a second CRLF to tell the smtp host we have completed the
message, which
   * will then get queued and sent.
   */

     sprintf(Rec_Buf, "rn.rn");
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);
     write_file(LOG_FILE | SCREEN, Rec_Buf);

  err=recv(sock,Rec_Buf,BUF_LEN,0);              /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);     /* write to logs */
  write_file(LOG_FILE | SCREEN, File_Buf);

     sprintf(Rec_Buf, "QUITrn");
     err=send(sock,Rec_Buf,strlen(Rec_Buf),0);   /* send a quit command
*/
  write_file(LOG_FILE | SCREEN, Rec_Buf);
  err=recv(sock,Rec_Buf,BUF_LEN,0);              /* get response from
server */
  sprintf(File_Buf,"received: %s", Rec_Buf);     /* write to logs */
  write_file(LOG_FILE | SCREEN, File_Buf);

  /*
   * Off course, if you wanted to use this as a genuine email posting
   * program, you would use the mail spool file we generated from our
   * last program, and would pick up the relevent headers to reply.
   * The message could be edited using a standard text editor, then
read
   * in by this program. We've kept it simple though so you can see
exactly
   * what is happening.
   */

     /* deallocate buffer memory */

     free(File_Buf);
     free(Rec_Buf);

     WSACleanup();
     return 0;
}

void handle_error(void)
{
  /* Cut and paste in the same error handler as used in the POP
program */
}

void smtp_error(void)
{
  printf("SMTP Error, Check the Log File for Detailsrnrn");

     WSACleanup();
     exit(0);
}

void write_file(int file_type, char *p)
{
  const int LOG_FILE=1;                          /* write to log file
*/
     const int SCREEN=4;                         /* display on screen
*/

     if( (file_type & LOG_FILE) != 0 )           /* add to logs */
     {
       FILE *fp=fopen("poplog.txt","a+");
       fprintf(fp,"%sn",p);
       fclose(fp);
     }

     if ( (file_type & SCREEN) != 0 )            /* screen */
     {
       printf("%sn",p);
     }
}

Okay, let's take a look at the log file (smtplog.txt):-

SMTP Session started Wed Mar 29 00:35:41 2000.

Connecting to relay.freeuk.net

Connected to relay.freeuk.net

received: 220 scrabble.freeuk.net ESMTP Exim 3.12 #1 Wed, 29 Mar 2000
00:34:12 +0100

HELO whitehouse.gov

received: 250 scrabble.freeuk.net Hello whitehouse.gov
[212.126.154.153]

34:12 +0100

MAIL FROM: bclinton@whitehouse.gov

received: 250 <bclinton@whitehouse.gov> is syntactically correct

154.153]

34:12 +0100

RCPT TO: gandalf@dhamma.org.uk

received: 250 <gandalf@dhamma.org.uk> is syntactically correct

154.153]

34:12 +0100

DATA

received: 354 Enter message, ending with "." on a line by itself

.153]

34:12 +0100

From: Bill Clinton <bclinton@whitehouse.gov>
To: Putin <putin@kremlin.ru>

Subject: Congratulations

Dear President Putin

Congratulations on your recent appointment

to President of Russia


I remain, your most faithful servent


Bill

.

received: 250 OK id=12a5Uy-0004ku-00

ul servent

QUIT

received: 221 scrabble.freeuk.net closing connection




Using UDP/IP

So far we've looked at using TCP/IP, which as I mentioned in part one
of the tutorial, is a STREAMING protocol, ie it uses handshaking. You
send data and it is acknowledged by the other end prior to you sending
more. This way, if packets get lost or become corrupted, the other end
can notify you to resend the packet. We're now going to take a look at
UDP/IP which is a DATAGRAM protocol. You send out a packet and never
bother to check if it gets to it's destination. Obviously this is a
less reliable protocol, but is much faster. There aren't too many
services running over the Internet using UDP. However, we'll develop
an example to illustrate how to use it. I did have in mind using TFTP
as an example, but we need to understand the UDP protocol in depth to
be able to use this. So, we'll take a simple one. You probably won't
find a server out there on the Internet which offer's an echo service,
but if you have a Linux Box, then enable port 7 in inetd.conf to try
this out.

All it does is send a string via UDP/IP and receives an echo of the
same string back from the server. Here's the code :-

/*
 * ech.c
 *
 * (c) Mar 2000 by Gandalf
 *
 * A simple program to illustrate UDP/IP. Server's don't usually
 * run an echo service as it can be used for DoS attacks. However,
 * if you have access to a Linux Box, you can enable this service
 * in your inetd.conf to try it.
 *
 */
#include    <stdio.h>
#include    <stdlib.h>
#include    <windows.h>
#include    <winsock.h>

#define WIN32_LEAN_AND_MEAN

void handle_error(void);

int main (int argc, char **argv)
{
  WORD wVersionRequested;                /* socket dll version info */
  WSADATA wsaData;                       /* data for socket lib
initialisation */
  SOCKET sock;                           /*   socket details */
  const int BUF_LEN=100;                 /*   Buffer size for transfers */
  struct sockaddr_in address;            /*   socket address stuff */
  int err;                               /*   error trapping */
  float socklib_ver;                     /*   socket dll version */
  char * Buf;                            /*   send buffer */
  char * Rec_Buf;                        /*   receive buffer */

     wVersionRequested = MAKEWORD( 1, 1 );

     /*
      * We need to call the WSAStartup routine BEFORE we try to use any
of
      * the Winsock dll calls.
      */

     if ( WSAStartup( wVersionRequested, &wsaData ) != 0 )
       handle_error();

     /* Check socket DLL supports 1.1 or higher */

     socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0;
     socklib_ver += LOBYTE( wsaData.wVersion );

  /* Find out what our maximum IP packet size is for datagrams and
allocate
   * our buffers
   */

     Buf = malloc(wsaData.iMaxUdpDg * sizeof(char) + 1);
     Rec_Buf = malloc(wsaData.iMaxUdpDg * sizeof(char) + 1);

     if ( socklib_ver   {
       printf ("nError: socket library must support 1.1 or greater.n");
       WSACleanup();    /* clean up before exit */
       exit(0);
     }

  /*
    * Open a socket. The AF_INET parameter tells windows we want to use
the
    * internet. Other parameters for different networking can be chosen
e.g.
    * for netbios, IPX etc. The SOCK_DGRAM parameter lets windows know
we want
    * to use UDP rather than TCP, and the final parameter will always
be
      * zero for what we want to do and tells windows to use whatever
      * default communication protocol has been established (eg PPP and
IP)
      */

     if ( (sock = socket(AF_INET, SOCK_DGRAM, 0)) == INVALID_SOCKET )
       handle_error();

  /* We now need to initialise a couple of variables in the address
    * structure. Once again, to tell windows we are using the internet,
    * and also what port we want to use when connecting to a remote
    * computer. In this case it is port 7 which is the standard port
for
    * echo. The htons routine is used to convert the way Intel chips
    * store data in memory, which is different compared to many other
computers.
    * The standard is based on Motorola format.
    */

     address.sin_family=AF_INET;            /* internet */
     address.sin_port = htons(7);           /* port 7 for the echo server
*/

  /*
   * The last example showed using a host name, and used the winsock
   * dll routine gethostbyname to resolve an IP address. This example
   * shows how to use an IP address direct using the inet_addr
routine.
   */

     address.sin_addr.s_addr=inet_addr("192.168.19.3");

     /* Now we're ready to actually connect to the echo server itself */

  if ( (connect(sock,(struct sockaddr *) &address, sizeof(address)))
!= 0)
    handle_error();

  /*
   * We should be connected to the echo server at this point and
whatever
   * we send to it should be echoed back. We use sendto and recvfrom
with
   * UDP/IP.
   */

  strcpy(Buf, "Hi There Mr Echo!");
  printf("nSent: %sn", Buf);
  err=sendto(sock,Buf,BUF_LEN,0,(struct sockaddr
*)&address,sizeof(address));
  err=sizeof(address);
  recvfrom(sock,Rec_Buf,BUF_LEN,0,(struct sockaddr *)&address,&err);
  printf("nReceived: %sn", Rec_Buf);

     /* deallocate buffer memory */

     free(Buf);
     free(Rec_Buf);

     /* Always call WSACleanup before exiting */
WSACleanup();
    exit(0);
}

void handle_error(void)
{
  /* Cut and paste in the same error handler as used in the POP
program */
}




Conclusion and What's Next

So, we are moving a bit closer towards programming our own hacking
applications. We hopefully fully understand TCP/IP and UDP/IP by now,
or at least enough to write our own programs.

I fully intended to introduce ICMP at this point with our own versions
of PING and TRACEROUTE. However, after developing them, I realised
that for the reader of this tutorial to understand how they work would
require a greater knowledge of the IP protocol, so we'll be leaving
these examples until part three of the tutorial.

We will be looking at the IP protocol in depth in the next part of the
tutorial. In fact, we will be taking a very deep look at all of the
protocols. It's going to be pretty heavy going as we can't really go
much further without getting into protocols to a bit level. So get
prepared.

As usual, we will be presenting a few programs to illustrate this. We
will be developing a logging program to watch out for TCP, UDP and
ICMP activity on your own computer. We will also expand this further
to allow us to monitor the protocols to the bit level.

It will eventually grow into a powerful firewall by the end of the
tutorial.

Hope you're enjoying things so far!

As usual, send any greets, complaints or whatever to
gandalf@dhamma.org.uk

                                                                  The Rota

                                                             BlueCrab Ltd
RFC's Used in the Tutorial

Here's the list of RFC's I used whilst developing the Windows Socket Programming
Tutorial. If you really want to get to grips with programming your own Internet
applications, you should read them fully. RFC's discuss internet related protocols in
great                                                                          detail.

View them online by left clicking the link, or download them by right clicking the link.
They are all in text format. The RFC's listed here account for about 5% of all available
RFC's. I will eventually be putting the lot online here, along with a document level
search facility, something which is sadly missing from most RFC repositories.
RFC
         RFC Title, Author, Date and General Information
Number

         NIC name server - a datagram-based information utility. J.R. Pickens, E.J. Feinler, J.E. Mathis.
756      Jul-01-1979.
         (Format: TXT=23491 bytes) (Status: UNKNOWN)

         User Datagram Protocol. J. Postel. Aug-28-1980.
768
         (Format: TXT=5896 bytes) (Status: STANDARD)

         User Datagram Protocol. J. Postel. Aug-28-1980.
768
         (Format: TXT=5896 bytes) (Status: STANDARD)

         Vulnerabilities of network control protocols: An example. E.C. Rosen. Jul-01-1981.
789
         (Format: TXT=25541 bytes) (Status: UNKNOWN)

         Internet Protocol. J. Postel. Sep-01-1981.
791
         (Format: TXT=97779 bytes) (Obsoletes RFC0760) (Status: STANDARD)

         Internet Control Message Protocol. J. Postel. Sep-01-1981.
792      (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950) (Status:
         STANDARD)

         Transmission Control Protocol. J. Postel. Sep-01-1981.
793
         (Format: TXT=177957 bytes) (Status: STANDARD)

         Simple Mail Transfer Protocol. J. Postel. Aug-01-1982.
821
         (Format: TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status: STANDARD)

         TCP maximum segment size and related topics. J. Postel. Nov-01-1983.
879
         (Format: TXT=22024 bytes) (Status: UNKNOWN)

         Domain names plan and schedule. J. Postel. Nov-01-1983.
881
         (Format: TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN)

         Standard for the transmission of IP datagrams over Ethernet networks. C. Hornig. Apr-01-1984.
894
         (Format: TXT=5697 bytes) (Status: STANDARD)

         Standard for the transmission of IP datagrams over experimental Ethernet networks. J. Postel.
895      Apr-01-1984.
         (Format: TXT=4985 bytes) (Status: STANDARD)

         Congestion control in IP/TCP internetworks. J. Nagle. Jan-06-1984.
896
         (Format: TXT=26782 bytes) (Status: UNKNOWN)
Domain name system implementation schedule. J. Postel. Feb-01-1984.
897
       (Format: TXT=15683 bytes) (Updates RFC0881) (Updated by RFC0921) (Status: UNKNOWN)

       Broadcasting Internet Datagrams. J.C. Mogul. Oct-01-1984.
919
       (Format: TXT=16382 bytes) (Status: STANDARD)

       Domain name system implementation schedule - revised. J. Postel. Oct-01-1984.
921
       (Format: TXT=23318 bytes) (Updates RFC0897) (Status: UNKNOWN)

       Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. Oct-01-1984.
922
       (Format: TXT=24147 bytes) (Status: STANDARD)

       Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. Aug-01-1985.
950
       (Format: TXT=37985 bytes) (Updates RFC0792) (Status: STANDARD)

       NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985.
954
       (Format: TXT=7397 bytes) (Obsoletes RFC0812, RFC0813) (Status: DRAFT STANDARD)

       Some problems with the specification of the Military Standard Internet Protocol. D.P. Sidhu.
963    Nov-01-1985.
       (Format: TXT=44019 bytes) (Status: UNKNOWN)

       Some problems with the specification of the Military Standard Transmission Control Protocol.
964    D.P. Sidhu. Nov-01-1985.
       (Format: TXT=20972 bytes) (Status: UNKNOWN)

       Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods.
       NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities
1001
       Board, End-to-End Services Task Force. Mar-01-1987.
       (Format: TXT=158437 bytes) (Status: STANDARD)

       Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications.
       NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities
1002
       Board, End-to-End Services Task Force. Mar-01-1987.
       (Format: TXT=170262 bytes) (Status: STANDARD)

       ISO transport services on top of the TCP: Version 3. M.T. Rose, D.E. Cass. May-01-1987.
1006
       (Format: TXT=31935 bytes) (Obsoletes RFC0983) (Status: STANDARD)

       TCP and IP bake off. J. Postel. Sep-01-1987.
1025
       (Format: TXT=11648 bytes) (Status: UNKNOWN)

       Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987.
       (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by
1035
       RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181,
       RFC2136, RFC2137, RFC2308) (Status: STANDARD)
Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network
1069   Protocol. R.W. Callon, H.W. Braun. Feb-01-1989.
       (Format: TXT=24268 bytes) (Obsoletes RFC0986) (Status: UNKNOWN)

       ISO presentation services on top of TCP/IP based internets. M.T. Rose. Dec-01-1988.
1085
       (Format: TXT=64643 bytes) (Status: UNKNOWN)

       Standard for the transmission of IP datagrams over NetBIOS networks. L.J. McLaughlin. Feb-01-
1088   1989.
       (Format: TXT=5749 bytes) (Status: STANDARD)

       DNS encoding of network names and other types. P.V. Mockapetris. Apr-01-1989.
1101
       (Format: TXT=28677 bytes) (Updates RFC1034, RFC1035) (Status: UNKNOWN)

       Host extensions for IP multicasting. S.E. Deering. Aug-01-1989.
1112   (Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Status:
       STANDARD)

       Administrative Domains and Routing Domains: A model for routing in the Internet. S. Hares, D.
1136   Katz. Dec-01-1989.
       (Format: TXT=22158 bytes) (Status: INFORMATIONAL)

       Compressing TCP/IP headers for low-speed serial links. V. Jacobson. Feb-01-1990.
1144
       (Format: TXT=120959, PS=534729 bytes) (Status: PROPOSED STANDARD)

       Structure and identification of management information for TCP/IP-based internets. M.T. Rose,
1155   K. McCloghrie. May-01-1990.
       (Format: TXT=40927 bytes) (Obsoletes RFC1065) (Also STD0016) (Status: STANDARD)

       TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991.
1180
       (Format: TXT=65494 bytes) (Status: INFORMATIONAL)

       New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. Oct-01-
1183   1990.
       (Format: TXT=23788 bytes) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL)

       Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990.
1191
       (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT STANDARD)

       Use of OSI IS-IS for routing in TCP/IP and dual environments. R.W. Callon. Dec-01-1990.
1195
       (Format: TXT=187866, PS=362052 bytes) (Status: PROPOSED STANDARD)

       Management Information Base for Network Management of TCP/IP-based internets:MIB-II. K.
       McCloghrie, M.T. Rose. Mar-01-1991.
1213
       (Format: TXT=146080 bytes) (Obsoletes RFC1158) (Updated by RFC2011, RFC2012,
       RFC2013) (Status: STANDARD)
OSI connectionless transport services on top of UDP: Version 1. C. Shue, W. Haggerty, K.
1240   Dobbins. Jun-01-1991.
       (Format: TXT=18140 bytes) (Status: PROPOSED STANDARD)

       ICMP Router Discovery Messages. S. Deering. Sep-01-1991.
1256
       (Format: TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD)

       Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet:
       Goals, Experimental Design, Implementation, and Policy Considerations. M.F. Schwartz. Nov-
1273
       01-1991.
       (Format: TXT=19949 bytes) (Status: INFORMATIONAL)

       A Unified Approach to Inter-Domain Routing. D. Estrin, Y. Rekhter, S. Hotz. May 1992.
1322
       (Format: TXT=96934 bytes) (Status: INFORMATIONAL)

       TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992.
1323   (Format: TXT=84558 bytes) (Obsoletes RFC1072, RFC1185) (Status: PROPOSED
       STANDARD)

       The PPP Internet Protocol Control Protocol (IPCP). G. McGregor. May 1992.
1332
       (Format: TXT=17613 bytes) (Obsoletes 1172) (Status: PROPOSED STANDARD)

       DNS NSAP RRs. B. Manning. July 1992.
1348   (Format: TXT=6871 bytes) (Obsoleted by RFC1637) (Updates RFC1034, RFC1035) (Updated by
       RFC1637) (Status: EXPERIMENTAL)

       THE TFTP PROTOCOL (REVISION 2). K. Sollins. July 1992.
       (Format: TXT=24599 bytes) (Obsoletes RFC0784) (Updates RFC1350, RFC1783) (Updated by
1350
       RFC1782, RFC1783, RFC1784, RFC1350, RFC1785, RFC2347, RFC2348, RFC2349) (Also
       STD0033) (Status: STANDARD)

       An IP Address Extension Proposal. K. Siyan. September 1992.
1365
       (Format: TXT=12790 bytes) (Status: INFORMATIONAL)

       Choosing a Common IGP for the IP Internet. P. Gross. October 1992.
1371
       (Format: TXT=18168 bytes) (Status: INFORMATIONAL)

       Suggestion for New Classes of IP Addresses. P. Robinson. October 1992.
1375
       (Format: TXT=16990 bytes) (Status: INFORMATIONAL)

       The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. November 1992.
1377
       (Format: TXT=22109 bytes) (Status: PROPOSED STANDARD)

       An Experiment in DNS Based IP Routing. C. Huitema. December 1992.
1383
       (Format: TXT=32680 bytes) (Status: EXPERIMENTAL)
Traceroute Using an IP Option. G. Malkin. January 1993.
1393
       (Format: TXT=13140 bytes) (Status: EXPERIMENTAL)

       Correspondence between the IAB and DISA on the use of DNS. Internet Architecture Board.
1401   January 1993.
       (Format: TXT=12528 bytes) (Status: INFORMATIONAL)

       Guidelines for Management of IP Address Space. E. Gerich. May 1993.
1466
       (Format: TXT=22262 bytes) (Obsoletes RFC1366) (Status: INFORMATIONAL)

       The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point
1473   Protocol. F. Kastenholz. June 1993.
       (Format: TXT=20484 bytes) (Status: PROPOSED STANDARD)

       A Security Problem and Proposed Correction With Widely Deployed DNS Software. E. Gavron.
1535   October 1993.
       (Format: TXT=9722 bytes) (Status: INFORMATIONAL)

       Common DNS Implementation Errors and Suggested Fixes. A. Kumar, J. Postel, C. Neuman, P.
1536   Danzig & S. Miller. October 1993.
       (Format: TXT=25476 bytes) (Status: INFORMATIONAL)

       The PPP Internetworking Packet Exchange Control Protocol (IPXCP). W. Simpson. December
1552   1993.
       (Format: TXT=29173 bytes) (Status: PROPOSED STANDARD)

       PPP LCP Extensions. W. Simpson. January 1994.
1570
       (Format: TXT=35719 bytes) (Updates RFC1548) (Status: PROPOSED STANDARD)

       Domain Name System Structure and Delegation. J. Postel. March 1994.
1591
       (Format: TXT=16481 bytes) (Status: INFORMATIONAL)

       DNS Server MIB Extensions. R. Austein & J. Saperia. May 1994.
1611
       (Format: TXT=58700 bytes) (Status: PROPOSED STANDARD)

       DNS Resolver MIB Extensions. R. Austein & J. Saperia. May 1994.
1612
       (Format: TXT=61382 bytes) (Status: PROPOSED STANDARD)

       PPP Bridging Control Protocol (BCP). F. Baker & R. Bowen. June 1994.
1638
       (Format: TXT=58477 bytes) (Obsoletes RFC1220) (Status: PROPOSED STANDARD)

       The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994.
1661   (Format: TXT=103026 bytes) (Obsoletes RFC1548) (Updated by RFC2153) (Also STD0051)
       (Status: STANDARD)

1663   PPP Reliable Transmission. D. Rand. July 1994.
(Format: TXT=17281 bytes) (Status: PROPOSED STANDARD)

       ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994.
1700
       (Format: TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status: STANDARD)

       DNS NSAP Resource Records. B. Manning & R. Colella. October 1994.
1706
       (Format: TXT=19721 bytes) (Obsoletes RFC1637) (Status: INFORMATIONAL)

       DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner & D. Baldoni.
1712   November 1994.
       (Format: TXT=13237 bytes) (Status: EXPERIMENTAL)

       Tools for DNS debugging. A. Romao. November 1994.
1713
       (Format: TXT=33500 bytes) (Also FYI0027) (Status: INFORMATIONAL)

       Post Office Protocol - Version 3. J. Myers & M. Rose. November 1994.
1725   (Format: TXT=35058 bytes) (Obsoletes RFC1460) (Obsoleted by RFC1939, STD0053) (Status:
       DRAFT STANDARD)

       POP3 AUTHentication command. J. Myers. December 1994.
1734
       (Format: TXT=8499 bytes) (Status: PROPOSED STANDARD)

       IPv4 Option for Sender Directed Multi-Destination Delivery. C. Graff. March 1995.
1770
       (Format: TXT=11606 bytes) (Status: INFORMATIONAL)

       TFTP Option Negotiation Analysis. G. Malkin & A. Harkin. March 1995.
1785
       (Format: TXT=3354 bytes) (Updates RFC1350) (Status: INFORMATIONAL)

       Representation of IP Routing Policies in a Routing Registry (ripe-81++). T. Bates, E. Gerich, L.
1786   Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, & J. Yu. March 1995.
       (Format: TXT=133643 bytes) (Status: INFORMATIONAL)

       ICMP Domain Name Messages. W. Simpson. April 1995.
1788
       (Format: TXT=11722 bytes) (Status: EXPERIMENTAL)

       DNS Support for Load Balancing. T. Brisco. April 1995.
1794
       (Format: TXT=15494 bytes) (Status: INFORMATIONAL)

       Requirements for IP Version 4 Routers. F. Baker. June 1995.
1812   (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Status: PROPOSED
       STANDARD)

       IP Authentication Header. R. Atkinson. August 1995.
1826
       (Format: TXT=27583 bytes) (Status: PROPOSED STANDARD)

1827   IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995.
(Format: TXT=30278 bytes) (Status: PROPOSED STANDARD)

       IP Authentication using Keyed MD5. P. Metzger & W. Simpson. August 1995.
1828
       (Format: TXT=9800 bytes) (Status: PROPOSED STANDARD)

       Whois and Network Information Lookup Service, Whois++. J. Gargano & K. Weiss. August
1834   1995.
       (Format: TXT=14429 bytes) (Status: INFORMATIONAL)

       Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. Faltstrom & C. Weider.
1835   August 1995.
       (Format: TXT=80581 bytes) (Status: PROPOSED STANDARD)

       Security Considerations for IP Fragment Filtering. G. Ziemba, D. Reed & P. Traina. October
1858   1995.
       (Format: TXT=20468 bytes) (Status: INFORMATIONAL)

       SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud & D. Crocker. November
1869   1995.
       (Format: TXT=23299 bytes) (Obsoletes RFC1651) (Also STD0010) (Status: STANDARD)

       SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, & K. Moore.
1870   November 1995.
       (Format: TXT=18226 bytes) (Obsoletes RFC1653) (Also STD0010) (Status: STANDARD)

       A Means for Expressing Location Information in the Domain Name System. C. Davis, P. Vixie,
1876   T. Goodwin & I. Dickinson. January 1996.
       (Format: TXT=29631 bytes) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL)

       Variable Length Subnet Table For IPv4. T. Pummill & B. Manning. December 1995.
1878
       (Format: TXT=19414 bytes) (Obsoletes RFC1860) (Status: INFORMATIONAL)

       SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996.
1891
       (Format: TXT=65192 bytes) (Status: PROPOSED STANDARD)

       Common DNS Operational and Configuration Errors. D. Barr. February 1996.
1912
       (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status: INFORMATIONAL)

       Architecture of the Whois++ Index Service. C. Weider, J. Fullton & S. Spero. February 1996.
1913
       (Format: TXT=33743 bytes) (Status: PROPOSED STANDARD)

       How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz & C. Weider. February 1996.
1914
       (Format: TXT=17842 bytes) (Status: PROPOSED STANDARD)

       Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol. F.
1915
       Kastenholz. February 1996.
(Format: TXT=14347 bytes) (Also BCP0003) (Status: BEST CURRENT PRACTICE)

       Post Office Protocol - Version 3. J. Myers & M. Rose. May 1996.
1939   (Format: TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957) (Also STD0053)
       (Status: STANDARD)

       Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June
1957   1996.
       (Format: TXT=2325 bytes) (Updates RFC1939) (Status: INFORMATIONAL)

       The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996.
1968
       (Format: TXT=20781 bytes) (Status: PROPOSED STANDARD)

       Serial Number Arithmetic. R. Elz & R. Bush. August 1996.
1982
       (Format: TXT=14440 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD)

       PPP Link Quality Monitoring. W. Simpson. August 1996.
1989
       (Format: TXT=29289 bytes) (Obsoletes RFC1333) (Status: DRAFT STANDARD)

       The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr & T. Coradetti.
1990   August 1996.
       (Format: TXT=53271 bytes) (Obsoletes RFC1717) (Status: DRAFT STANDARD)

       PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996.
1994
       (Format: TXT=24094 bytes) (Obsoletes RFC1334) (Status: DRAFT STANDARD)

       Incremental Zone Transfer in DNS. M. Ohta. August 1996.
1995
       (Format: TXT=16810 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)

       A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996.
1996
       (Format: TXT=15247 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)

       TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W.
2001   Stevens. January 1997.
       (Format: TXT=12981 bytes) (Status: PROPOSED STANDARD)

       IP Mobility Support. C. Perkins. October 1996.
2002
       (Format: TXT=193103 bytes) (Updated by RFC2290) (Status: PROPOSED STANDARD)

       IP Encapsulation within IP. C. Perkins. October 1996.
2003
       (Format: TXT=30291 bytes) (Status: PROPOSED STANDARD)

       Minimal Encapsulation within IP. C. Perkins. October 1996.
2004
       (Format: TXT=12202 bytes) (Status: PROPOSED STANDARD)

2005   Applicability Statement for IP Mobility Support. J. Solomon. October 1996.
(Format: TXT=10509 bytes) (Status: PROPOSED STANDARD)

       The Definitions of Managed Objects for IP Mobility Support using SMIv2. D. Cong, M. Hamlen,
2006   C. Perkins. October 1996.
       (Format: TXT=95030 bytes) (Status: PROPOSED STANDARD)

       TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow.
2018   October 1996.
       (Format: TXT=25671 bytes) (Status: PROPOSED STANDARD)

       The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996.
2043
       (Format: TXT=13719 bytes) (Status: PROPOSED STANDARD)

       INTERNET REGISTRY IP ALLOCATION GUIDELINES. K. Hubbard, M. Kosters, D. Conrad,
2050   D. Karrenberg, J. Postel. November 1996.
       (Format: TXT=28975 bytes) (Also BCP0012) (Status: BEST CURRENT PRACTICE)

       A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie. October
2052   1996.
       (Format: TXT=19257 bytes) (Status: EXPERIMENTAL)

       Domain Name System Security Extensions. D. Eastlake, 3rd, C. Kaufman. January 1997.
2065
       (Format: TXT=97718 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD)

       The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control
2125   Protocol (BACP). C. Richards, K. Smith. March 1997.
       (Format: TXT=49213 bytes) (Status: PROPOSED STANDARD)

       ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March 1997.
2126
       (Format: TXT=51032 bytes) (Status: PROPOSED STANDARD)

       Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y.
2136   Rekhter, J. Bound. April 1997.
       (Format: TXT=56354 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)

       Secure Domain Name System Dynamic Update. D. Eastlake. April 1997.
2137
       (Format: TXT=24824 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD)

       TCP Control Block Interdependence. J. Touch. April 1997.
2140
       (Format: TXT=26032 bytes) (Status: INFORMATIONAL)

       U.S. Government Internet Domain Names. Federal Networking Council. May 1997.
2146
       (Format: TXT=26564 bytes) (Obsoletes RFC1816) (Status: INFORMATIONAL)

       A Primer On Internet and TCP/IP Tools and Utilities. G. Kessler, S. Shepard. June 1997.
2151
       (Format: TXT=114130 bytes) (Obsoletes RFC1739) (Also FYI0030) (Status:
INFORMATIONAL)

       PPP Vendor Extensions. W. Simpson. May 1997.
2153
       (Format: TXT=10780 bytes) (Updates RFC1661, RFC1962) (Status: INFORMATIONAL)

       Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM).
2163   C. Allocchio. January 1998.
       (Format: TXT=58789 bytes) (Obsoletes RFC1664) (Status: PROPOSED STANDARD)

       Referral Whois (RWhois) Protocol V1.5. S. Williamson, M. Kosters, D. Blacka, J. Singh, K.
2167   Zeilstra. June 1997.
       (Format: TXT=136355 bytes) (Obsoletes RFC1714) (Status: INFORMATIONAL)

       Resolution of Uniform Resource Identifiers using the Domain Name System. R. Danie1, M.
2168   Mealling. June 1997.
       (Format: TXT=46528 bytes) (Status: EXPERIMENTAL)

       Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997.
2181   (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123) (Status: PROPOSED
       STANDARD)

       Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July
2182   1997.
       (Format: TXT=27456 bytes) (Also BCP0016) (Status: BEST CURRENT PRACTICE)

       Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997.
2219
       (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST CURRENT PRACTICE)

       Key Exchange Delegation Record for the DNS. R. Atkinson. October 1997.
2230
       (Format: TXT=25563 bytes) (Status: INFORMATIONAL)

       Mobile-IPv4 Configuration Option for PPP IPCP. J. Solomon, S. Glass. February 1998.
2290
       (Format: TXT=39421 bytes) (Updates RFC2002) (Status: PROPOSED STANDARD)

       Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998.
2308   (Format: TXT=41428 bytes) (Obsoletes RFC1034) (Updates RFC1034, RFC1035) (Status:
       PROPOSED STANDARD)

       Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G. Oglesby. May 1998.
2345
       (Format: TXT=29707 bytes) (Status: EXPERIMENTAL)

       TFTP Option Extension. G. Malkin, A. Harkin. May 1998.
2347   (Format: TXT=13060 bytes) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT
       STANDARD)

2348   TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998.
(Format: TXT=9515 bytes) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT
       STANDARD)

       TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. May 1998.
2349   (Format: TXT=7848 bytes) (Obsoletes RFC1784) (Updates RFC1350) (Status: DRAFT
       STANDARD)

       INTERNET OFFICIAL PROTOCOL STANDARDS. J. Postel, J. Reynolds. September 1998.
       (Format: TXT=110969 bytes) (Obsoletes RFC2300, RFC2200, RFC2000, RFC1920, RFC1880,
2400   RFC1800, RFC1780, RFC1720, RFC1610, RFC1600, RFC1540, RFC1500, RFC1410, RFC1360,
       RFC1280, RFC1250, RFC1200, RFC1140, RFC1130, RFC1100, RFC1083) (Also STD0001)
       (Status: STANDARD)

More Related Content

What's hot

C# and java comparing programming languages
C# and java  comparing programming languagesC# and java  comparing programming languages
C# and java comparing programming languagesShishir Roy
 
Windows batch scripting
Windows batch scriptingWindows batch scripting
Windows batch scriptingArghodeepPaul
 
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...Zohar Babin
 
Computer programming tools and building process
Computer programming tools and building processComputer programming tools and building process
Computer programming tools and building processArghodeepPaul
 
Python in the browser
Python in the browserPython in the browser
Python in the browserPyCon Italia
 
Making%20R%20Packages%20Under%20Windows
Making%20R%20Packages%20Under%20WindowsMaking%20R%20Packages%20Under%20Windows
Making%20R%20Packages%20Under%20Windowstutorialsruby
 
Web programming UNIT II by Bhavsingh Maloth
Web programming UNIT II by Bhavsingh MalothWeb programming UNIT II by Bhavsingh Maloth
Web programming UNIT II by Bhavsingh MalothBhavsingh Maloth
 
Visual studio 2015 and .net core 5 – get ready to rumble
Visual studio 2015 and .net core 5  – get ready to rumbleVisual studio 2015 and .net core 5  – get ready to rumble
Visual studio 2015 and .net core 5 – get ready to rumbleTadeusz Balcer
 
Complete WPF Overview Tutorial with Example - iFour Technolab
Complete WPF Overview Tutorial with Example - iFour TechnolabComplete WPF Overview Tutorial with Example - iFour Technolab
Complete WPF Overview Tutorial with Example - iFour TechnolabiFour Technolab Pvt. Ltd.
 
The Ring programming language version 1.5.4 book - Part 16 of 185
The Ring programming language version 1.5.4 book - Part 16 of 185The Ring programming language version 1.5.4 book - Part 16 of 185
The Ring programming language version 1.5.4 book - Part 16 of 185Mahmoud Samir Fayed
 

What's hot (16)

Developers survival-guide
Developers survival-guideDevelopers survival-guide
Developers survival-guide
 
C# and java comparing programming languages
C# and java  comparing programming languagesC# and java  comparing programming languages
C# and java comparing programming languages
 
Windows script host
Windows script hostWindows script host
Windows script host
 
Windows batch scripting
Windows batch scriptingWindows batch scripting
Windows batch scripting
 
Codename: Roslyn
Codename: RoslynCodename: Roslyn
Codename: Roslyn
 
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...
Debugging LAMP Apps on Linux/UNIX Using Open Source Tools - Jess Portnot - OS...
 
Lecture01 - Fundamental Programming with Python Language
Lecture01 - Fundamental Programming with Python LanguageLecture01 - Fundamental Programming with Python Language
Lecture01 - Fundamental Programming with Python Language
 
Part i
Part iPart i
Part i
 
Computer programming tools and building process
Computer programming tools and building processComputer programming tools and building process
Computer programming tools and building process
 
Python in the browser
Python in the browserPython in the browser
Python in the browser
 
Making%20R%20Packages%20Under%20Windows
Making%20R%20Packages%20Under%20WindowsMaking%20R%20Packages%20Under%20Windows
Making%20R%20Packages%20Under%20Windows
 
Web programming UNIT II by Bhavsingh Maloth
Web programming UNIT II by Bhavsingh MalothWeb programming UNIT II by Bhavsingh Maloth
Web programming UNIT II by Bhavsingh Maloth
 
Visual studio 2015 and .net core 5 – get ready to rumble
Visual studio 2015 and .net core 5  – get ready to rumbleVisual studio 2015 and .net core 5  – get ready to rumble
Visual studio 2015 and .net core 5 – get ready to rumble
 
Csharp ebook
Csharp ebookCsharp ebook
Csharp ebook
 
Complete WPF Overview Tutorial with Example - iFour Technolab
Complete WPF Overview Tutorial with Example - iFour TechnolabComplete WPF Overview Tutorial with Example - iFour Technolab
Complete WPF Overview Tutorial with Example - iFour Technolab
 
The Ring programming language version 1.5.4 book - Part 16 of 185
The Ring programming language version 1.5.4 book - Part 16 of 185The Ring programming language version 1.5.4 book - Part 16 of 185
The Ring programming language version 1.5.4 book - Part 16 of 185
 

Similar to The windows socket

How to work with code blocks
How to work with code blocksHow to work with code blocks
How to work with code blocksTech Bikram
 
Hacking the Codename One Source Code - Part I - Transcript.pdf
Hacking the Codename One Source Code - Part I - Transcript.pdfHacking the Codename One Source Code - Part I - Transcript.pdf
Hacking the Codename One Source Code - Part I - Transcript.pdfShaiAlmog1
 
His162013 140529214456-phpapp01
His162013 140529214456-phpapp01His162013 140529214456-phpapp01
His162013 140529214456-phpapp01Getachew Ganfur
 
C plus plus for hackers it security
C plus plus for hackers it securityC plus plus for hackers it security
C plus plus for hackers it securityCESAR A. RUIZ C
 
Introduction-to-C-Part-1 (1).doc
Introduction-to-C-Part-1 (1).docIntroduction-to-C-Part-1 (1).doc
Introduction-to-C-Part-1 (1).docMayurWagh46
 
ODROID Magazine April 2014
ODROID Magazine April 2014ODROID Magazine April 2014
ODROID Magazine April 2014Nanik Tolaram
 
The Development History of PVS-Studio for Linux
The Development History of PVS-Studio for LinuxThe Development History of PVS-Studio for Linux
The Development History of PVS-Studio for LinuxPVS-Studio
 
Dotnet Basics Presentation
Dotnet Basics PresentationDotnet Basics Presentation
Dotnet Basics PresentationSudhakar Sharma
 
Makefile
MakefileMakefile
MakefileIonela
 
Introduction-to-C-Part-1.pptx
Introduction-to-C-Part-1.pptxIntroduction-to-C-Part-1.pptx
Introduction-to-C-Part-1.pptxNEHARAJPUT239591
 
Introduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJ
Introduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJIntroduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJ
Introduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJmeharikiros2
 
Computer and multimedia Week 1 Windows Architecture.pptx
Computer and multimedia Week 1 Windows Architecture.pptxComputer and multimedia Week 1 Windows Architecture.pptx
Computer and multimedia Week 1 Windows Architecture.pptxfatahozil
 

Similar to The windows socket (20)

How to work with code blocks
How to work with code blocksHow to work with code blocks
How to work with code blocks
 
Programming in c plus plus2
Programming in c plus plus2Programming in c plus plus2
Programming in c plus plus2
 
Smiley033
Smiley033Smiley033
Smiley033
 
Hacking the Codename One Source Code - Part I - Transcript.pdf
Hacking the Codename One Source Code - Part I - Transcript.pdfHacking the Codename One Source Code - Part I - Transcript.pdf
Hacking the Codename One Source Code - Part I - Transcript.pdf
 
C++ for hackers
C++ for hackersC++ for hackers
C++ for hackers
 
His162013 140529214456-phpapp01
His162013 140529214456-phpapp01His162013 140529214456-phpapp01
His162013 140529214456-phpapp01
 
Cpb2010
Cpb2010Cpb2010
Cpb2010
 
C
CC
C
 
C plus plus for hackers it security
C plus plus for hackers it securityC plus plus for hackers it security
C plus plus for hackers it security
 
The Seven Pillars Of Asp.Net
The Seven Pillars Of Asp.NetThe Seven Pillars Of Asp.Net
The Seven Pillars Of Asp.Net
 
Unit i
Unit iUnit i
Unit i
 
Introduction-to-C-Part-1 (1).doc
Introduction-to-C-Part-1 (1).docIntroduction-to-C-Part-1 (1).doc
Introduction-to-C-Part-1 (1).doc
 
ODROID Magazine April 2014
ODROID Magazine April 2014ODROID Magazine April 2014
ODROID Magazine April 2014
 
The Development History of PVS-Studio for Linux
The Development History of PVS-Studio for LinuxThe Development History of PVS-Studio for Linux
The Development History of PVS-Studio for Linux
 
Dotnet Basics Presentation
Dotnet Basics PresentationDotnet Basics Presentation
Dotnet Basics Presentation
 
Makefile
MakefileMakefile
Makefile
 
Introduction-to-C-Part-1.pptx
Introduction-to-C-Part-1.pptxIntroduction-to-C-Part-1.pptx
Introduction-to-C-Part-1.pptx
 
Introduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJ
Introduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJIntroduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJ
Introduction-to-C-Part-1 JSAHSHAHSJAHSJAHSJHASJ
 
Introduction to C Programming
Introduction to C ProgrammingIntroduction to C Programming
Introduction to C Programming
 
Computer and multimedia Week 1 Windows Architecture.pptx
Computer and multimedia Week 1 Windows Architecture.pptxComputer and multimedia Week 1 Windows Architecture.pptx
Computer and multimedia Week 1 Windows Architecture.pptx
 

Recently uploaded

UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"
UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"
UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"DianaGray10
 
The Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementThe Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementNuwan Dias
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Juan Carlos Gonzalez
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Valere | Digital Solutions & AI Transformation Portfolio | 2024
Valere | Digital Solutions & AI Transformation Portfolio | 2024Valere | Digital Solutions & AI Transformation Portfolio | 2024
Valere | Digital Solutions & AI Transformation Portfolio | 2024Alexander Turgeon
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 

Recently uploaded (20)

UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"
UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"
UiPath Clipboard AI: "A TIME Magazine Best Invention of 2023 Unveiled"
 
The Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API ManagementThe Kubernetes Gateway API and its role in Cloud Native API Management
The Kubernetes Gateway API and its role in Cloud Native API Management
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?Governance in SharePoint Premium:What's in the box?
Governance in SharePoint Premium:What's in the box?
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Valere | Digital Solutions & AI Transformation Portfolio | 2024
Valere | Digital Solutions & AI Transformation Portfolio | 2024Valere | Digital Solutions & AI Transformation Portfolio | 2024
Valere | Digital Solutions & AI Transformation Portfolio | 2024
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 

The windows socket

  • 1. The Windows Socket Programming Tutorial Welcome to the Windows socket programming tutorial. Here you'll find out how to program your own internet applications. The guide assumes no prior knowledge of programming with Windows Sockets, although you need a working knowledge of C. The tutorial starts off very simple and will eventually build up to an advanced level so you can understand how to program your own code for hacking applications. Please feel free to report any bugs, typos etc. There was one that crept into the pop client in part two of the tutorial, but this has been fixed (cheers Bone Digger). There's also the potential for a buffer overflow in the program (cheers mnemonix). I haven't bothered to fix that as there are lots of areas in all the programs which need better error trapping (virtually non-existent on purpose to keep the code easier to follow and understand). I will be putting a fully debugged and error trapped program example in the final part of the tutorial to show how to develop all of the frameworks illustrated into robust code. As this is going to be a custom firewall, it will need it ;) I've had quite a few requests for C tutorials since I started this guide. There are plenty of beginners tutorials out on the web. I've downloaded and reviewed quite a few rather than write my own. If you haven't used C before, I would recommend the following guide :- Coronado Enterprises C Tutor version 2 This is an excellent beginners guide and covers virtually everything you will need to know to understand the socket programming tutorial. It's also freeware. I've included it on the menu under downloads. File size is 192kB. I did not write the C tutorial, but if you have any questions about it, I'd be more than happy to answer them as I'm recommending it. If you don't have a C compiler for windows, you can download the Windows port of the Linux GCC compiler package. You will also need the RSXNTDJ package to allow you to program apps for Windows. Both of these packages (along with many other useful tools) are freely available from http://www.delorie.com Part One of the Socket tutorial describes in more detail what you will need and how to set up the compiler. The Rota
  • 2. Internet Programming with Windows - A Tutorial Part 1 By Gandalf Gandalf@dhamma.org.uk (c) Feb 2000 Contents Introduction What You Will Need Compiler Comments The Internet Protocols The Windows TCP/IP Stack Our First Program Using TCP/IP - WHOIS.C Conclusion and What’s Next Introduction I decided to write this tutorial mainly as a means of getting my head around programming Internet applications under the Microsoft Windows OS. This is a topic that is not always easy to understand. There are many web sites, references and books on the subject, but it takes a lot of hard work to plough through them all to sift the good stuff from the junk. Let me say one thing from the start. I don't like Windows, never have and I suspect I never will. I've been a Unix and Linux user (Minix before Linux came out) now for longer than I care to remember. Linux is probably the best and easiest OS to use for developing Internet applications. There are lots of applications and programs available freely for Linux, most with freely available source code. Whenever I've wanted to develop a specific tool under Linux, I've done what probably most Linux users do...download pieces of code and patch in whatever else is needed to perform the required task. It’s pretty easy to do without necessarily understanding the underlying principles. Yeah, things go wrong, but a bit of tweaking usually gets you there in the end. So why did I decide to do this under Windows? Good question. I started to use Windows more and more since Win95 came out as my profession called for me to keep up with understanding Windows as well as Unix. When I found myself having to develop Windows applications, I immediately started using Visual Basic so I could code easily rather than have to learn Windows programming with C++. I've been a C programmer for about 15 years, but mainly on Unix. I've never used C++ much before, and until recently, I thought it was a pre-requisite for programming under Windows (fool I hear you say).
  • 3. The main problem I've got with programming under Windows is that most freely available source code is written to use the GUI. It always seems that 90% of the code goes towards "making things pretty" etc. To a non-Windows guru, this can be very daunting, as it's almost impossible for a person not used to C++ to decipher what the hell is going on. It came to head recently when I wanted to write an application to allow me to retrieve multiple emails from multiple POP servers into one big email spool. I wanted to be able to be read the spool via a single mail editor, and have the editor fill my reply email headers automatically. So I decided to get to grips with both C programming for Windows and also accessing the functions within the winsock.dll. After that, I decided to dig deeper and delve into coding direct without using the Winsock dll. Anyway, enough of the ramble. This tutorial should grow on a weekly basis (it'll take me a week or so to write each section as I decipher my own notes I wrote whilst exploring this) and will cover Internet programming using mainly C routines for Windows. The plan is to start simply by accessing the Winsock dll for all initial programs. At each stage, a brief explanation and useful working source code will be presented to explain various concepts. All programs have been written as command line programs. No GUI, so the code is easier to understand. The tutorial will build up to a much more advanced level, resulting in the development of a complete new Winsock dll with a lot more callable routines that the hacker and phreaker will like! Some assembly language programming will be required for later stages of the tutorial, but I'll be releasing these routines as a dll for anyone who doesn't want to learn assembly, but still wants to access the routines. All of the way through the tutorial, explanations of the underlying concepts of internet programming will hopefully be built up to an advanced level. For example, from the outset various Internet protocols will be described very briefly. Further on in the tutorial, each of the protocols will be explored to a byte level. What You Will Need A basic understanding of C. A C compiler for windows. Suitable Windows libraries (mainly Winsock and ICMP). Windows 95/98 or NT. The desire to learn. For those who have never programmed in C before (and I'm not talking about for windows), then you will need to download one of the many C programmers tutorials/guides/references that are freely available on the net. Ignore any that are windows related, as I will be including a brief chapter on using C to program Windows apps. If you can
  • 4. understand Basic or any other programming language, C shouldn't be much of a problem. C compilers are available free for download. For learning basic C then I would recommend Borland's TurboC. They have released version 1 (I believe) for free download, although it won't be suitable for Windows apps. I use the free GCC package with RSXNTDJ (also free) for developing Windows apps. These are downloadable from www.delorie.com. The main reason I use this is that it is a port of the Linux GCC package, so I'm familiar with it. Alternatively, you can buy, beg, steal or borrow a commercial copy of whatever compiler you want. Windows libraries can be downloaded from Microsoft’s SDK pages (although I couldn't find a one for ICMP). For the GCC package you don't even need the libraries as you can convert the equivalent dll's into .a libraries using the makelib tool supplied. All the routines presented in this tutorial have been tested under NT4 Service Pack 5. I make no guarantees they will work with other win32 OS's although they should. If you run into problems, then email me and I'll try to come up with a solution. Compiler Comments Unfortunately I will have to restrict comments in this section to the use of GCCW32 and RSXNTDJ as I don’t have access to any other win 32 compilers. If anyone wants to give feedback on using other compilers, then please email me and I’ll include it in the updates (along with your email address so you can get the why doesn’t this work questions) With these packages, you can’t use the standard Lib’s that come with the Microsoft SDK, however there is a MAKELIB utility program that can convert MS DLL’s into a .a library. According to the specs, the header files included with RSXNTDJ state that WINSOCK is supported up to and including version 2.0, however, I could not get programs to compile with NT4.0 SP5’s wsock32.dll after I converted it using MAKELIB. You can set up RSXNTDJ and GCCW32 to use the MS SDK headers, but as the SDK is a hefty download I have not tried this. I will eventually get round to trying it and will update this section. Until then, I am using an older version of Winsock that was left under my system32 directory after an update and had been renamed as wsock32n.dll. This appears to be version 1.1, but works OK. You will need to convert both wsock32n.dll and icmp.dll into .a libraries using the MAKELIB utility. Unfortunately, the help file that comes with RSXNTDJ is wrong, so here’s the protocol:-
  • 5. Copy wsock32.dll and icmp.dll into your rsxntdj/lib directory, then from a command prompt type the following: - makelib wsock32n.dll –o libwsock.a And also: - makelib icmp.dll –o libicmp.a In your makefile for gccw32, reference these as –lwsock and –licmp E.g. for the first program that we will compile (whois.c), the makefile looks like this: - PROJECT = whois OBJS = whois.o LIBS = -lwsock include ....rsxntmak.gnu (Make sure the path for rsxntmak.gnu is correct for your system) The Internet I thought a very brief introduction to the Internet and some basic terminology might be a good idea to jog people’s memory on certain points, and maybe clear up a few misconceptions. This is general, the following sections will relate specifically as to how Windows handles Internet access. It all starts very basic, but by the end of the tutorial it will get pretty hairy. There are billions of computers connected to the Internet, some via dial up when needed, and others, which have a permanent "live" connection. To connect to the computer you want to talk to, you need some way of identifying this computer. It will have a unique "name" and also an IP address, which is a 32-bit number. The "name" will never change unless the user decides to connect to the internet via a different dial up account, but the IP address may do, especially for most dial up ISP’s "Names" are specified by a convention called DNS, which stands for Domain Name Service. RFC’s 1032, 1033, 1034 and 1035 cover DNS for those who want to delve deeper. OK ... let’s take a practical example. Let’s take my account I use to post to PHUK as an example. The unique "name" is gandalf.freeuk.com The IP number changes every time I dial up the account. So how are these all related?
  • 6. We’ll start with the name. A DNS name has the following format: - subdomain.subdomain.domain There can be many of the subdomain bits. In my case, com is the domain, freeuk is a subdomain and gandalf is the subdomain within freeuk. The IP Address We will discuss the IP protocol later on in this section, but for now, it is sufficient to say that IP stands for Internet Protocol and the IP address is the basis for identifying all computers on the internet (and indeed often on private networks). An IP address consists of four octets that define a unique address e.g. 176.116.32.6 When I connect to freeuk.com and successfully login, their server assigns an IP address to my computer. This is different every time I login. It is a dynamic IP address, i.e. it only relates to my computer for the duration of my connection to the Internet. Some ISP’s issue static IP’s, where even if you aren’t connected the same IP address is reserved for your computer. The handling of DNS name and equivalent IP address is done by the ISP’s Nameservers. Part Two of the tutorial will dig deeper into IP address classes and subnets etc. Protocols There are quite a few protocols that need to be understood to get to grips with writing your own Internet applications. For this part of the tutorial, we don’t need to know the protocols in depth. But I’ll briefly describe some of them here. Part Two of the tutorial will discuss all the protocols to a byte by byte level for those who really want to know how things work. PPP When you use dial up networking to connect to your ISP, Windows uses the PPP protocol to talk to the ISP’s computer. PPP stands for Point to Point Protocol. It handles negotiation of baud rates etc and also gets an IP address from the ISP. IP The Internet Protocol is responsible for transporting data packets across the Internet and is primarily used by the routers to give them enough information to get the data packets to their destination. Sometimes IP may fragment data into smaller chunks, where each chunk may arrive at the destination in any order and by different network routes. It is the responsibility of IP to reassemble everything back into the correct order.
  • 7. TCP IP by itself is not a very reliable protocol as it sends info out and doesn’t ever check to see if it gets to the destination. This is usually the job for TCP, which stands for Transmission Control Protocol. Any Internet application that requires reliable data transfer (e.g. HTTP, POP, SMTP etc) uses TCP to handshake the data transfer. TCP runs on top of IP UDP UDP is also a transmission protocol called the User Datagram Protocol. Unlike TCP it doesn’t use handshaking, so it is much faster but not as reliable. It is often used for streaming audio or video over the Internet. Like TCP, UDP runs on top of IP ICMP ICMP stands for Internet Control Message Protocol. It is closely related to IP (in fact it is usually encapsulated within the IP data packets). It is used by programs such as PING etc to check if parts of the Internet are up and running. It is not often used for much else (from the Windows user perspective), but it is used extensively by all of the routers on the Internet. That’s all we’ll say about protocols at the moment until part two of the tutorial. We’ll present a few programs at the end of this tutorial, which will demonstrate the use of windows socket programming using TCP/IP and also ICMP. The Windows TCP/IP Stack The Windows TCP/IP stack (the Winsock dll) takes all the hard work out of programming Internet applications. It handles lower level access for protocols such as TCP, UDP and IP. A separate dll (icmp.dll) handles the ICMP protocol. We will introduce all gently to programming via the various Windows dll’s. This just about reaches the end of the first part of the tutorial. Hey says all, where’s the code and examples? Okay, the first part of the tutorial (the download you are reading now) is a basic introduction as to why I decided to write this tutorial. It hopefully gives a basic explanation of various protocols that will be explored in continuing parts of the tutorial. Without these, people who want to learn from scratch will be out of their depth. So, I can’t leave this without giving a bit of code for all to try. The following program provides a template for TCP/IP access using C.
  • 8. Yes, if you want to do other things, you will have to understand the relevant RFC’s and will also need to use a few more routines from the Winsock dll. What we have presented so far should give you a basic framework to allow you to layout your own programs. Don’t worry if you don’t want to, the second tutorial is all about implementing routines from the Winsock dll. It has plenty of examples covering TCP/UDP and ICMP. Our First Program Using TCP/IP - WHOIS.C Whois will be familiar to Linux users. If you want to find out information about a certain DNS name, you can run a whois query to find out information on network address numbers, administrative contact details and valid name server’s etc. Official whois servers exist all over the world. A couple of the most useful ones are whois.internic.net (for com, net, org and edu domains) and whois.nic.uk (for co.uk, org.uk, ltd.uk, net.uk etc). The program accepts one or two command line arguments: - Whois domainname whois.server and saves any query results to a file called whoislog.txt. So, for example, if I wanted to query whois.internic.net about freeuk.com, I would use: - Whois freeuk.com whois.internic.net If the second argument is missing, the program automatically uses whois.internic.net. Here is the output for a query on freeuk.com: - Whois Session Started Sat Feb 26 23:52:33 2000. Connecting to whois.internic.net Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: FREEUK.COM Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: www.networksolutions.com Name Server: NS0.FREEUK.NET Name Server: NS1.FREEUK.NET Name Server: NS2.CLARA.NET Updated Date: 15-sep-1999
  • 9. >>> Last update of whois database: Sat, 26 Feb 00 02:54:30 EST <<< The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars. So what happens if I want to query my own freeuk account:- Whois gandalf.freeuk.com Result:- Whois Session Started Sun Feb 27 17:33:41 2000. Connecting to whois.internic.net Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. No match for "GANDALF.FREEUK.COM". >>> Last update of whois database: Sun, 27 Feb 00 02:36:32 EST <<< The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and Registrars. So why didn’t it find my account? Well Internic only handles registered domains and not subdomains. We will find out in part two of the tutorial how to query freeuk to find out details on subdomain accounts. Anyway, here is the program listing. There is a download section at the end of this tutorial with links to download the source, libraries, makefile etc for this and all subsequent programs in this tutorial. /* * whois.c * * (c) Feb 2000 by Gandalf * */ #include <stdio.h> #include <stdlib.h> #include <time.h> #include <windows.h> #include <winsock.h> #define WIN32_LEAN_AND_MEAN /* define win 32 only */ void handle_error(void); /* Error handler routine */ void write_file(char *buf); /* Write details to log file */ int main (int argc, char **argv) { WORD wVersionRequested; /* socket dll version info */
  • 10. WSADATA wsaData; /* data for socket lib initialisation */ SOCKET sock; /* socket details */ const int BUF_LEN=10000; /* Buffer size for transfers */ struct sockaddr_in address; /* socket address stuff */ struct hostent * host; /* host stuff */ int err; /* error trapping */ float socklib_ver; /* socket dll version */ char File_Buf[BUF_LEN]; /* file buffer */ char DomainName[100]; /* domain name from user */ char HostName[100]; /* host name from user */ time_t now; /* for date and time */ if (argc < 2) /* check we have command line options */ { printf("nUseage: whois domainname [whois.server]n"); exit(0); } strcat(DomainName, argv[1]); /* get domain name from command line */ strcat(DomainName, "rn"); /* add crlf as whois servers expect it */ if (argc == 3) strcat(HostName, argv[2]); /* get host name from command line */ else strcat(HostName, "whois.internic.net"); wVersionRequested = MAKEWORD( 1, 1 ); /* * We need to call the WSAStartup routine BEFORE we try to use any of * the Winsock dll calls. */ if ( WSAStartup( wVersionRequested, &wsaData ) != 0 ) handle_error(); /* Check socket DLL supports 1.1 or higher */ socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0; socklib_ver += LOBYTE( wsaData.wVersion ); if ( socklib_ver < 1.1 ) { printf ("nError: socket library must support 1.1 or greater.n"); WSACleanup(); /* clean up before exit */ exit(0); } /* write current date and time to log file and screen */ time(&now); sprintf(File_Buf, "Whois Session Started %.24s.nn", ctime(&now)); write_file(File_Buf); /* * Open a socket. The AF_INET parameter tells windows we want to use
  • 11. the * internet. Other parameters for different networking can be chosen e.g. * for netbios, IPX etc. The SOCK_STREAM parameter lets windows know we want * to use TCP rather than UDP, and the final parameter will always be * zero for what we want to do and tells windows to use whatever * default communication protocol has been established (eg PPP and IP) */ if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET ) handle_error(); /* We now need to initialise a couple of variables in the address * structure. Once again, to tell windows we are using the internet, * and also what port we want to use when connecting to a remote * computer. In this case it is port 43 which is the standard port for * whois. The htons routine is used to convert the way Intel chips * store data in memory, which is different compared to many other computers. * The standard is based on Motorola format. */ address.sin_family=AF_INET; /* internet */ address.sin_port = htons(43); /* port 43 for whois */ /* write to the log file and screen */ sprintf(File_Buf,"Connecting to %sn", HostName); write_file(File_Buf); /* * host is a pointer to a structure of the predefined type hostent. We * need to call gethostbyname with the DNS name we want to use to return * a pointer to a hostent structure. This is so we can resolve an IP * address from our ISP's nameserver. */ if ( (host=gethostbyname(HostName)) == NULL ) handle_error(); /* we then initialise the address structure with the resolved IP address */ address.sin_addr.s_addr=*((unsigned long *) host->h_addr); /* Now we're ready to actually connect to the whois server itself */ if ( (connect(sock,(struct sockaddr *) &address, sizeof(address))) != 0) handle_error(); /*
  • 12. * We should be connected to the whois server at this point * so we need to send the domain name and wait for the response. The send * and recv routines are always used with TCP. These enable handshaking * compared to the sendto and recvfrom routines which are used for UDP * protocol, ie without handshaking. */ strcpy(File_Buf, DomainName); err=send(sock,File_Buf,strlen(File_Buf),0); /* send domain name */ err=recv(sock,File_Buf,BUF_LEN,0); /* discard first response */ err=recv(sock,File_Buf,BUF_LEN,0); /* get query results back */ write_file(File_Buf); /* Always call WSACleanup before exiting */ WSACleanup(); /* clean up before exit */ exit(0); } void handle_error(void) { /* * Errors are handled by calling the WSAGetLastError routine which * will return the last error as one of the following. As we develop * this tutorial, we will go into much more detail on what they mean * and what caused them. */ switch ( WSAGetLastError() ) { case WSANOTINITIALISED : printf("Unable to initialise socket.n"); break; case WSAEAFNOSUPPORT : printf("The specified address family is not supported.n"); break; case WSAEADDRNOTAVAIL : printf("Specified address is not available from the local machine.n"); break; case WSAECONNREFUSED : printf("The attempt to connect was forcefully rejected.n"); break; case WSAEDESTADDRREQ : printf("address destination address is required.n"); break; case WSAEFAULT : printf("The namelen argument is incorrect.n"); break; case WSAEINVAL : printf("The socket is not already bound to an address.n"); break; case WSAEISCONN : printf("The socket is already connected.n");
  • 13. break; case WSAEADDRINUSE : printf("The specified address is already in use.n"); break; case WSAEMFILE : printf("No more file descriptors are available.n"); break; case WSAENOBUFS : printf("No buffer space available. The socket cannot be created.n"); break; case WSAEPROTONOSUPPORT : printf("The specified protocol is not supported.n"); break; case WSAEPROTOTYPE : printf("The specified protocol is the wrong type for this socket.n"); break; case WSAENETUNREACH : printf("The network can't be reached from this host at this time.n"); break; case WSAENOTSOCK : printf("The descriptor is not a socket.n"); break; case WSAETIMEDOUT : printf("Attempt timed out without establishing a connection.n"); break; case WSAESOCKTNOSUPPORT : printf("Socket type is not supported in this address family.n"); break; case WSAENETDOWN : printf("Network subsystem failure.n"); break; case WSAHOST_NOT_FOUND : printf("Authoritative Answer Host not found.n"); break; case WSATRY_AGAIN : printf("Non-Authoritative Host not found or SERVERFAIL.n"); break; case WSANO_RECOVERY : printf("Non recoverable errors, FORMERR, REFUSED, NOTIMP.n"); break; case WSANO_DATA : printf("Valid name, no data record of requested type.n"); break; case WSAEINPROGRESS : printf("address blocking Windows Sockets operation is in progress.n"); break; case WSAEINTR : printf("The (blocking) call was canceled via WSACancelBlockingCall().n"); break; default : printf("Unknown error.n"); break; }
  • 14. WSACleanup(); exit(0); } void write_file(char *buf) { /* writes results to a log file and also to the screen */ FILE *fp=fopen("whoislog.txt","a+"); fprintf(fp,"%sn",buf); fclose(fp); printf("%sn",buf); } So...that was our first program using TCP/IP. It is a basic template for virtually any program you will want to do using TCP/IP. All you need to do is change any of the relevant details such as domain name, port, data to send depending on what type of server you are trying to connect to. For example, if you wanted to connect to a POP server, then you would change the domain name to the name of the POP server (e.g. relay.freeuk.net). You would also change the port number to 110, and once a valid connection has been established, change the send and recv part of the program to negotiate collection of your email. For virtually all recognised data transfer protocols such as POP/SMTP etc, there is an RFC that covers the required send and receive string formats. For POP it is RFC1725 and for SMTP it is RFC1869. These are freely available on the web. Conclusion and What’s Next Okay...Nothing difficult so far. We have discussed a few protocols, and we have introduced a simple program that can be compiled and used under windows to do a domain name enquiry. The basic framework won’t change for the next tutorial. Part Two of the tutorial will illustrate further programs that access the Winsock dll. We will also introduce accessing the ICMP dll. Anyway, enough for now. Check back in a couple of weeks for part two of the tutorial. Send any feedback, errors, typos and wants to gandalf@dhamma.org.uk. The Rota BlueCrab Ltd
  • 15. Internet Programming with Windows - A Tutorial Part 2 By Gandalf Gandalf@dhamma.org.uk (c) Mar 2000 Contents Disclaimer Introduction RFC's Simple POP Email Client Sending Emails by SMTP Using UDP/IP Conclusion and What's Next Disclaimer Some of the programs presented in this tutorial may be illegal to use unless you have permission from the owner of the server you attempt to connect to and also to the recipient of any email's you send. If in doubt, don't do it. You can of course use these freely on your own network if you own one. If you want to try anything out, then consider setting up a Linux Box to act as a server so you can experiment in peace without any fear of reprisal. Everything presented in this tutorial should be treated as a theoretical discussion of what is possible. The author will not be held responsible for actions of anyone using material from this tutorial for illegal purposes. Introduction Hopefully we've all survived part one of the tutorial. Part two is going to start off pretty much where part one left off. We will start by putting together a more advanced program using TCP/IP that will allow you to retrieve emails from a POP account into a mail spool file. We will also develop a program to allow you to send emails via smtp. This will include falsifying header information. The programs are going to be fairly rudimentary, but will provide a nice framework for those who would like to develop their own email client. RFC's I've mentioned RFC's briefly in part one of the tutorial. We are now going to use information from various RFC's in some detail. So what are RFC's ?
  • 16. Every protocol that exists on the net, whether it's for handling mail, news, web site access or anything else you care to consider, there is an RFC for it. RFC stands for Request for Comments, and the whole of the internet and it's associated protocols are based on them. If you want to develop or understand any Internet application, you need to read the associated RFC's. You can find a list of all RFC's used so far in this tutorial at http://www.exegesis.org.uk/gandalf/winsock/rfc/index.htm The RFC's themselves are also downloadable or readable from links on the index page. I will eventually be putting ALL rfc's online over a period of time, with a search facility. OK, on with the tutorial, let's start with a bit of programming. Simple POP Email Client Let's continue where we left off in the first part of the tutuorial by developing another TCP/IP program. We will put together a basic framework to allow you to connect to, and negotiate downloading POP mail from your POP server. As usual, we will be presenting a piece of code that is functional rather then exhaustively error trapped to make it easier to understand. There are comments in the code to suggest areas that would need to be changed if you wanted to develop a robust POP client capable of handling attachments etc, but this will do to get you started. Later parts of the tutorial will be using this code to develop a full multiple POP account client with SMTP posting. The program uses a log file called poplog.txt to store what's sent to and received back from the pop server so you can check for errors etc. It saves all mails to a text mail spool called mailbox.txt complete with headers. Here's the code:- /* * popclnt1.c * * * A very basic pop client that retrieves mail from an account into * a multi pop retrieval client in later parts of the tutorial with all * the extra error handling that's needed. Use this as a framework to * develop your own pop client. This program doesn't delete any mails * from the pop mail server, so you can try it out without being afraid * of losing any emails! */ #include <stdio.h>
  • 17. #include <stdlib.h> #include <time.h> #include <windows.h> #include <winsock.h> #define WIN32_LEAN_AND_MEAN void handle_error(void); void pop_error(void); void write_file(int file, char *p); int main (int argc, char *argv[]) { const long BUF_LEN=60000; /* 60000 char buffer. In real life we would have to allow for a much * larger buffer than this to allow retrieval of long messages which * might have attachments. We will be doing this in one of the later * parts of the tutorial by using synchronised data flow with a smaller * buffer that downloads mails in smaller chunks. */ const char POP_ERR_MSG[]="-ERR"; /* POP Server error response */ const int LOG_FILE=1; /* write to log file */ const int MAIL_FILE=2; /* write to mail file */ const int SCREEN=4; /* display on screen */ WORD wVersionRequested; /* socket dll version info */ WSADATA wsaData; /* socket lib initialisation */ SOCKET sock; /* socket details */ struct sockaddr_in address; /* socket address stuff */ struct hostent * host; /* host stuff */ int err; /* error trapping */ float socklib_ver; /* socket dll version */ char * File_Buf; /* file buffer */ char * Rec_Buf; /* recieve buffer */ /* Fill in to suit your own account, increase array sizes if needed */ char hostname[20] = "pop.wherever.net"; /* hostname for pop server */ char username[20] = "username"; /* username */ char password[20] = "password"; /* password */ int i,j; /* general counters */ char tempbuf[20] = ""; /* temp string buffer for parsing */ int num_flag=0; /* string parse flag */ time_t now; /* from time.h */ /* allocate dynamic storage from the heap */ File_Buf = malloc(BUF_LEN * sizeof(char) + 1); Rec_Buf = malloc(BUF_LEN * sizeof(char) + 1); wVersionRequested = MAKEWORD( 1, 1 );
  • 18. if ( WSAStartup( wVersionRequested, &wsaData ) != 0 ) handle_error(); /* Check socket DLL supports 1.1 or higher */ socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0; socklib_ver += LOBYTE( wsaData.wVersion ); if ( socklib_ver { printf ("Error: socket library must support 1.1 or greatern"); WSACleanup(); return 0; } /* get date and time to write to log file */ time(&now); sprintf(File_Buf,"Pop Client Session started %.24s.nn", ctime(&now)); write_file(LOG_FILE | SCREEN, File_Buf); /* open a socket based on TCP/IP */ if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET ) handle_error(); address.sin_family=AF_INET; /* internet */ address.sin_port = htons(110); /* pop port */ sprintf(File_Buf,"Connecting to %sn", hostname); write_file(LOG_FILE | SCREEN, File_Buf); /* DNS on hostname */ if ( (host=gethostbyname(hostname)) == NULL ) handle_error(); /* IP address for hostname */ address.sin_addr.s_addr=*((unsigned long *) host->h_addr); /* try to connect to pop server */ if ( (connect(sock,(struct sockaddr *) &address, sizeof(address))) != 0) handle_error(); sprintf(File_Buf, "Connected to %sn", hostname); write_file(LOG_FILE | SCREEN, File_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* should start +OK */ write_file(LOG_FILE, File_Buf); if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL ) /* check for errors */ pop_error(); strcpy(Rec_Buf,"USER "); strcat(Rec_Buf, username);
  • 19. strcat(Rec_Buf, "rn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* send username */ sprintf(File_Buf,"sent: %s",Rec_Buf); write_file(LOG_FILE, File_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* should recieve +OK */ sprintf(File_Buf,"received: %s", Rec_Buf); write_file(LOG_FILE, File_Buf); if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL ) /* check for errors */ pop_error(); strcpy(Rec_Buf,"PASS "); strcat(Rec_Buf, password); strcat(Rec_Buf, "rn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* send password */ sprintf(File_Buf,"sent: %s",Rec_Buf); write_file(LOG_FILE, File_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* should recieve +OK */ sprintf(File_Buf,"received: %s",Rec_Buf); write_file(LOG_FILE, File_Buf); if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL ) /* check for errors */ pop_error(); strcpy(Rec_Buf,"STATrn"); /* send stat command */ err=send(sock,Rec_Buf,strlen(Rec_Buf),0); sprintf(File_Buf,"sent: %s", Rec_Buf); write_file(LOG_FILE, File_Buf); /* * should recieve +OK x y where x = number of messages * and y is total octets. Note the buffers we have allocated * would not be sufficient for a real pop client. They * should be dynamically allocated here after checking the * size of the waiting emails. */ err=recv(sock,Rec_Buf,BUF_LEN,0); sprintf(File_Buf,"received: %s", Rec_Buf); write_file(LOG_FILE, File_Buf); if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL ) /* check for errors */ pop_error(); /* * Now we need to work out how many emails we have to retrieve * and set up a loop to get them all. */ i = j = 0; while (i { if (Rec_Buf[i] > '0' && Rec_Buf[i] { while (Rec_Buf[i] != ' ') /* space is end of number */ { tempbuf[j] = Rec_Buf[i];
  • 20. j++; i++; } num_flag=1; tempbuf[j] = '0'; } i++; } i = atoi(tempbuf); /* number of emails */ printf("There are %d message(s) waitingrn", i); /* * At this point we should really be checking the length of each email * on the POP server and then either allocate dynamic memory, or better * still, try synchronised access which we will be doing in a later * part of the tutorial. Until then, let's keep it simple. If you do * have an email larger than the buffer, it won't do anything else * other than crash the program! */ for( j=1; j<=i; j++) { sprintf(Rec_Buf, "RETR %drn", j); /* add number */ printf("Retrieving message number %dn", j); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); sprintf(File_Buf,"sent: %s ",Rec_Buf); write_file(LOG_FILE, File_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* +OK message will follow */ sprintf(File_Buf,"received: %s ",Rec_Buf); write_file(LOG_FILE, File_Buf); if ( strstr(Rec_Buf,POP_ERR_MSG) != NULL ) /* check for errors */ pop_error(); err=recv(sock,Rec_Buf,BUF_LEN,0); /* retrieve the mail */ sprintf(File_Buf,"%s",Rec_Buf); write_file(MAIL_FILE, File_Buf); } printf ("All donenn"); /* send quit command then clean up */ strcpy(Rec_Buf,"QUITrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); sprintf(File_Buf,"sent: %s", Rec_Buf); write_file(LOG_FILE, File_Buf); /* deallocate buffer memory */ free(File_Buf); free(Rec_Buf);
  • 21. WSACleanup(); return 0; } void handle_error(void) { /* * Errors are handled by calling the WSAGetLastError routine which * will return the last error as one of the following. As we develop * this tutorial, we will go into much more detail on what they mean * and what caused them. */ switch ( WSAGetLastError() ) { case WSANOTINITIALISED : printf("Unable to initialise socket.n"); break; case WSAEAFNOSUPPORT : printf("The specified address family is not supported.n"); break; case WSAEADDRNOTAVAIL : printf("Specified address is not available from the local machine.n"); break; case WSAECONNREFUSED : printf("The attempt to connect was forcefully rejected.n"); break; case WSAEDESTADDRREQ : printf("address destination address is required.n"); break; case WSAEFAULT : printf("The namelen argument is incorrect.n"); break; case WSAEINVAL : printf("The socket is not already bound to an address.n"); break; case WSAEISCONN : printf("The socket is already connected.n"); break; case WSAEADDRINUSE : printf("The specified address is already in use.n"); break; case WSAEMFILE : printf("No more file descriptors are available.n"); break; case WSAENOBUFS : printf("No buffer space available. The socket cannot be created.n"); break; case WSAEPROTONOSUPPORT : printf("The specified protocol is not supported.n"); break; case WSAEPROTOTYPE : printf("The specified protocol is the wrong type for this socket.n"); break; case WSAENETUNREACH : printf("The network can't be reached from this host at this time.n");
  • 22. break; case WSAENOTSOCK : printf("The descriptor is not a socket.n"); break; case WSAETIMEDOUT : printf("Attempt timed out without establishing a connection.n"); break; case WSAESOCKTNOSUPPORT : printf("Socket type is not supported in this address family.n"); break; case WSAENETDOWN : printf("Network subsystem failure.n"); break; case WSAHOST_NOT_FOUND : printf("Authoritative Answer Host not found.n"); break; case WSATRY_AGAIN : printf("Non-Authoritative Host not found or SERVERFAIL.n"); break; case WSANO_RECOVERY : printf("Non recoverable errors, FORMERR, REFUSED, NOTIMP.n"); break; case WSANO_DATA : printf("Valid name, no data record of requested type.n"); break; case WSAEINPROGRESS : printf("address blocking Windows Sockets operation is in progress.n"); break; case WSAEINTR : printf("The (blocking) call was canceled via WSACancelBlockingCall().n"); break; default : printf("Unknown error.n"); break; } WSACleanup(); exit(0); } void pop_error(void) { printf("POP Error, Check the Log File for Detailsrnrn"); WSACleanup(); exit(0); } void write_file(int file_type, char *p) { const int LOG_FILE=1; /* write to log file */ const int MAIL_FILE=2; /* write to mail file */ const int SCREEN=4; /* display on screen */
  • 23. if( (file_type & LOG_FILE) != 0 ) /* add to logs */ { FILE *fp=fopen("poplog.txt","a+"); fprintf(fp,"%sn",p); fclose(fp); } if( (file_type & MAIL_FILE) != 0 ) /* add to mailbox */ { FILE *fp=fopen("mailbox.txt","a+"); fprintf(fp,"%sn",p); fclose(fp); } if ( (file_type & SCREEN) != 0 ) /* screen */ { printf("%sn",p); } } Log File Example after connecting to a POP Server:- Pop Client Session started Tue Mar 28 22:27:06 2000. Connecting to pop.freeuk.net Connected to pop.freeuk.net received: +OK CPOP v2.3 Ready for Action sent: USER xxxxxxxx received: +OK xxxxxxxx sent: PASS xxxxxxxx received: +OK xxxxxxxx sent: STAT received: +OK 1 7165 sent: RETR 1 received: +OK 1 sent: QUIT Sending Email's with SMTP
  • 24. Now that we've seen how to retrieve emails from a POP server, we'll take a look at how to send them with SMTP. Once again using TCP/IP. As for the POP client, the program is a basic framework for you to develop further. This will be our last TCP/IP example for a while. Hopefully, the three programs we have presented so far will allow you to develop your own TCP/IP applications by reading the relevant RFC's to allow you to establish and use the required protocol. Most email programs available for windows won't allow you to modify certain headers and often put in additional header fields you might not want to use. With this program, you can set up the "From:" field if you don't want your real email address to be seen. It is theoretically possible to use it to log onto SMTP servers where you don't have an account and send emails from their server. Many SMTP servers do not check user details, although a large number of UK ISP's do check you are using one of their Dial Up Accounts before letting you use SMTP to protect themselves from email spammers. You might of course be logged in their log files if you aren't careful! Anyway, let's take an example. The following program sends an email to whoever has been specified in the RCPT TO: field, in this case, it comes to my account. However, when I recieve it it will appear to have come from Bill Clinton and should have been sent to President Putin. Here's the source:- /* * smtp1.c * * (c) Mar 2000 by Gandalf * * A very basic smtp program to send emails from a text file. Try it out by * sending an email to one of your mail accounts. Make your own email headers * up with this, or add a few that maybe your current email program doesn't * allow. This example will send an email to whoever you specify in the RCPT TO * field, but will appear to be intended for someone else, and of course it * will also appear to come from someone different to yourself! * This is a technique often used by spammers. I don't agree with spamming, * but the technique can be useful for other purposes. */ #include <stdio.h> #include <stdlib.h> #include <time.h> #include <windows.h> #include <winsock.h> #define WIN32_LEAN_AND_MEAN void handle_error(void); void smtp_error(void); void write_file(int file, char *p); int main (int argc, char *argv[])
  • 25. { const int BUF_LEN=5000; /* send and recieve buffers */ const int LOG_FILE=1; /* write to log file */ const int SCREEN=4; /* display on screen */ WORD wVersionRequested; /* socket dll version info */ WSADATA wsaData; /* socket lib initialisation */ SOCKET sock; /* socket details */ struct sockaddr_in address; /* socket address stuff */ struct hostent * host; /* host stuff */ int err; /* error trapping */ float socklib_ver; /* socket dll version */ char * File_Buf; /* file buffer */ char * Rec_Buf; /* recieve buffer */ /* Change to use your own smtp host */ char hostname[20] = "relay.where.net"; /* hostname for smtp server */ time_t now; /* from time.h */ /* allocate dynamic storage from the heap */ File_Buf = malloc(BUF_LEN * sizeof(char) + 1); Rec_Buf = malloc(BUF_LEN * sizeof(char) + 1); wVersionRequested = MAKEWORD( 1, 1 ); if ( WSAStartup( wVersionRequested, &wsaData ) != 0 ) handle_error(); /* Check socket DLL supports 1.1 or higher */ socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0; socklib_ver += LOBYTE( wsaData.wVersion ); if ( socklib_ver { printf ("Error: socket library must support 1.1 or greatern"); WSACleanup(); return 0; } /* get date and time to write to log file */ time(&now); sprintf(File_Buf,"SMTP Session started %.24s.nn", ctime(&now)); write_file(LOG_FILE | SCREEN, File_Buf); /* open a socket based on TCP/IP */ if ( (sock = socket(AF_INET, SOCK_STREAM, 0)) == INVALID_SOCKET ) handle_error(); address.sin_family=AF_INET; /* internet */ address.sin_port = htons(25); /* smtp port */ sprintf(File_Buf,"Connecting to %sn", hostname); write_file(LOG_FILE | SCREEN, File_Buf);
  • 26. /* DNS on hostname */ if ( (host=gethostbyname(hostname)) == NULL ) handle_error(); /* IP address for hostname */ address.sin_addr.s_addr=*((unsigned long *) host->h_addr); /* Connect to smtp server */ if ( (connect(sock,(struct sockaddr *) &address, sizeof(address))) != 0) handle_error(); sprintf(File_Buf, "Connected to %sn", hostname); write_file(LOG_FILE | SCREEN, File_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */ write_file(LOG_FILE | SCREEN, File_Buf); /* * OK, now we send the usual expected string to the smtp host. This * should be "HELO whatever.wewant.comrn" Some smtp hosts check * the domain out properly, but most don't. As long as it checks a * rudimentary test to see if it could be a valid domain, the smtp * host will usually accept it! */ sprintf(Rec_Buf, "HELO microsoft.comrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* send expected response */ write_file(LOG_FILE | SCREEN, Rec_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */ write_file(LOG_FILE | SCREEN, File_Buf); sprintf(Rec_Buf, "MAIL FROM: bclinton@whitehouse.govrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* send who it's from */ write_file(LOG_FILE | SCREEN, Rec_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */ write_file(LOG_FILE | SCREEN, File_Buf); sprintf(Rec_Buf, "RCPT TO: gandalf@dhamma.org.ukrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* send who it's to. This is */ write_file(LOG_FILE | SCREEN, Rec_Buf); /* the last required field */ err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */
  • 27. write_file(LOG_FILE | SCREEN, File_Buf); sprintf(Rec_Buf, "DATArn"); /* Send a DATA command which */ err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* tells the server that all */ write_file(LOG_FILE | SCREEN, Rec_Buf); /* else we send is going to * be our message with headers * and the mesaage body. */ err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */ write_file(LOG_FILE | SCREEN, File_Buf); /* * OK. At this point we can add as many headers as we want. Check out * the RFC's for all common headers */ sprintf(Rec_Buf, "From: Bill Clinton <bclinton@whitehouse.gov>rn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); sprintf(Rec_Buf, "To: Putin <putin@kremlin.ru>rn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); sprintf(Rec_Buf, "Subject: Congratulationsrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); /* Done with headers, so let's add the message body */ sprintf(Rec_Buf, "rnDear President Putinrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); sprintf(Rec_Buf, "rnCongratulations on your recent appointment "); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); sprintf(Rec_Buf, "to President of Russiarn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); sprintf(Rec_Buf, "rnI remain, your most faithful serventrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); sprintf(Rec_Buf, "rnBill"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); /*
  • 28. * Once we have finished, we send a CRLF followed by a full stop and * a second CRLF to tell the smtp host we have completed the message, which * will then get queued and sent. */ sprintf(Rec_Buf, "rn.rn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); write_file(LOG_FILE | SCREEN, Rec_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */ write_file(LOG_FILE | SCREEN, File_Buf); sprintf(Rec_Buf, "QUITrn"); err=send(sock,Rec_Buf,strlen(Rec_Buf),0); /* send a quit command */ write_file(LOG_FILE | SCREEN, Rec_Buf); err=recv(sock,Rec_Buf,BUF_LEN,0); /* get response from server */ sprintf(File_Buf,"received: %s", Rec_Buf); /* write to logs */ write_file(LOG_FILE | SCREEN, File_Buf); /* * Off course, if you wanted to use this as a genuine email posting * program, you would use the mail spool file we generated from our * last program, and would pick up the relevent headers to reply. * The message could be edited using a standard text editor, then read * in by this program. We've kept it simple though so you can see exactly * what is happening. */ /* deallocate buffer memory */ free(File_Buf); free(Rec_Buf); WSACleanup(); return 0; } void handle_error(void) { /* Cut and paste in the same error handler as used in the POP program */ } void smtp_error(void) { printf("SMTP Error, Check the Log File for Detailsrnrn"); WSACleanup(); exit(0); } void write_file(int file_type, char *p) { const int LOG_FILE=1; /* write to log file
  • 29. */ const int SCREEN=4; /* display on screen */ if( (file_type & LOG_FILE) != 0 ) /* add to logs */ { FILE *fp=fopen("poplog.txt","a+"); fprintf(fp,"%sn",p); fclose(fp); } if ( (file_type & SCREEN) != 0 ) /* screen */ { printf("%sn",p); } } Okay, let's take a look at the log file (smtplog.txt):- SMTP Session started Wed Mar 29 00:35:41 2000. Connecting to relay.freeuk.net Connected to relay.freeuk.net received: 220 scrabble.freeuk.net ESMTP Exim 3.12 #1 Wed, 29 Mar 2000 00:34:12 +0100 HELO whitehouse.gov received: 250 scrabble.freeuk.net Hello whitehouse.gov [212.126.154.153] 34:12 +0100 MAIL FROM: bclinton@whitehouse.gov received: 250 <bclinton@whitehouse.gov> is syntactically correct 154.153] 34:12 +0100 RCPT TO: gandalf@dhamma.org.uk received: 250 <gandalf@dhamma.org.uk> is syntactically correct 154.153] 34:12 +0100 DATA received: 354 Enter message, ending with "." on a line by itself .153] 34:12 +0100 From: Bill Clinton <bclinton@whitehouse.gov>
  • 30. To: Putin <putin@kremlin.ru> Subject: Congratulations Dear President Putin Congratulations on your recent appointment to President of Russia I remain, your most faithful servent Bill . received: 250 OK id=12a5Uy-0004ku-00 ul servent QUIT received: 221 scrabble.freeuk.net closing connection Using UDP/IP So far we've looked at using TCP/IP, which as I mentioned in part one of the tutorial, is a STREAMING protocol, ie it uses handshaking. You send data and it is acknowledged by the other end prior to you sending more. This way, if packets get lost or become corrupted, the other end can notify you to resend the packet. We're now going to take a look at UDP/IP which is a DATAGRAM protocol. You send out a packet and never bother to check if it gets to it's destination. Obviously this is a less reliable protocol, but is much faster. There aren't too many services running over the Internet using UDP. However, we'll develop an example to illustrate how to use it. I did have in mind using TFTP as an example, but we need to understand the UDP protocol in depth to be able to use this. So, we'll take a simple one. You probably won't find a server out there on the Internet which offer's an echo service, but if you have a Linux Box, then enable port 7 in inetd.conf to try this out. All it does is send a string via UDP/IP and receives an echo of the same string back from the server. Here's the code :- /* * ech.c * * (c) Mar 2000 by Gandalf * * A simple program to illustrate UDP/IP. Server's don't usually * run an echo service as it can be used for DoS attacks. However, * if you have access to a Linux Box, you can enable this service * in your inetd.conf to try it. * */
  • 31. #include <stdio.h> #include <stdlib.h> #include <windows.h> #include <winsock.h> #define WIN32_LEAN_AND_MEAN void handle_error(void); int main (int argc, char **argv) { WORD wVersionRequested; /* socket dll version info */ WSADATA wsaData; /* data for socket lib initialisation */ SOCKET sock; /* socket details */ const int BUF_LEN=100; /* Buffer size for transfers */ struct sockaddr_in address; /* socket address stuff */ int err; /* error trapping */ float socklib_ver; /* socket dll version */ char * Buf; /* send buffer */ char * Rec_Buf; /* receive buffer */ wVersionRequested = MAKEWORD( 1, 1 ); /* * We need to call the WSAStartup routine BEFORE we try to use any of * the Winsock dll calls. */ if ( WSAStartup( wVersionRequested, &wsaData ) != 0 ) handle_error(); /* Check socket DLL supports 1.1 or higher */ socklib_ver = HIBYTE( wsaData.wVersion ) / 10.0; socklib_ver += LOBYTE( wsaData.wVersion ); /* Find out what our maximum IP packet size is for datagrams and allocate * our buffers */ Buf = malloc(wsaData.iMaxUdpDg * sizeof(char) + 1); Rec_Buf = malloc(wsaData.iMaxUdpDg * sizeof(char) + 1); if ( socklib_ver { printf ("nError: socket library must support 1.1 or greater.n"); WSACleanup(); /* clean up before exit */ exit(0); } /* * Open a socket. The AF_INET parameter tells windows we want to use the * internet. Other parameters for different networking can be chosen e.g. * for netbios, IPX etc. The SOCK_DGRAM parameter lets windows know we want * to use UDP rather than TCP, and the final parameter will always
  • 32. be * zero for what we want to do and tells windows to use whatever * default communication protocol has been established (eg PPP and IP) */ if ( (sock = socket(AF_INET, SOCK_DGRAM, 0)) == INVALID_SOCKET ) handle_error(); /* We now need to initialise a couple of variables in the address * structure. Once again, to tell windows we are using the internet, * and also what port we want to use when connecting to a remote * computer. In this case it is port 7 which is the standard port for * echo. The htons routine is used to convert the way Intel chips * store data in memory, which is different compared to many other computers. * The standard is based on Motorola format. */ address.sin_family=AF_INET; /* internet */ address.sin_port = htons(7); /* port 7 for the echo server */ /* * The last example showed using a host name, and used the winsock * dll routine gethostbyname to resolve an IP address. This example * shows how to use an IP address direct using the inet_addr routine. */ address.sin_addr.s_addr=inet_addr("192.168.19.3"); /* Now we're ready to actually connect to the echo server itself */ if ( (connect(sock,(struct sockaddr *) &address, sizeof(address))) != 0) handle_error(); /* * We should be connected to the echo server at this point and whatever * we send to it should be echoed back. We use sendto and recvfrom with * UDP/IP. */ strcpy(Buf, "Hi There Mr Echo!"); printf("nSent: %sn", Buf); err=sendto(sock,Buf,BUF_LEN,0,(struct sockaddr *)&address,sizeof(address)); err=sizeof(address); recvfrom(sock,Rec_Buf,BUF_LEN,0,(struct sockaddr *)&address,&err); printf("nReceived: %sn", Rec_Buf); /* deallocate buffer memory */ free(Buf); free(Rec_Buf); /* Always call WSACleanup before exiting */
  • 33. WSACleanup(); exit(0); } void handle_error(void) { /* Cut and paste in the same error handler as used in the POP program */ } Conclusion and What's Next So, we are moving a bit closer towards programming our own hacking applications. We hopefully fully understand TCP/IP and UDP/IP by now, or at least enough to write our own programs. I fully intended to introduce ICMP at this point with our own versions of PING and TRACEROUTE. However, after developing them, I realised that for the reader of this tutorial to understand how they work would require a greater knowledge of the IP protocol, so we'll be leaving these examples until part three of the tutorial. We will be looking at the IP protocol in depth in the next part of the tutorial. In fact, we will be taking a very deep look at all of the protocols. It's going to be pretty heavy going as we can't really go much further without getting into protocols to a bit level. So get prepared. As usual, we will be presenting a few programs to illustrate this. We will be developing a logging program to watch out for TCP, UDP and ICMP activity on your own computer. We will also expand this further to allow us to monitor the protocols to the bit level. It will eventually grow into a powerful firewall by the end of the tutorial. Hope you're enjoying things so far! As usual, send any greets, complaints or whatever to gandalf@dhamma.org.uk The Rota BlueCrab Ltd
  • 34. RFC's Used in the Tutorial Here's the list of RFC's I used whilst developing the Windows Socket Programming Tutorial. If you really want to get to grips with programming your own Internet applications, you should read them fully. RFC's discuss internet related protocols in great detail. View them online by left clicking the link, or download them by right clicking the link. They are all in text format. The RFC's listed here account for about 5% of all available RFC's. I will eventually be putting the lot online here, along with a document level search facility, something which is sadly missing from most RFC repositories.
  • 35. RFC RFC Title, Author, Date and General Information Number NIC name server - a datagram-based information utility. J.R. Pickens, E.J. Feinler, J.E. Mathis. 756 Jul-01-1979. (Format: TXT=23491 bytes) (Status: UNKNOWN) User Datagram Protocol. J. Postel. Aug-28-1980. 768 (Format: TXT=5896 bytes) (Status: STANDARD) User Datagram Protocol. J. Postel. Aug-28-1980. 768 (Format: TXT=5896 bytes) (Status: STANDARD) Vulnerabilities of network control protocols: An example. E.C. Rosen. Jul-01-1981. 789 (Format: TXT=25541 bytes) (Status: UNKNOWN) Internet Protocol. J. Postel. Sep-01-1981. 791 (Format: TXT=97779 bytes) (Obsoletes RFC0760) (Status: STANDARD) Internet Control Message Protocol. J. Postel. Sep-01-1981. 792 (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950) (Status: STANDARD) Transmission Control Protocol. J. Postel. Sep-01-1981. 793 (Format: TXT=177957 bytes) (Status: STANDARD) Simple Mail Transfer Protocol. J. Postel. Aug-01-1982. 821 (Format: TXT=124482 bytes) (Obsoletes RFC0788) (Also STD0010) (Status: STANDARD) TCP maximum segment size and related topics. J. Postel. Nov-01-1983. 879 (Format: TXT=22024 bytes) (Status: UNKNOWN) Domain names plan and schedule. J. Postel. Nov-01-1983. 881 (Format: TXT=23490 bytes) (Updated by RFC0897) (Status: UNKNOWN) Standard for the transmission of IP datagrams over Ethernet networks. C. Hornig. Apr-01-1984. 894 (Format: TXT=5697 bytes) (Status: STANDARD) Standard for the transmission of IP datagrams over experimental Ethernet networks. J. Postel. 895 Apr-01-1984. (Format: TXT=4985 bytes) (Status: STANDARD) Congestion control in IP/TCP internetworks. J. Nagle. Jan-06-1984. 896 (Format: TXT=26782 bytes) (Status: UNKNOWN)
  • 36. Domain name system implementation schedule. J. Postel. Feb-01-1984. 897 (Format: TXT=15683 bytes) (Updates RFC0881) (Updated by RFC0921) (Status: UNKNOWN) Broadcasting Internet Datagrams. J.C. Mogul. Oct-01-1984. 919 (Format: TXT=16382 bytes) (Status: STANDARD) Domain name system implementation schedule - revised. J. Postel. Oct-01-1984. 921 (Format: TXT=23318 bytes) (Updates RFC0897) (Status: UNKNOWN) Broadcasting Internet datagrams in the presence of subnets. J.C. Mogul. Oct-01-1984. 922 (Format: TXT=24147 bytes) (Status: STANDARD) Internet Standard Subnetting Procedure. J.C. Mogul, J. Postel. Aug-01-1985. 950 (Format: TXT=37985 bytes) (Updates RFC0792) (Status: STANDARD) NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. 954 (Format: TXT=7397 bytes) (Obsoletes RFC0812, RFC0813) (Status: DRAFT STANDARD) Some problems with the specification of the Military Standard Internet Protocol. D.P. Sidhu. 963 Nov-01-1985. (Format: TXT=44019 bytes) (Status: UNKNOWN) Some problems with the specification of the Military Standard Transmission Control Protocol. 964 D.P. Sidhu. Nov-01-1985. (Format: TXT=20972 bytes) (Status: UNKNOWN) Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities 1001 Board, End-to-End Services Task Force. Mar-01-1987. (Format: TXT=158437 bytes) (Status: STANDARD) Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications. NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities 1002 Board, End-to-End Services Task Force. Mar-01-1987. (Format: TXT=170262 bytes) (Status: STANDARD) ISO transport services on top of the TCP: Version 3. M.T. Rose, D.E. Cass. May-01-1987. 1006 (Format: TXT=31935 bytes) (Obsoletes RFC0983) (Status: STANDARD) TCP and IP bake off. J. Postel. Sep-01-1987. 1025 (Format: TXT=11648 bytes) (Status: UNKNOWN) Domain names - implementation and specification. P.V. Mockapetris. Nov-01-1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by 1035 RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2181, RFC2136, RFC2137, RFC2308) (Status: STANDARD)
  • 37. Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network 1069 Protocol. R.W. Callon, H.W. Braun. Feb-01-1989. (Format: TXT=24268 bytes) (Obsoletes RFC0986) (Status: UNKNOWN) ISO presentation services on top of TCP/IP based internets. M.T. Rose. Dec-01-1988. 1085 (Format: TXT=64643 bytes) (Status: UNKNOWN) Standard for the transmission of IP datagrams over NetBIOS networks. L.J. McLaughlin. Feb-01- 1088 1989. (Format: TXT=5749 bytes) (Status: STANDARD) DNS encoding of network names and other types. P.V. Mockapetris. Apr-01-1989. 1101 (Format: TXT=28677 bytes) (Updates RFC1034, RFC1035) (Status: UNKNOWN) Host extensions for IP multicasting. S.E. Deering. Aug-01-1989. 1112 (Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Status: STANDARD) Administrative Domains and Routing Domains: A model for routing in the Internet. S. Hares, D. 1136 Katz. Dec-01-1989. (Format: TXT=22158 bytes) (Status: INFORMATIONAL) Compressing TCP/IP headers for low-speed serial links. V. Jacobson. Feb-01-1990. 1144 (Format: TXT=120959, PS=534729 bytes) (Status: PROPOSED STANDARD) Structure and identification of management information for TCP/IP-based internets. M.T. Rose, 1155 K. McCloghrie. May-01-1990. (Format: TXT=40927 bytes) (Obsoletes RFC1065) (Also STD0016) (Status: STANDARD) TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991. 1180 (Format: TXT=65494 bytes) (Status: INFORMATIONAL) New DNS RR Definitions. C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. Oct-01- 1183 1990. (Format: TXT=23788 bytes) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) Path MTU discovery. J.C. Mogul, S.E. Deering. Nov-01-1990. 1191 (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT STANDARD) Use of OSI IS-IS for routing in TCP/IP and dual environments. R.W. Callon. Dec-01-1990. 1195 (Format: TXT=187866, PS=362052 bytes) (Status: PROPOSED STANDARD) Management Information Base for Network Management of TCP/IP-based internets:MIB-II. K. McCloghrie, M.T. Rose. Mar-01-1991. 1213 (Format: TXT=146080 bytes) (Obsoletes RFC1158) (Updated by RFC2011, RFC2012, RFC2013) (Status: STANDARD)
  • 38. OSI connectionless transport services on top of UDP: Version 1. C. Shue, W. Haggerty, K. 1240 Dobbins. Jun-01-1991. (Format: TXT=18140 bytes) (Status: PROPOSED STANDARD) ICMP Router Discovery Messages. S. Deering. Sep-01-1991. 1256 (Format: TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD) Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations. M.F. Schwartz. Nov- 1273 01-1991. (Format: TXT=19949 bytes) (Status: INFORMATIONAL) A Unified Approach to Inter-Domain Routing. D. Estrin, Y. Rekhter, S. Hotz. May 1992. 1322 (Format: TXT=96934 bytes) (Status: INFORMATIONAL) TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992. 1323 (Format: TXT=84558 bytes) (Obsoletes RFC1072, RFC1185) (Status: PROPOSED STANDARD) The PPP Internet Protocol Control Protocol (IPCP). G. McGregor. May 1992. 1332 (Format: TXT=17613 bytes) (Obsoletes 1172) (Status: PROPOSED STANDARD) DNS NSAP RRs. B. Manning. July 1992. 1348 (Format: TXT=6871 bytes) (Obsoleted by RFC1637) (Updates RFC1034, RFC1035) (Updated by RFC1637) (Status: EXPERIMENTAL) THE TFTP PROTOCOL (REVISION 2). K. Sollins. July 1992. (Format: TXT=24599 bytes) (Obsoletes RFC0784) (Updates RFC1350, RFC1783) (Updated by 1350 RFC1782, RFC1783, RFC1784, RFC1350, RFC1785, RFC2347, RFC2348, RFC2349) (Also STD0033) (Status: STANDARD) An IP Address Extension Proposal. K. Siyan. September 1992. 1365 (Format: TXT=12790 bytes) (Status: INFORMATIONAL) Choosing a Common IGP for the IP Internet. P. Gross. October 1992. 1371 (Format: TXT=18168 bytes) (Status: INFORMATIONAL) Suggestion for New Classes of IP Addresses. P. Robinson. October 1992. 1375 (Format: TXT=16990 bytes) (Status: INFORMATIONAL) The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. November 1992. 1377 (Format: TXT=22109 bytes) (Status: PROPOSED STANDARD) An Experiment in DNS Based IP Routing. C. Huitema. December 1992. 1383 (Format: TXT=32680 bytes) (Status: EXPERIMENTAL)
  • 39. Traceroute Using an IP Option. G. Malkin. January 1993. 1393 (Format: TXT=13140 bytes) (Status: EXPERIMENTAL) Correspondence between the IAB and DISA on the use of DNS. Internet Architecture Board. 1401 January 1993. (Format: TXT=12528 bytes) (Status: INFORMATIONAL) Guidelines for Management of IP Address Space. E. Gerich. May 1993. 1466 (Format: TXT=22262 bytes) (Obsoletes RFC1366) (Status: INFORMATIONAL) The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point 1473 Protocol. F. Kastenholz. June 1993. (Format: TXT=20484 bytes) (Status: PROPOSED STANDARD) A Security Problem and Proposed Correction With Widely Deployed DNS Software. E. Gavron. 1535 October 1993. (Format: TXT=9722 bytes) (Status: INFORMATIONAL) Common DNS Implementation Errors and Suggested Fixes. A. Kumar, J. Postel, C. Neuman, P. 1536 Danzig & S. Miller. October 1993. (Format: TXT=25476 bytes) (Status: INFORMATIONAL) The PPP Internetworking Packet Exchange Control Protocol (IPXCP). W. Simpson. December 1552 1993. (Format: TXT=29173 bytes) (Status: PROPOSED STANDARD) PPP LCP Extensions. W. Simpson. January 1994. 1570 (Format: TXT=35719 bytes) (Updates RFC1548) (Status: PROPOSED STANDARD) Domain Name System Structure and Delegation. J. Postel. March 1994. 1591 (Format: TXT=16481 bytes) (Status: INFORMATIONAL) DNS Server MIB Extensions. R. Austein & J. Saperia. May 1994. 1611 (Format: TXT=58700 bytes) (Status: PROPOSED STANDARD) DNS Resolver MIB Extensions. R. Austein & J. Saperia. May 1994. 1612 (Format: TXT=61382 bytes) (Status: PROPOSED STANDARD) PPP Bridging Control Protocol (BCP). F. Baker & R. Bowen. June 1994. 1638 (Format: TXT=58477 bytes) (Obsoletes RFC1220) (Status: PROPOSED STANDARD) The Point-to-Point Protocol (PPP). W. Simpson, Editor. July 1994. 1661 (Format: TXT=103026 bytes) (Obsoletes RFC1548) (Updated by RFC2153) (Also STD0051) (Status: STANDARD) 1663 PPP Reliable Transmission. D. Rand. July 1994.
  • 40. (Format: TXT=17281 bytes) (Status: PROPOSED STANDARD) ASSIGNED NUMBERS. J. Reynolds,J. Postel. October 1994. 1700 (Format: TXT=458860 bytes) (Obsoletes RFC1340) (Also STD0002) (Status: STANDARD) DNS NSAP Resource Records. B. Manning & R. Colella. October 1994. 1706 (Format: TXT=19721 bytes) (Obsoletes RFC1637) (Status: INFORMATIONAL) DNS Encoding of Geographical Location. C. Farrell, M. Schulze, S. Pleitner & D. Baldoni. 1712 November 1994. (Format: TXT=13237 bytes) (Status: EXPERIMENTAL) Tools for DNS debugging. A. Romao. November 1994. 1713 (Format: TXT=33500 bytes) (Also FYI0027) (Status: INFORMATIONAL) Post Office Protocol - Version 3. J. Myers & M. Rose. November 1994. 1725 (Format: TXT=35058 bytes) (Obsoletes RFC1460) (Obsoleted by RFC1939, STD0053) (Status: DRAFT STANDARD) POP3 AUTHentication command. J. Myers. December 1994. 1734 (Format: TXT=8499 bytes) (Status: PROPOSED STANDARD) IPv4 Option for Sender Directed Multi-Destination Delivery. C. Graff. March 1995. 1770 (Format: TXT=11606 bytes) (Status: INFORMATIONAL) TFTP Option Negotiation Analysis. G. Malkin & A. Harkin. March 1995. 1785 (Format: TXT=3354 bytes) (Updates RFC1350) (Status: INFORMATIONAL) Representation of IP Routing Policies in a Routing Registry (ripe-81++). T. Bates, E. Gerich, L. 1786 Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, & J. Yu. March 1995. (Format: TXT=133643 bytes) (Status: INFORMATIONAL) ICMP Domain Name Messages. W. Simpson. April 1995. 1788 (Format: TXT=11722 bytes) (Status: EXPERIMENTAL) DNS Support for Load Balancing. T. Brisco. April 1995. 1794 (Format: TXT=15494 bytes) (Status: INFORMATIONAL) Requirements for IP Version 4 Routers. F. Baker. June 1995. 1812 (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Status: PROPOSED STANDARD) IP Authentication Header. R. Atkinson. August 1995. 1826 (Format: TXT=27583 bytes) (Status: PROPOSED STANDARD) 1827 IP Encapsulating Security Payload (ESP). R. Atkinson. August 1995.
  • 41. (Format: TXT=30278 bytes) (Status: PROPOSED STANDARD) IP Authentication using Keyed MD5. P. Metzger & W. Simpson. August 1995. 1828 (Format: TXT=9800 bytes) (Status: PROPOSED STANDARD) Whois and Network Information Lookup Service, Whois++. J. Gargano & K. Weiss. August 1834 1995. (Format: TXT=14429 bytes) (Status: INFORMATIONAL) Architecture of the WHOIS++ service. P. Deutsch, R. Schoultz, P. Faltstrom & C. Weider. 1835 August 1995. (Format: TXT=80581 bytes) (Status: PROPOSED STANDARD) Security Considerations for IP Fragment Filtering. G. Ziemba, D. Reed & P. Traina. October 1858 1995. (Format: TXT=20468 bytes) (Status: INFORMATIONAL) SMTP Service Extensions. J. Klensin, N. Freed, M. Rose, E. Stefferud & D. Crocker. November 1869 1995. (Format: TXT=23299 bytes) (Obsoletes RFC1651) (Also STD0010) (Status: STANDARD) SMTP Service Extension for Message Size Declaration. J. Klensin, N. Freed, & K. Moore. 1870 November 1995. (Format: TXT=18226 bytes) (Obsoletes RFC1653) (Also STD0010) (Status: STANDARD) A Means for Expressing Location Information in the Domain Name System. C. Davis, P. Vixie, 1876 T. Goodwin & I. Dickinson. January 1996. (Format: TXT=29631 bytes) (Updates RFC1034, RFC1035) (Status: EXPERIMENTAL) Variable Length Subnet Table For IPv4. T. Pummill & B. Manning. December 1995. 1878 (Format: TXT=19414 bytes) (Obsoletes RFC1860) (Status: INFORMATIONAL) SMTP Service Extension for Delivery Status Notifications. K. Moore. January 1996. 1891 (Format: TXT=65192 bytes) (Status: PROPOSED STANDARD) Common DNS Operational and Configuration Errors. D. Barr. February 1996. 1912 (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status: INFORMATIONAL) Architecture of the Whois++ Index Service. C. Weider, J. Fullton & S. Spero. February 1996. 1913 (Format: TXT=33743 bytes) (Status: PROPOSED STANDARD) How to Interact with a Whois++ Mesh. P. Faltstrom, R. Schoultz & C. Weider. February 1996. 1914 (Format: TXT=17842 bytes) (Status: PROPOSED STANDARD) Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol. F. 1915 Kastenholz. February 1996.
  • 42. (Format: TXT=14347 bytes) (Also BCP0003) (Status: BEST CURRENT PRACTICE) Post Office Protocol - Version 3. J. Myers & M. Rose. May 1996. 1939 (Format: TXT=47018 bytes) (Obsoletes RFC1725) (Updated by RFC1957) (Also STD0053) (Status: STANDARD) Some Observations on Implementations of the Post Office Protocol (POP3). R. Nelson. June 1957 1996. (Format: TXT=2325 bytes) (Updates RFC1939) (Status: INFORMATIONAL) The PPP Encryption Control Protocol (ECP). G. Meyer. June 1996. 1968 (Format: TXT=20781 bytes) (Status: PROPOSED STANDARD) Serial Number Arithmetic. R. Elz & R. Bush. August 1996. 1982 (Format: TXT=14440 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) PPP Link Quality Monitoring. W. Simpson. August 1996. 1989 (Format: TXT=29289 bytes) (Obsoletes RFC1333) (Status: DRAFT STANDARD) The PPP Multilink Protocol (MP). K. Sklower, B. Lloyd, G. McGregor, D. Carr & T. Coradetti. 1990 August 1996. (Format: TXT=53271 bytes) (Obsoletes RFC1717) (Status: DRAFT STANDARD) PPP Challenge Handshake Authentication Protocol (CHAP). W. Simpson. August 1996. 1994 (Format: TXT=24094 bytes) (Obsoletes RFC1334) (Status: DRAFT STANDARD) Incremental Zone Transfer in DNS. M. Ohta. August 1996. 1995 (Format: TXT=16810 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996. 1996 (Format: TXT=15247 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. 2001 Stevens. January 1997. (Format: TXT=12981 bytes) (Status: PROPOSED STANDARD) IP Mobility Support. C. Perkins. October 1996. 2002 (Format: TXT=193103 bytes) (Updated by RFC2290) (Status: PROPOSED STANDARD) IP Encapsulation within IP. C. Perkins. October 1996. 2003 (Format: TXT=30291 bytes) (Status: PROPOSED STANDARD) Minimal Encapsulation within IP. C. Perkins. October 1996. 2004 (Format: TXT=12202 bytes) (Status: PROPOSED STANDARD) 2005 Applicability Statement for IP Mobility Support. J. Solomon. October 1996.
  • 43. (Format: TXT=10509 bytes) (Status: PROPOSED STANDARD) The Definitions of Managed Objects for IP Mobility Support using SMIv2. D. Cong, M. Hamlen, 2006 C. Perkins. October 1996. (Format: TXT=95030 bytes) (Status: PROPOSED STANDARD) TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. 2018 October 1996. (Format: TXT=25671 bytes) (Status: PROPOSED STANDARD) The PPP SNA Control Protocol (SNACP). A. Fuqua. October 1996. 2043 (Format: TXT=13719 bytes) (Status: PROPOSED STANDARD) INTERNET REGISTRY IP ALLOCATION GUIDELINES. K. Hubbard, M. Kosters, D. Conrad, 2050 D. Karrenberg, J. Postel. November 1996. (Format: TXT=28975 bytes) (Also BCP0012) (Status: BEST CURRENT PRACTICE) A DNS RR for specifying the location of services (DNS SRV). A. Gulbrandsen, P. Vixie. October 2052 1996. (Format: TXT=19257 bytes) (Status: EXPERIMENTAL) Domain Name System Security Extensions. D. Eastlake, 3rd, C. Kaufman. January 1997. 2065 (Format: TXT=97718 bytes) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control 2125 Protocol (BACP). C. Richards, K. Smith. March 1997. (Format: TXT=49213 bytes) (Status: PROPOSED STANDARD) ISO Transport Service on top of TCP (ITOT). Y. Pouffary, A. Young. March 1997. 2126 (Format: TXT=51032 bytes) (Status: PROPOSED STANDARD) Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. 2136 Rekhter, J. Bound. April 1997. (Format: TXT=56354 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) Secure Domain Name System Dynamic Update. D. Eastlake. April 1997. 2137 (Format: TXT=24824 bytes) (Updates RFC1035) (Status: PROPOSED STANDARD) TCP Control Block Interdependence. J. Touch. April 1997. 2140 (Format: TXT=26032 bytes) (Status: INFORMATIONAL) U.S. Government Internet Domain Names. Federal Networking Council. May 1997. 2146 (Format: TXT=26564 bytes) (Obsoletes RFC1816) (Status: INFORMATIONAL) A Primer On Internet and TCP/IP Tools and Utilities. G. Kessler, S. Shepard. June 1997. 2151 (Format: TXT=114130 bytes) (Obsoletes RFC1739) (Also FYI0030) (Status:
  • 44. INFORMATIONAL) PPP Vendor Extensions. W. Simpson. May 1997. 2153 (Format: TXT=10780 bytes) (Updates RFC1661, RFC1962) (Status: INFORMATIONAL) Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM). 2163 C. Allocchio. January 1998. (Format: TXT=58789 bytes) (Obsoletes RFC1664) (Status: PROPOSED STANDARD) Referral Whois (RWhois) Protocol V1.5. S. Williamson, M. Kosters, D. Blacka, J. Singh, K. 2167 Zeilstra. June 1997. (Format: TXT=136355 bytes) (Obsoletes RFC1714) (Status: INFORMATIONAL) Resolution of Uniform Resource Identifiers using the Domain Name System. R. Danie1, M. 2168 Mealling. June 1997. (Format: TXT=46528 bytes) (Status: EXPERIMENTAL) Clarifications to the DNS Specification. R. Elz, R. Bush. July 1997. 2181 (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123) (Status: PROPOSED STANDARD) Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July 2182 1997. (Format: TXT=27456 bytes) (Also BCP0016) (Status: BEST CURRENT PRACTICE) Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. 2219 (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST CURRENT PRACTICE) Key Exchange Delegation Record for the DNS. R. Atkinson. October 1997. 2230 (Format: TXT=25563 bytes) (Status: INFORMATIONAL) Mobile-IPv4 Configuration Option for PPP IPCP. J. Solomon, S. Glass. February 1998. 2290 (Format: TXT=39421 bytes) (Updates RFC2002) (Status: PROPOSED STANDARD) Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998. 2308 (Format: TXT=41428 bytes) (Obsoletes RFC1034) (Updates RFC1034, RFC1035) (Status: PROPOSED STANDARD) Domain Names and Company Name Retrieval. J. Klensin, T. Wolf, G. Oglesby. May 1998. 2345 (Format: TXT=29707 bytes) (Status: EXPERIMENTAL) TFTP Option Extension. G. Malkin, A. Harkin. May 1998. 2347 (Format: TXT=13060 bytes) (Obsoletes RFC1782) (Updates RFC1350) (Status: DRAFT STANDARD) 2348 TFTP Blocksize Option. G. Malkin, A. Harkin. May 1998.
  • 45. (Format: TXT=9515 bytes) (Obsoletes RFC1783) (Updates RFC1350) (Status: DRAFT STANDARD) TFTP Timeout Interval and Transfer Size Options. G. Malkin, A. Harkin. May 1998. 2349 (Format: TXT=7848 bytes) (Obsoletes RFC1784) (Updates RFC1350) (Status: DRAFT STANDARD) INTERNET OFFICIAL PROTOCOL STANDARDS. J. Postel, J. Reynolds. September 1998. (Format: TXT=110969 bytes) (Obsoletes RFC2300, RFC2200, RFC2000, RFC1920, RFC1880, 2400 RFC1800, RFC1780, RFC1720, RFC1610, RFC1600, RFC1540, RFC1500, RFC1410, RFC1360, RFC1280, RFC1250, RFC1200, RFC1140, RFC1130, RFC1100, RFC1083) (Also STD0001) (Status: STANDARD)