Foomail Components:
Foomail is the cheezy name I've given to this E-mail client implementation. The goals of the foomail implementation include:

• Provide good error logging
• Ensure that SMTP limits are not exceeded.
• Ensure that multiple addresses are not sent the same email.

Foomail components are diagrammed below, and summarized below the diagram. Click a component on the diagram for further detail.


I've recorded some of the flaws in this implementation here.

Quick Ref:

• class EmailEnvelope
  - this is the "electronic envelope" that contains the message to be sent. Class email envelope is not concerned with any of the headers or the format of the actual message data, but only with transfering the message.
• class EmailContents
  - the email message itself. This contains the headers and the message body. This class is supposed to manage the format of the message data, but really just makes sure that header lines are not too long, and folds them if so.
• class Email Header
  - this is a header of the message, such as a memo header. Examples are "To:", "From:", "Subject:", and many others. Headers with their syntaxes are defined in RFC 822.
• class EmailAddress
  - is an email mailbox address such as "foo@foo.foo". This class is used mainly to parse email addresses into their constituent alias, user, and host names.
• class EmailAddressList
  - this is a list of email addresses. The internal representation is not a list of class EmailAddress though, it is a list of class EmailAddressListNodes. Each EmailAddressListNode represents a particular host, and has its own list of users at that host. Therefore, each user at a particular host are sorted, and then each group of users at a host is sorted by the host name.
• class EmailError
  - class representing an error that occured while sending an email. This class includes an error message, the response code it got from the server which caused the error if applicable, and an internal error code.
• class EmailErrorList
  - a list of class EmailErrors. There is not really much else to say about this, but check it out anyways if looking for any methods related to errors.

Garbage Notes:

• Every EmailEnvelope has one EmailContents instance and one EmailAddressList instance, both alread allocated. Whenever the EmailEnvelope is deleted, it also deletes its EmailContents and its EmailAddressList objects too.
• Every EmailContents instance manages the EmailHeaders that it has reference to. In other words, when a EmailContents is deleted, it deletes all the EmailHeaders that have been added to it.
• Whenever an EmailAddressList is deleted, all associated memory is also deleted. Class EmailAddressList does not actually keep any references to class EmailAddress, but rather stores the addresses in an internal form so that they can be more easily sorted by host name. Also, understand that this means any information passed to an EmailAddressList will be copied, and it is still the responsibility of the caller to manage the memory afterwards.
• When an EmailErrorList is deleted, all the EmailErrors that it contains will also be deleted. The caller of the EmailEnvelope::sendMail() method must make sure to check if an EmailErrorList is returned, and if so, must delete it.