Email Domain Configuration Management Tool

1. Introduction

• 1.1 Purpose of this document

Description of email configuration tool and requirements. This email configuration tool aims to help systems administrators configure new email domains in a system that uses Qmail with VmailMGR.
 
• 1.2 Scope of this document

This document describes the requirements gathered from the customer (an ISP). The requirements gathered are interpreted and analyzed by the requirements team (John & Balazs) to develop the detailed requirements for the development team (John & Balazs).

The constraints placed on the requirements were that they had to be developed using solely non-MS software. Also, the client's setup includes public and secure email servers, the public server being the global mail exchange accessible from the net, and the secure server being the actual mail server protected by the firewall, that only allows secure connections both in POP3, IMAP and SMTP protocols.
 

• 1.3 Overview

The  Email Domain Configuration Management Tool (EDoCoMaT) aims at providing a user friendly graphical interface to the configuration of a new email domain under Qmail and VmailMGR. Once the user enters the required information for the new domain, the tool is able to generate all the required configuration files both for the secure server and for the public server.
 
• 1.4 Business Context

This is an open source project, sponsored by SourceForge  (sponsored in turn by VA Linux), and by theNewPush. The tool is designed to complement the mail administration tool called oMail-Admin in order to create a new email domain.  One particular advantage of the tool is that it should lead to significant savings on time spent debugging problems with a new domain (eg. fatfingering, forgot to restart qmail, etc.)

2. General Description

• 2.1 Product Functions

jMailConfig creates the required settings for an email domain (derived straight from an internet domain name). The program is responsible for saving and loading the settings and generating the required Unix user.   It initializes the mail domain with VmailMgr, creates the Qmail configuration files and restarts Qmail.
 
• 2.2 Similar System Information

This tool is intended to be used in conjunction with oMail-Admin and VmailMgr. It extends their capabilities by allowing a transparent creation of a new mail domain.
 
• 2.3 User Characteristics

The intended user of this product is a webmaster or systems administrator (e.g. at an ISP). Knowledge of the manual process makes the operation of the tool safer and easier.
 
• 2.4 User Problem Statement

The users currently have to go through a manual process to create new mail domains on both the secure and the public servers. This process involves editing a number of configuration files manually, as well as creating a new Unix user each time. In addition, currently the person creating a new mail domain has to have root access on the secure server.
 
• 2.5 User Objectives

The main goals of the users are:
• Capability of creating a mail domain without having to be the root user
• Simple user interface to generate the config files, with basic integrity checking
• Modular design to be able to add a web interface easily

 
• 2.6 General Constraints

The project needs to implement good software engineering practices:
• Formal Requirements Document
• Object Oriented Design
• Class Diagrams, Association Diagram, Use Case Diagrams, and Statechart Diagrams
• Multi-platform
• Extendable to run different modules on different machines

        1.    Create Qmail configuration files

1. Description

On the secure server, the rcpthosts and the virtualdomains files need to be generated/maintained. On the public server, the rcpthosts and the smtproutes files need to be generated/maintained.
2. Criticality

These files are the core files needed for the QMail and VmailMgr system to know about the domain.
3. Technical issues

Ultimately, a method needs to be defined to get the configuration files onto the remote server.
4. Cost and schedule

1day for basic functionality. 1day for remote file maintenance.
5. Risks

Changes in the file format may delay the project.
6. Dependencies with other requirements

This is the single most important feature. Without this feature, it is not possible to test the rest.

1. Description

On the secure server, the unix user under which this domain will be stored needs to be generated.
2. Criticality

This user is needed for the QMail and VmailMgr system to be able to deliver the mail.
3. Cost and schedule

1day.
4. Risks

Changes in the command line args may delay the project.
5. Dependencies with other requirements

Without this feature, it is not possible to set up the mail domain in VmailMgr.

1. Description

On the secure server, the files required by VmailMgr need to be generated. This is a one time procedure that can be done using the vsetup as the domain user.
2. Criticality

These files are needed for the VmailMgr system to know about the mail boxes of the domain.
3. Technical issues

This utility needs to be run as the mail domain user, on the secure server.
4. Cost and schedule

1day.
5. Dependencies with other requirements

Without this feature, it is not possible to test the mail domain.

1. Description

On the secure server, the QMail service needs to be restarted in order to take the domain changes into account.
2. Criticality

This is only needed if QMail has already delivered mail to that domain, prior to being responsible for the domain. In that case the old info is cashed, and QMail will not recieve email for that domain until it is restarted.
3. Cost and schedule

1day.
4. Risks

Changes in the command line args may delay the project.

4. Interface Requirements

• 4.1 User Interfaces

The first iteration of this product will only have a GUI. The GUI will enable all the operations required by the users in order to set up a new domain.
 
• 4.1.1 GUI

The user interface allows for the easy input of the parameters needed to create the new mail domain.



Description:

• File menu: exit exits the application
• Help menu: about displays info about this application
• Open File button: for future use, to open a mail domain configuration
• Save File button: saves the configuration of a mail domain (not the password)
• Domain Name: fully qualified domain name (FQDN) of the mail domain
• Domain User Name: the Unix user that controls the mail domain
• Domain User Password: the password of the Unix user
• Confirm Password: the same password must be entered twice
• Public Mail Server Name: FQDN of the public mail server
• Public Mail Server IP Address: IP address of the public mail server
• Secure Mail Server Name: FQDN of the secure mail server
• Secure Mail Server IP Address: IP address of the secure mail server
• Install button: starts the process to create the new mail domain
• Exit button: exits the application

 
• 4.1.2 CLI

No command line interface available in this version
 
• 4.1.3 API

MailDomainInfo is the main class that delivers the functionality. The attributes that are required to create a new mail domain are made public. A developer that needs to incorporate in its application the feature of creating new mail domains needs to:
• Instantiate a MailDomainInfo object
• Set the attributes: domainName, domainUserName, domainUserPassword, publicMXName, publicMXIP, secureMXName, secureMXIP
• call the generateConfigFiles() method

 
• 4.1.4 Diagnostics or ROM

Debugging info can be obtained by looking at standard error, and saving the domain configuration file.
 
 
• 4.2 Communications Interfaces

A future version will use RMI to connect to the remote public server to create its configuration files locally.
 
• 4.3 Software Interfaces

No other software interfaces are planned at this point.

5. Performance Requirements

The system should use no more than 64Mb RAM.

• 6.1 Standards Compliance

The system should work with Linux RedHat 6.2 and up. It should respect the POSIX standard for the system tools used.
 
• 6.2 Hardware Limitations

The system needs to support the Intel x86 platform. Future versions may have to support the IA-64 architecture.

7. Other non-functional attributes

• 7.1 Security
• 7.2 Binary Compatibility
• 7.3 Reliability
• 7.4 Maintainability
• 7.5 Portability
• 7.6 Extensibility
• 7.7 Reusability
• 7.8 Application Affinity/Compatibility
• 7.9 Resource Utilization
• 7.10 Serviceability
• ... others as appropriate

8. Preliminary Object-Oriented Domain Analysis

• 8.1 Inheritance Relationships

This section should contain a set of graphs that illustrate the primary inheritance hierarchy (is-kind-of) for the system. For example:



• 8.2 Class descriptions

This section presents a more detailed description of each class identified during the OO Domain Analysis. For more details on the process giving rise to these descriptions, see Lecture 5.3: OO Domain Analysis and/or texts on object-oriented software development.

Each class description should conform to the following structure:

1. 8.2.1 <Class name>
1. 8.2.1.1 Abstract or Concrete:

Indicates whether this class is abstract or concrete.
2. 8.2.1.2 List of Superclasses:

Names all immediate superclasses.
3. 8.2.1.3 List of Subclasses:

Names all immediate subclasses.
4. 8.2.1.4 Purpose:

States the basic purpose of the class.
5. 8.2.1.5 Collaborations:

Names each class with which this class must interact in order to accomplish its purpose, and how.
6. 8.2.1.6 Attributes:

Lists each attribute (state variable) associated with each instance of this class, and indicates examples of possible values (or a range).
7. 8.2.1.7 Operations:

Lists each operation that can be invoked upon instances of this class. For each operation, the arguments (and their type), the return value (and its type), and any side effects of the operation should be specified.
8. 8.2.1.8 Constraints:

Lists any restrictions upon the general state or behavior of instances of this class.

9. Operational Scenarios

In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows:

In the broad sense, a scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use case, which consists merely of a short description with a number attached. More detailed forms are called scripts. These are usually represented as tables or diagrams and involved identifying an action and the agent (doer) of the action. For this reason, a script can also be called an action table.

Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because they describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.

10. Preliminary Schedule

The project plan should be accompanied by one or more PERT or GANTT charts.

11. Preliminary Budget

12. Appendices

Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:

• 12.1 Definitions, Acronyms, Abbreviations

Provides definitions of unfamiliar definitions, terms, and acronyms.
• 12.2 References

Provides complete citations to all documents and meetings referenced or used in the preparation of this document.