ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Bumblebee's guide to Simple Mail Transfer Protocol ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ INDEX 1. Overview 2. Syntaxis 3. Client messages 4. Server messages 5. Practice 6. Experience 1. Overview ÄÄÄÄÄÄÄÄÄÄÄ SMTP it's a protocol independent of the transmission subsystem and requires only a ordered communication channel. This mean we cannot use UDP but TCP. The SMTP defines a way of 'speak' with servers and send, receive and manage mail and mail sessions. This little guide explains how to send a mail using this protocol and some tricks you can use in the process. Most of this information can be found in the internet RFC821. Moreover there are some tips you can get only from the experience. This is a guide and the full information of the protocol is not avaliable but the needed to send a mail succesfuly. 2. Syntaxis ÄÄÄÄÄÄÄÄÄÄÄ Here follows a little brief of the different messages that can be used by the client and the server. Notice that is very important to put spaces only where required 'cause so old SMTP servers could have lame implementations and could be possible the server doesn't process the message. Client messages: [CRLF] := pair of character equal to 0dh,0ah (0a0dh) [string] := vector of character without special chars [host] := string between < > '' [address] := e-mail address between < > '<29a@bumblebee.net>' [multi-line] := different strigs separated by [CRLF] HELO [host][CRLF] MAIL FROM:[address][CRLF] RCPT TO:[address][CRLF] DATA[CRLF] [multi-line] [CRLF].[CRLF] QUIT[CRLF] Server responses: Some particular: 220[CRLF] := Service ready 250[CRLF] := Requested action okay 221[CRLF] := Closing transmission 251[CRLF] := Fowarding mail 354[CRLF] := Start main input Some general: (use * as wild card: char from 0 to 9) 4**[CRLF] := Not error but fail. Retry. 5**[CRLF] := Error. Better disconnect! 3. Client messages ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ HELO [host][CRLF] It's used to identify the client. This is not needed i all the servers but it's a good idea to include it. If you don't use it and it's needed the server will ask you for it when you perform other operation. Most of the servers will not check this host. Server ever knows the address of the client so include it and don't use a fake address. Server answers message 250 if all it's ok. MAIL FROM:[address][CRLF] This begins the 'send mail' process. The address required by MAIL FROM can be different from client address and host used by HELO. This is an interesting point 'cause you can put here the fake address you want, www.microsoft.com as example ;) Some servers only allows addressed of registered users in its domain, but this is not very frequent. This command will return message 250 if all it's ok. This command must be followed by RCPT TO and DATA. RCPT TO:[address][CRLF] This lets know the server the destination recipient of the mail. This address MUST be a right address if you want the mail arrives ;) If the servers supports fowarding the address doesn't needs to be owned by the server. This is in most cases. This command will return message 250 from server if fowarding not needed and 251 if the recipient account is not in the server. This command must be after MAIL FROM and must followed by DATA. DATA[CRLF] [multi-line] [CRLF].[CRLF] This is a non-simple message. Begins with a DATA command that lets know the server we are going to send the body of the mail. If all goes ok, previous right use of MAIL FROM and RCPT TO, the server answers 354 and waits the mail input. The mail input is a multi-line entry that must be finished with [CRLF] dot [CRLF], without spaces between [CRLF] and the dot. If all is ok the sever will answer 250. In most cases the mail is processed just now, but in other cases the server will wait until you send the QUIT message. QUIT[CRLF] This is used to close the session with the server. This command ends with disconnection and with the 221 response. Notice that several servers wait until you close the session to process the mail to make sure you close the session in the right way, not closing the connection in dirty way. 4. Server messages ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Server messages could change from one to another implemetation of the protocol. There are servers that follow the reply code with a space and other use a minus sign. Moreover the strings that gives u a little description of the reason of the reply code could be in any lenguage and format. Don't rely on them. You must only take into account the three first bytes of the reply, thus the code that is in ASCII format. But remember the SMTP session is connection oriented 'cause the order of the messages is important. You must read the whole reply message until the [CRLF]. 5. Practice ÄÄÄÄÄÄÄÄÄÄÄ The simplest way to practice this protocol and understand it is using a telnet client to connect with a SMTP server and send your first mail. The SMTP server are listening port 25. So you can connect by: telnet smtp.server.dom 25 Try with a server that has SMTP. Most web based mail systems have an address different of the one you use to send mail, so this could not be a good idea. But test it simply connecting to port 25. Try with mail.hotmail.com (not www.hotmail.com cause this is for HTTP), but i'm not sure if it will work. We are going to assume you connected without problems. Let's use C for client and S for server. This could be your session: S: 220 SMTP.SERVER.DOM Simple Mail Transfer Service Ready C: HELO S: 250 Hello bumblebee.net! C: MAIL FROM: S: 250 OK C: RCPT TO: S: 251 User not local; will forward to support@avp.com C: DATA S: 354 Start mail input; end with . C: Hi AVP people! C: Are you Anti Viral Perverts? C: . S: 250 OK C: QUIT S: 221 SMTP.SERVER.DOM Service closing transmission channel Simple, isn't it? Make different tests. Now you only need to code your own engine! 6. Experience ÄÄÄÄÄÄÄÄÄÄÄÄÄ There are some things the official documentation doesn't say and you must take into accout to avoid problems: . The only one reliable part of the reply message of the server are the three first bytes in each reply. There is a rule that allows modern servers to have milti-line replies. That's using the - sign after the code of reply. Last line will not have it: S: 220-SMTP.SERVER.DOM Simple Mail Transfer Service Ready S: 220-That's an exaple of milti-line reply S: 220 Ready to rock! . In big networks could be that the SMTP server to send mails is not the same that for incoming messages. . The web based mail could give problems like the previous point. You can try to send a mail to bee@easymail.com by the connection to easymail.com. This is the simplest way 'cause with one address you have the server to send and the address for the destination. The problem could be there is not a 25 port avaliable listening for connections. . The server will fill some fields in the mail for you. These are usualy the fowarding address (if avaliable), the host of the client (not necessary equal to sender address), and in some cases the date if is not filled by the sender. . You need to implement a standard format for the mail if you want to send a file (hehehe). May be MIME 1.0 it's the best solution. Keep in mind the previous point filling this data. . Don't assume you are coding something 100% compatible, there is a implementation in a server waiting to fuck your client ;) That's all. I hope you've found this article interesting and useful. The way of the bee