Documentation

This documentation is being created as we speak...sort of!

1. Installing Rumble
   1. Installing Rumble for Windows
   2. Installing Rumble on UNIX platforms
2. Configuring Rumble
   1. Directives in rumble.conf
3. Bundled modules
   1. Greylisting module
   2. Whitelisting module
   3. Blacklisting module
   4. SpamAssassin module
   5. Foreman module
   6. TLS module
4. Managing your server:
   1. Managing domain names
   2. Managing email accounts
   3. Managing modules
5. Writing your own modules for Rumble

 

Installing Rumble

Installing Rumble for Windows

Installing Rumble on a Windows operating system is quite simple. Download the latest installer for Windows and run it. On a regular Windows installation, Rumble will probably install itself inside the folder C:\Program Files\Rumble. If you choose to have Rumble run as a Windows service, you can proceed directly to the RumbleLua web interface and configure your mail server. Otherwise, you can manually configure the mail server by editing the configuration files found inside the [install path]\config folder.

Installing Rumble on UNIX platforms

The optimal way of installing Rumble on UNIX platforms (Linux, FreeBSD etc) is to download and compile the source code. The source code packages found on the sourceforge web site will also compile and install the modules bundled with the Windows version of Rumble.

In order to compile Rumble from scratch, you will need to install the development files and runtime libraries for the following programs:

• Lua 5.1 or 5.2
• libopenssl 0.9 or higher
• libgnutls
• libsqlite3 and optionally libmysqlclient
• libresolv

If any of these libraries or programs are missing, the installer script will of course let you know.

Once you've gotten the libraries installed, simply run the included installer file, compile.sh (using bash), and the program will be compiled for you.

When the compiling has finished, the entire mail server suite will be available in the build directory, and can be moved whereever you like. If you wish to move the executable to fx. /usr/bin, but have the rest of the configuration files, modules and mail storage located elsewhere, you can let rumble know by using the --config-dir parameter, fx:
/usr/bin/rumble --config-dir=/etc/rumble/config

 

Configuring Rumble

Directives in rumble.conf

• ServerName: Sets the name of the server. This name is used for MTA greetings, and should be set to the real hostname of your mail server.
   
• DatabaseEngine: Sets the database engine to use. By default, Rumble uses the SQLite3 database engine to manage its domains, accounts and messages, but you can set it to use MySQL as well.
  
  
• DataFolder: If Rumble is using SQLite3, this directive tells Rumble where the database files are located. The specified folder should be readable and writable by Rumble.
  
  
• StorageFolder: Sets the folder, in which all messages should be stored by default. Each domain can have its own specific storage folder set individually, but Rumble will default to the folder in this directive if a domain does not have an individual folder set. As with the DataFolder directive, the folder specified here should be readable/writable by Rumble.
  
  
• TempFolder: Sets an optional temporary folder for new messages to be placed in before they are parsed and shipped out to their respective email accounts. This folder can be the same as the StorageFolder.
  
  
• ForceIPv4: If you run Rumble on a system that defaults to IPv6 standards, you can set this directive to 1 to force Rumble to use IPv4 instead.
  
  
• BlockOutgoingMail: If set to 1, all outgoing mail requests will be denied. You can use this directive if you only wish for your server to recieve mail and not relay or send any mail itself.
  
  
• EnableSMTP: Specifies whether or not to enable the SMTP service. You should probably not touch this directive unless you have a good reason to.
  
  
• SMTPPort: Sets the port at which the SMTP service will operate. Default is port 25.
  
  
• MessageSizeLimit: Sets the maximum allowed message size for any incoming messages (in bytes). The default value, 104857600, allows messages of 100MB or less to pass through.
  
  
• IgnoreMX: A list of fake MX records that are commonly used to block mail for certain domains. You don't need to specify anything here, but the default value will save your server some time that would otherwise have been wasted trying to contact bogus mail servers.
  
  
• EnablePOP3: Specifies whether or not to enable the POP3 service. If you're only interested in running an SMTP service, you should turn this directive off.
  
  
• POP3Port: Sets the port at which the POP3 service will operate. Default is port 110.
  
  
• EnableIMAP4: Specifies whether or not to enable the IMAP4v1 service.
  
  
• IMAP4Port: Sets the port at which the IMAP4v1 service will operate. Default is port 143.
  
  
• LoadScript: Loads and runs the specified Lua script. You can use this directive to create your own Lua modules or run the bundled ones.
  
  
• LoadModule: Loads the specified .so or .dll module.

Bundled modules

Rumble comes with a set of pre-compiled modules in C and Lua that takes care of 99% of all users' needs for mail server extensions. Most modules can be configured through the web-based interface, or through their respective configuration files in the /config/ folder.

 

Greylisting module

Greylisting is the act of intentionally delaying the receipt of emails by pretending that the mail server is unable to handle a specific SMTP request at the given time. The intention of this is to prevent emails from poorly-written spam-bots while allowing real emails to get through.

For more information on greylisting, visit fx. http://www.greylisting.org

 

Whitelisting module

The whitelisting module does the opposite of the greylisting and blacklisting modules; It allows certain pre-defined hosts to deliver emails immediately, without going through a quarantine phase. As some well-known email account suppliers, fx. yahoo, have mail servers that don't conform to the SMTP standards, it is necessary to allow these servers to deliver emails nonetheless....which is what the whitelisting module takes care of :)

 

Blacklisting module

The blacklisting module handles checks for either sender addresses or server hosts that should never be allowed to send emails to your server. This is done through a pre-defined set of non-allowed email addresses and hosts, as well as a real-time query with the DNS blacklisting providers around the world. If someone is spamming other servers, there's a 99.9% chance the blacklisting module will know about it.

 

SpamAssassin module

For information on SpamAssassin, see http://spamassassin.apache.org

 

Foreman module

The foreman module dynamicly scales each server component to match the current load. If any server (SMTP, POP3, IMAP etc) receives a big influx of emails or requests to check email accounts, the foreman module will expand the worker pool of said service. When the load goes down again, the module will shrink the pool back to its original size.

 

TLS module

The TLS module provides support for the STARTTLS command on the POP3, IMAP4 and SMTP servers. This is used for secure communication between client and server.