gromox.cfg(5)

Name
gromox.cfg — Central configuration file for Gromox services

Description
The common configuration file utilized by all services. Historically, each service had separate configuration files, but the number of directives that needed explicit configuration were reduced over time to the point that there were too many distinct files for little value, and so, gromox.cfg came to be.

Configuration directives

This manpage does not describe all possible directives. Please also consult the manpages of gromox daemons and command-line utilities for more.

autoreply_silence_window
    If an autoreply message (other than a bounce report, e.g. out-of-office) is to be generated, that return message will be suppressed if another autoreply for the given {From, To} address pair was produced within the given time period previously. (Unlike the response_audit_capacity directive, autoreply pairs are stored persistently, in the message database.)
    Default: 1day

backfill_transport_headers
    Try to fill the PR_TRANSPORT_MESSAGE_HEADERS property when messages are submitted. Turning this option on requires extra storage (usually between 0.5KB and 1KB per sent message). Transport headers for sent messages can be generated on the fly from the regular MAPI message data structures e.g. via gromox-export(8) for analysis, so unless there is a need to retain the results from older generator versions, you should leave this off.
    Default: off

bounce_postmaster
    This directive defines the Envelope-From and From addresses for system-generated bounce messages such as Non-Delivery-Reports (autoresponse messages about e.g. mailbox being full, or a target email address being invalid). RFC-5321-5322-consuming components like SMTP, IMAP and EAS want to have an SMTP-looking address in this field. Preferably, it should point to the administrator's mailbox (or an alias thereto).
    When the value set here has no domain part and ends in just '@', the domain is taken from a re-resolution of the system hostname (so as to cope with an unqualified hostname in /etc/hosts that many system installations use).
    Default: postmaster@

lda_junk_rules
    A semicolon-separated list of header/value matches that make delivery(8) place incoming messages into the junk folder rather than Inbox. Each entry in this list has the form Header=val (`:` may be used in place of `=`). Header names and values are compared case-insensitively. Values are checked both against the full header value and individual comma/semicolon separated tokens; use * or an empty value to match any header value.
    Default: (empty)
    Example: X-Spam-Flag=YES; X-Spam=yes; X-Spam=1

exmdb_client_rpc_timeout
    If the execution of an RPC takes longer than the specified time, the client will sever the connection and return an error to the calling program. The value cannot be lower than 4s. The special value 0 disabled RPC timeout checking.
    Default: 0

outgoing_smtp_url
    A string which selects how outgoing messages are handed to a mail transfer agent. The syntax follows the Common Internet Scheme for URIs (RFC 1738 section 3.1), so something like "sendmail://localhost" or "smtp://[::1]:25/" can be used.
    The sendmail:// transport selects the local maildrop queue (hostname is ignored). Maildrop is perhaps best known to administrators by the command /usr/sbin/sendmail. This transport is the most robust one, because local maildrop implementations generally accept messages even if the MTA is not running (assuming everything else is fine, e.g. there is enough free disk space). Partial Delivery Failure handling then is also the MTA's responsibility, and the MTA will consistently emit NDR/DSN for unreachable recipients.
    Other recognized schemes are smtp:, smtp+tls: (STARTTLS), smtp+unverifiedtls: (STARTTLS but ignore validation issues) and smtps: (always-on/implicit TLS). These are only meant for developers who want to avoid running an MTA for having faster turnarounds. All SMTP transport drivers are locally unqueued, which means that, if the SMTP server is unavailable due to network issues, pressing the "Send" button will immediately produce an error in always-online MUAs, and the user has to save the message as a draft and try again later on their own accord. MAPI also has no way to be conveyed Partial Delivery Failure occuring in SMTP conversations, so a multi-recipient message with one bad recipient can lead to three bad characteristics all at once: valid recipients will receive a message copy; the sender got the Send button error; no Non-Delivery Report is generated for users in the local mail system. The proper way to use a custom outgoing SMTP server is to configre the localhost MTA to perform relaying.
    Default: sendmail://localhost

ruleproc_debug
    Make the "TWOSTEP" Client-Side Inbox Rule Processor emit information about the conditions it is evaluating and the actions it is carrying out. The surrounding process also needs to have log level set to at least 6 (debug) to see anything, i.e. delivery.cfg:lda_log_level=6 in case of delivery(8gx), or --loglevel=6 in case of command-line tools like case of gromox-import(8). [The Rule Processor implementation inside exmdb_provider(8gx) logs unconditionally, and its log messages will be seen, provided level 6 is set with http.cfg:http_log_level=6.]
    Default: off

reported_server_version
    Default: 15.00.0847.4040

See also
gromox(7)