-
Notifications
You must be signed in to change notification settings - Fork 4
Configuration
Configuration of Idlemail is done using a json configuration file. For a complete example configuration file, have a look at exampleconfig.json.
The overall structure of the configuration file is:
{
"destinations": {
// Map of <destination name> to <configuration>
"<destination name>": {
type: "<destination_type>",
// config
}
},
"sources": {
// Map of <source name> to <configuration>
"<source name>": {
type: "<source_type>",
// config
}
},
"mappings": {
// Mappings that encode, to which destination the mails of which source are forwarded
"<source name>": [
// list of
"<destination name>"
]
},
"retryagent": { // optional
// Configure the RetryAgent, which will try to re-schedule mails
// that were not sent, e.g. due to a temporary Destination failure
}
}
Sources are (as the name states), the sources for incoming mails. Idlemail currently supports the following source implementations:
-
ImapIDLE (
imap_idle)Source using the IMAP protocoll with its IDLE extension. (Mail-server notifies us about new mails)
-
ImapPoll (
imap_poll)Source using the IMAP protocoll by regularly polling the configured mail server for new mails.
Destinations are (as the name states), the destinations, to which the mails retrieved through the sources should be delivered. Idlemail currently supports the following destination implementations:
-
Smtp (
smtp)Destination using the SMTP protocoll to deliver retrieved mails to your mail server.
-
Exec (
exec)Destination that delivers retrieved mails to a local binary on the machine running Idlemail.
RetryAgents are an optional concept Idlemail employs to avoid loosing mails on transmission errors. When a mail is fetched by a source, it's gone on the source's side. If sending by the destination then fails, the mail will be permanently lost. However, when a RetryAgent is configured, a mail that fails to send will be stored there and queued for re-transmission.
Currently implemented RetryAgents are: