|SPAMD(8)||System Manager's Manual||SPAMD(8)|
spamdis a fake mail daemon which rejects false mail. It is designed to be very efficient so that it does not slow down the receiving machine.
spamdconsiders sending hosts to be of three types: blacklisted hosts are diverted to
spamdand tarpitted i.e. they are communicated with very slowly to consume the sender's resources. Mail is rejected with either a 450 or 550 error message. A blacklisted host will not be allowed to talk to a real mail server. whitelisted hosts do not talk to
spamd. Their connections are instead sent to a real mail server, such as smtpd(8). greylisted hosts are diverted to
spamdhas not yet decided if they are likely spammers. They are given a temporary failure message by
spamdwhen they try to deliver mail. When
spamdis run in default mode, it will greylist connections from new hosts. Depending on its configuration, it may choose to blacklist the host or, if the checks described below are met, eventually whitelist it. When
spamdis run in blacklist-only mode, using the
-bflag, it will consult a pre-defined set of blacklist addresses to decide whether to tarpit the host or not. When a sending host talks to
spamd, the reply will be stuttered. That is, the response will be sent back a character at a time, slowly. For blacklisted hosts, the entire dialogue is stuttered. For greylisted hosts, the default is to stutter for the first 10 seconds of dialogue only. The options are as follows:
spamddoes not fork(2) into the background.
spamdis to bind(2). By default
spamdlistens on the localhost address 127.0.0.1.
spamdshould listen for diverted SMTP connections on. The default port is found by looking for the named service “spamd” using getservbyname(3).
spamdlogs connections, disconnections and blacklist matches to syslogd(8) at
LOG_INFOlevel. With verbose logging enabled, message detail including subject and recipient information is logged at
LOG_INFO, along with the message body and SMTP dialogue being logged at
451 Temporary failure, please try again later.
spamdwill use the db file in /var/db/spamd to track these connections to
spamdby connecting IP address, HELO/EHLO, envelope-from, and envelope-to, or tuple for short. Hosts which connect but do not attempt to deliver mail will not generate a tuple and always be ignored. A previously unseen tuple is added to the /var/db/spamd database, recording the time an initial connection attempt was seen. After passtime minutes if
spamdsees a retried attempt to deliver mail for the same tuple,
spamdwill whitelist the connecting address by adding it as a whitelist entry to /var/db/spamd.
spamdregularly scans the /var/db/spamd database and configures all whitelist addresses as the pf(4) <spamd-white> table, allowing connections to pass to the real MTA. Any addresses not found in <spamd-white> are diverted to
spamd. An example pf.conf(5) fragment is given below. In the example, the file /etc/mail/nospamd contains addresses of hosts who should be passed directly to the SMTP agent (thus bypassing
table <spamd-white> persist table <nospamd> persist file "/etc/mail/nospamd" pass in on egress proto tcp to any port smtp \ divert-to 127.0.0.1 port spamd pass in on egress proto tcp from <nospamd> to any port smtp pass in log on egress proto tcp from <spamd-white> to any port smtp pass out log on egress proto tcp to any port smtp
spamdremoves tuple entries from the /var/db/spamd database if delivery has not been retried within greyexp hours from the initial time a connection is seen. The default is 4 hours as this is the most common setting after which MTAs will give up attempting to retry delivery of a message.
spamdremoves whitelist entries from the /var/db/spamd database if no mail delivery activity has been seen from the whitelisted address by spamlogd(8) within whiteexp hours from the initial time an address is whitelisted. The default is 36 days to allow for the delivery of monthly mailing list digests without greylist delays every time. spamd-setup(8) should be run periodically by cron(8) to update the blacklists configured in spamd.conf(5). Use crontab(1) to uncomment the entry in root's crontab. When run in blacklist-only mode, the
-bflag should be specified. spamlogd(8) should be used to update the whitelist entries in /var/db/spamd when connections are seen to pass to the real MTA on the smtp port. spamdb(8) can be used to examine and alter the contents of /var/db/spamd. See spamdb(8) for further information.
spamdsends log messages to syslogd(8) using facility daemon and, with increasing verbosity, level err, warn, info, and debug. The following syslog.conf(5) section can be used to log connection details to a dedicated file:
!spamd daemon.info /var/log/spamd
spamdin default mode, it may be useful to define spamtrap destination addresses to catch spammers as they send mail from greylisted hosts. Such spamtrap addresses affect only greylisted connections to
spamdand are used to temporarily blacklist a host that is obviously sending spam. Unused email addresses or email addresses on spammers' lists are very useful for this. When a host that is currently greylisted attempts to send mail to a spamtrap address, it is blacklisted for 24 hours by adding the host to the
spamdblacklist <spamd-greytrap>. Spamtrap addresses are added to the /var/db/spamd database with the following spamdb(8) command:
# spamdb -T -a 'firstname.lastname@example.org'
email@example.com firstname.lastname@example.org email@example.com
spamdhas such an address specified, no host may enter new greylist tuples when connecting to this address; only existing entries may be updated. Any host attempting to make new deliveries to the low priority MX for which a tuple has not previously been seen will be trapped. Note that it is important to ensure that a host running
spamdwith the low priority MX address active must see all the greylist changes for a higher priority MX host for the same domains. This is best done by the host itself receiving the connections to the higher priority MX on another IP address (which may be an IP alias). This will ensure that hosts are not trapped erroneously if the higher priority MX is unavailable. For example, on a host which is an existing MX record for a domain of value 10, a second IP address with MX of value 99 (a higher number, and therefore lower priority) would ensure that any RFC conformant client would attempt delivery to the IP address with the MX value of 10 first, and should not attempt to deliver to the address with MX value 99. pf.conf(5) rules described above are sufficient. However when running in blacklist-only mode, a slightly modified pf.conf(5) ruleset is required, diverting any addresses found in the <spamd> table to
spamd. Any other addresses are passed to the real MTA.
table <spamd> persist pass in on egress inet proto tcp from <spamd> to any port smtp \ divert-to 127.0.0.1 port spamd
# pfctl -q -t spamd -T replace -f /usr/local/share/spammers
spamdover a localhost socket, giving
spamdinformation about each source of blacklist addresses, as well as custom rejection messages for each blacklist source that can be used to let any real person whose mail is deferred by
spamdknow why their address has been listed from sending mail. This is important as it allows legitimate mail senders to pressure spam sources into behaving properly so that they may be removed from the relevant blacklists.
spamdlistens for configuration connections on the port identified by the named service “spamd-cfg” (see services(5)). The configuration socket listens only on the INADDR_LOOPBACK address. Configuration of spamd is done by connecting to the configuration socket, and sending blacklist information, one blacklist per line. Each blacklist consists of a name, a message to reject mail with, and addresses in CIDR format, all separated by semicolons (;):
spamdwill reject mail by displaying all the messages from all blacklists in which a connecting address is matched. spamd-setup(8) is normally used to configure this information.
spamdsupports realtime synchronisation of spamd databases between a number of spamd daemons running on multiple machines, using the
-yoptions. The databases are synchronised for greylisted and trapped entries; whitelisted entries and entries made manually using spamdb(8) are not updated. The following example will accept incoming multicast and unicast synchronisation messages, and send outgoing multicast messages through the network interface em0:
# /usr/libexec/spamd -y em0 -Y em0
# /usr/libexec/spamd -y bge0 -Y em0:2 \ -Y foo.somewhere.org -Y bar.somewhere.org
spamdwill calculate the message-digest fingerprint (checksum) for the file and use it as a shared key to authenticate the synchronisation messages. The file itself can contain any data. For example, to create a secure random key:
# dd if=/dev/random of=/etc/mail/spamd.key bs=2048 count=1
spamdcommand first appeared in OpenBSD 3.3.
spamdcurrently uses the user “_spamd” outside a chroot jail when running in default mode, and requires the greylisting database in /var/db/spamd to be owned by the “_spamd” user. This is wrong and should change to a distinct user from the one used by the chrooted
|April 2, 2017||OpenBSD-current|