eMail Broadcast freeware for home office personal PC Bounce email manager freeware
for returned emails

STOP SPAM
Free2Try easy
to use anti-spam

Home

<<back to>>
eMail Bolts
& Nuts

  

Google

Email messages are text files formatted to specifications
outlined in RFC documents that describe how messages
should be formatted and systems communicate with each other...

 


Emailing in a nutshell

 

Email Message Format

A variety of data like; sound files, images and other binary information, etc., are included into email messages--which can be formatted by adding specific descriptions to all parts of the message.

For example; messages composed in "rich text" or HTML format may include WAV sound, GIF images attachment, etc.--the message will consist of 3 parts, so that a mail reader (MS Outlook or Eudora, etc.) can display the message in "rich text" or HTML with the image and play the sound WAV file--which are not included in normal email messages.

Hence, a standard format known as MIME (Multipurpose Internet Mail Extensions) has been created to describe the message parts and mail program conforming to this standard will be able to describe its own messages and interpret messages created by other systems.

 

(MIME)
Multipurpose Internet Mail Extensions

MIME encoded messages consist of many parts--each part is allowed to be described in detail and some parts encoded. The purpose of MIME is to describe the many parts of an email message, such as attached sound files and images.

MIME messages may include a plain text message and a GIF image--because GIF image is binary data consisting of 8 bit characters. To get the GIF image data to pass through the Internet--Base 64 is used to encode the data into 6-bit characters.

MIME is also used to annotate part of a message so that the receiving mail reader will know what data is stored in the message and process it optionally, ie; instead of listing the GIF file as a generic attachment--may automatically display it instead.
 

  

   

Message Encoding Binary data

Message encoding binary data is often represented by 8 bit characters and some computers on the Internet are unable to transfer data represented by 8 bit characters. Therefore, the encoding process must convert 8 bit characters into smaller characters for sending across the Internet and then re-convert back to 8 bit characters by the receiving computer.

Base 64, UUencode and Quoted Printable are the most popular (there are several types of data encoding). Since many Internet email infrastructure was not designed to handle email messages containing binary information like file attachments--they are converted into a format that is compatible with computers on the Internet and this conversion process is called encoding.

Base 64 is generally used to encode binary attachments with MIME formatted messages and transforming 8 bit characters into 6 bit characters--which are compatible with the Internet infrastructure (will approximately increase data size to 130%) compared to the original.

UUencode (Unix to Unix) is an older form of data encoding that transforms 8 bit data into characters that are compatible with the Internet infrastructure. And most mail systems that support Base 64 are also backwards compatible with Uuencode--which can only be understood by some older mail systems.

Quoted Printable encoding is suitable when small portions of the message data are stored into 8 bit characters, usually for text message that consists of characters less than 8 bits--normally for the message body text.

Quoted Printable encoding is designed to transform 8 bit characters into characters compatible with the Internet, similar to Uuencode or Base 64 -- the difference is that “Quoted Printable” does not convert all the characters of the message, it only transforms characters which use more than 7 bits and any 8 bit characters are split into two or three smaller characters.


 

RFC-822 Message Structure

Email messages are text files formatted to specifications outlined in RFC 821 (Request For Comment) documents, that describes in detail how messages should be formatted and how systems should communicate with each other by following these guidelines.

An email message has the following parts: RFC-822 Message Header and Message Data

RFC-822 Message Header is the first part all email messages, it specify the many options of the message and includes the subject line and headers are not required to be placed in any particular order. A MIME formatted message may contain many parts and each part may contain its own header and in the message data section.

Example of a Message Header:

Reply-To: "Service" <service@bouncemailmanager.com>
From: "Tony" <service@bouncemailmanager.com>
To: "Wendy" <support@mailsbroadcast.com>
CC: "CEO" <ceo@mailsbroadcast.com>
Subject: I am getting too many bounce mails.
Date: Mon, 11 Nov 2002 12:38:23 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 1
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
 
Reply-To: This is the specified email address that the sender wants the recipient to “Reply-To:” instead of the “From:” email address.
 
From: The “From:” email address in the header is allowed to be different from the email address that actually sent the message.
 
To: Message to be sent to that particular recipient.
 
CC: Send a carbon copy of the message to...
 
Subject: Message subject of the email.
 
Date: Indicates the date and time of the message created and a reference to the time zone used to calculate the date and time.
 
MIME-Version: Indicates the version used for MIME encoding of the message.
 
Content-Type: Header is only used with MIME messages--to declare the general type of data and the subtype specifies a format for that type of data. For example: Content-Type: of "text/plain"--inform the user agent that the data is in plain text format. The optional “charset” parameter tells the mail reader that the message is intended to be displayed with the "iso-8859-1" character set.
 
Content-Transfer-Encoding: Header is only used with MIME messages to specify an auxiliary encoding that was applied to the data, so that it is allowed to be to pass through the mail transport mechanisms--which may have data or character set limitations.
 
Custom Headers (X-* Type): Headers with an “X-“ are added by the program that created the message and can be read by a mail reader, therefore, any special format specification or information contains in the message—can be taken advantage of—and ignored, if it is not recognized by a mail reader.
 
X-Priority: Custom header is quite popular but different mail readers may interpret it differently or not at all. For example: usually most mail readers set or interpret "4"=low "3"=normal and "1"=high
 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Message Data following after the message headers is the “Message Data”--the composed message body text and any file attachment information. Below here is an example of a message body without files attachments:

I need further information about bounce mail manager,
 please send it to service@mailsbroadcast.com 
Thank you :)
--
TonyKoh
mailsbroadcast.com
http://www.mailsbroadcast.com
. <<<This period indicates the end of the message.
 
 

Example of a message with GIF file attachment encoded with MIME and “Quote Printable” message body (GIF encoded with Base 64) preceded by an attachment header, which preceded all attachments--describing various properties of the attachment.

This is a multi-part message in MIME format.
------=_NextPart_000_0051_01BD9B7E.F01FEA90
Content-Type: text/plain;charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message text.
--
TonyKoh
BounceMailmanager.com
http://www.bouncemailmanager.com
------=_NextPart_000_0051_01BD9B7E.F01FEA90
Content-Type: image/gif;name="welcome.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;filename="welcome.gif"
R0lBOClhAwALAKEVVN//// 6VVNUaGgFFFCH5BAEAA
AAALAAAAADAAsAAAYJhH6tauygkFSFACs=
------=_NextPart_000_0083_01CF9B5S.B01ZWA70--
. <<<This period indicates the end of the message.
 
 

Mail Servers Protocol

The most common protocols used by mail server to communicate with the Internet are SMTP, POP3 and IMAP4 to (send) receive email messages and distribute and them into different recipient unique mailbox.

Mail servers receive messages via SMTP and email readers must send email to a mail server using it. Mail servers using POP3 or IMAP4 to send messages, likewise; mail readers must use it to receive messages from the mail servers.

SMTP (Simple Mail Transport Protocol); for sending and receiving email messages and POP3 (Post Office Protocol Version 3); for delivering and retrieving email messages to mail readers, example: MS Outlook, Eudora, etc.

IMAP4 (Internet Message Access Protocol Version 4); for delivering messages to mail readers or to preview and retrieve emails from mail servers.

 

(POP3) Post Office Protocol Version 3

POP3 is a standard client-server protocol for receiving emails. The POP3 mail servers listen for email requests via port 110 and send email to the requesting party. The client side (ie: Outlook, Eudora) mail readers can access (retrieve) emails by issuing a predefined set of commands to the mail server.

A POP3 session is created when a remote user connects to a mailbox on the POP3 mail server and ends when the remote user disconnects from it. While a session is open, no other user can retrieve email from the POP3 mailbox but email can still be sent to that account.

The POP3 clients (Outlook, Eudora) login to the POP3 server by sending as clear text the password for the mail account or uses APOP authentication--where the password itself is not sent to the remote mail server--using a digest created by the RSA MD5 algorithm--based on the password with a unique value sent by the POP3 mail server—that changes with connection. Therefore, APOP ensures that a different digest will be sent each time you log into the server.

 

(IMAP4)
Internet Message Access Protocol Version 4

IMAP4 is an alternative to POP3 for retrieving emails that operate via server port 143 that identify users by account name and password. IMAP4 protocol was designed to allow messages to be managed on the server. Since the messages remain on the server, the protocol is useful for users to access emails from various client computers.

IMAP4 server stores messages in different mailboxes. More than one user is allowed to access to an IMAP4 mailbox, therefore allowing mailboxes to be shared by multiple users.

 

 


 

.

 


 


(SMTP)
Simple Mail Transport Protocol

SMTP is a protocol governing electronic mail transmission and reception. A conversation is established with a SMTP server via port 25 --After the initial connection, the client ie: Eudora Mail, Outlook Express, etc. sends a HELO command followed by the domain name, telling the SMTP server whom it is talking to. The SMTP server may terminate the connection if it does not wish to speak to the specified domain.

If the HELO command is accepted by the remote server, the SMTP client issues a MAIL-FROM command followed by the FROM: address, at this point the SMTP server may terminate the connection if it does not wish to speak to the specified domain.

After the FROM address is accepted, the SMTP client issues a RCPT-TO command followed by the address of the intended recipient--the SMTP server may terminate the connection if it does not wish to speak to the specified address, example: non local.

The SMTP client issues the DATA command to the server and if accepted--it then send the message headers followed by blank line and the message body, file attachment and finally followed by a period to end the message--the SMTP server acknowledges receipt--and the SMTP client send a QUIT command and terminate the conversation.

 

Extended SMTP
ESMTP consists of several extensions (all optional) to the basic SMTP protocol which may or may not be supported by mail servers. Whereas, normal SMTP involves several fragments of data being sent from the client to the mail server and after each fragment is sent, the client waits for the mail server acknowledgement reply and then the client sends the next fragment, and so on. Therefore, a time is wasted while waiting for the server to return a response.

Pipelining extension
Pipelining can send messages faster by allowing the client to batch several fragments of data together and sending them all at once, and the server only need to acknowledge with one reply for the combined set of data. Since the fragments and acknowledgements are combined, the client spends less time waiting for the server to respond.

Delivery Status Notifications
DSN extension supported SMTP servers allow greater control of the notification process by specifying when and how notifications are sent. DSN extensions also allow for an "Envelope ID" to be included in the outbound message, which is returned as a MIME part of the delivery status notifications--therefore, allowing client applications to match delivery status notifications to the original message.

An example MIME part to a DSN message with the Envelope ID specified as 3112394 

--FAA10845.816082428/mail.domain.com
Content-Type: message/delivery-status
 
Original-Envelope-Id: 3112394
Reporting-MTA: dns; mail.domain.com
Received-From-MTA: DNS; tony.bouncemailmanager.com
Arrival-Date: Tue, 10 Dec 2002 12:37:15 -0900 (EST)
 
Original-Recipient: rfc822;tony@bouncemailmanager.com
Final-Recipient: RFC822; xxx0021@mail.domain.com
Action: delivered (to mailbox)
Status: 2.1.5
Last-Attempt-Date: Tue, 10 Dec 2002 12:37:43 -0900 (EST)
 
-- FAA10845.816082428/mail.domain.com
 
 

 

  

  

Any feed-back or suggestions? Please Drop us a note


Art of eMail CRM | eMail Bolts&Nuts

Home | Contact Us | Privacy Policy | Guest Book | Useful Sites

Support | Purchase | Product Info | Download Bounce eMail Manager Freeware
Line with surfer
©Copyright June 2002  Permission to re-print, please click here