wether to fork to the background. initscripts require this to be true most of the time.

chroot to this directory on startup. this path is ABSOLUTE, it WON'T work with a relative path, because we are chrooting to the dir BEFORE chrooting, as a security measure. to disable chrooting, use an empty string (default).

drop privileges once running? recomended.

user to drop privileges to.

group to drop privileges to.

write a pid file with the pid of the main hermes server. if you set background=true above, this will write the pid of the forked hermes, not the original.

the port where hermes will listen for new connection. if you are going to use a port lower than 1024 (almost always, smtp is 25, smtps is 465 and delivery is 587), then you need to run as root (you can drop privileges) or with setUID active.

the ip to bind to. if you leave it empty (default), then it listens on all available ips

the host of the real smtp server. if your server is qmail and you have the AUTH patch, DON'T use localhost, use the external IP instead.

the port for the real smtp server.

database file to use. if you are chrooting, the path is relative to the chroot: real filepath = chroot + database_file

wether to use greylisting. greylisting will slightly delay your emails (configurable, see below) to stop most spam. is the most efective technique in use by hermes.

wether to throttle connection. it will force some spammers (the more impatient ones) to drop the connection and leave you alone.

wether we should check if there is data before we send the SMTP banner. if there is data the spam is almost certainly spam.

rbl domain to check. if this is empty (default) hermes will not check anything, effectively disabling rbl checking. recommended value is "zen.spamhaus.org"

time to delay the initial SMTP banner

initial expiry time. when email is first recorded, it will expire after this time (in minutes).

initial period of time (in minutes) during which a retry on the spammer's side will FAIL.

once we have whitelisted a triplet, how long it stays whitelisted (in days). 36 is a magic number, is the maximum days between a day and the same day next month

wether to submit stats.

should stats be submited using SSL? recomended, but some people will compile without ssl.

username (used to submit stats). you can register on http:

password

if you are using the filelogger, which file to log to.

wether to clean the database file and send stats. if you have two instances of hermes running (for example one for smtp and other for smtps) you want to configure all of them but one to use clean_db=false. also, you might prefer to not clean the database at all for many reasons (for example to keep a huge file around with all your system's email data). anyway, this doesn't mean in anyway that entries in the database won't expire, only that they will be left hanging around without any use.

should we try to connect to our real smtp server using ssl? not really neccesary unless real smtp server is on other machine.

should we accept connections using ssl? NOTE: this does NOT disable the starttls capability, only starts hermes expecting SSL negotiation. starttls is handled the following way: if you have ssl, it is always on. clients can request it at any time an hermes will change to ssl at once. if you don't have ssl, hermes will refuse to starttls with a 354 error code, although it WILL still accept the command. connection should proceed normally even on that event

file with our private key (PEM format). to generate, execute: # openssl genrsa 1024 > private.key

file with our server certificate (PEM format). to generate, execute: # openssl req -new -x509 -nodes -sha1 -days 365 -key private.key > certificate.crt and answer the questions

wether to add headers to the email sent or no to be rfc compatible this HAS to be true, but if you set to false, no one will know you are using hermes