MILTER-CALLBACK
milter-callback is intended to:
- perform a envelope-from sender verification on target MX.
- perform an optional envelope-from sender verification on sending peer.
- drop e-mails from nonexistent hostsparts, mail domains and nonexistent users.
- log to database all connections processed (only pgsql is supported at this time).
- handle the history and whitelist via web-interface.
milter-callback is not intended to:
- use telepathy or mind efforts to penetrate inside the letter text. If spammers use
RFC-compliant relays that accept the e-mail they send in reverse direction, milter-callback
will pass such mail.
milter-callback is a sendmail milter that is written to lower the amount of receiving spam. It was tested
on FreeBSD 4.x to 8.x and is currently used on four production relays with more than 2500 mailboxes.
The latest release is 1.6.0 (you can download it
here). For this verion to run FreeBSD 6.3-RELEASE or
upper versions are required. You can also use old version (why lots of people keep on downloading this old incapable crap ?
Stop. Upgrade your systems.) from here for older
libmilter versions (FreeBSD 6.2-RELEASE and previous versions). Older version doesn't support
null-envelope-from (<> e-mails) and never will for technical reasons. Older version doesn't have SQL functionality,
cache (i.e. they can create really big amounts of traffic on callouts) and SPF support.
You can e-mail about any bugs found at milter-callback@norma.perm.ru.
Please, if possible, supply a core-file and a log with debugging level 3.
HOW IT WORKS
milter-callback can work in three different modes: rfc,
direct or both.
- RFC mode. In rfc mode the sender is validated according to RFC 974: if MXes for sender
domains exist, the sender is checked on those MXes; if not, the sender is checked on
the host taken from the hostpart of the e-mail address. If all of the MXes reject
e-mail envelope-from address that relay is trying to send, the message is rejected.
If all/one of the MXes is accepting such mail, the message is relayed. Otherwise
the message is tempfailed.
- Direct mode.In direct mode sender is validated
on sending relay by opening reverse connection. An attempt to relay mail to non-existent address
is also made to ensure the sending peer is not an openrelay.
- Both mode. In both mode
previous two modes are used sequentually. Plus, a fake e-mail address verification is
performed. Finally, the message is accepted only if following conditions are met:
the fake e-mail is rejected on the sending peer, one/all of the MXes accepted original
e-mail, the sending peer accepted the e-mail address it's trying to send. The message
is rejected if all of the MXes rejected reverse e-mail, otherwise the message is
tempfailed. In both mode reverse peer testing will be skipped
if the reverse peer is one of the MXes. Plus, a feature called graceful DNS relaying
can be applied. See it's description below.
Mode defaults to both mode. Note: the direct
mode is considered as weird and exotic, and it exists only because it exists internally
inside the program on procedural level. I see no reason to use it.
FEATURES
- SPF support.
SPF is supported through the libspf2 library. The mail is immidiately passed if SPF_PASS is received,
and is dropped if SPF_FAIL is received. All of the usual checks are performed on any other result.
However, checks aren't performed if at least one allowed network in TXT record has a mask shorted than
permitted in the configuration. In this case SPF checking is simply skipped.
- PostgreSQL logging, whitelist handling and web-interface.
At this time, the main and the most feature of milter-callback is the pgsql integration.
milter-callback, being compiled with -DWITH_PGSQL, allows whitelist and log handling
through a database and attached web-interface written in php. At this time, the authentication
to a web-interface must be done externally, for example via different apache modules.
- Cache. milter-callback caches everything that is
not whitelisted for the given amount. Each cache entry eats at least 332
bytes of memory. Cache TTL and length is controlled through the
configuration file. Cache allows to skip unnecessary MX and reverse checks.
- Graceful DNS relaying. Graceful DNS relaying allows
to skip the reverse and fake checks. It means that if, for example, the
envelope-from e-mail address is some@foo.bar and
the IP of the relay that is sending such mail resolves to
somehost.foo.bar, and the domain level of this
host will be 2 or more, reverse relaying checks will be skipped and
only MX tests will be performed. This is a dangerous feature, because
the spammers may set their IPs to resolve to some well-known e-mail
providers domains, even to your own e-mail domain. Use this feature
with caution, it can be only set through the configuration file.
- Headers. milter-callback will insert 4
headers to e-mails it has processed: one,
X-Callback, that will indicate that the
message was processes by milter and the version of the milter, and
another, X-Callback-Status, that will
contain reasons why this message was passed. Finally, if the pair
<relay IP/envelope-from address> was found in cache, it will insert
X-Callback-Cached header, mostly for debugging
puproses. It will also insert the X-Callback-Envelope-From
header, which shows envelope-from e-mail address told by relay in the MAIL FROM stage.
INSTALLATION
Installation is quite simple: compile the milter using provided
Makefile (you can supply -DWITH_DEBUG, -DWITH_PGSQL and/or -DWITH_SPF arguments,
but by default those aren't used), put the provided configuration file in
/usr/local/etc/mail/milter-callback.conf, put the
man page in appropriate place, put the milter to where you want
it, and start the program. Then edit your sendmail .mc m4 configuration file, add
strings
INPUT_MAIL_FILTER(`milter-callback', `S=unix:/var/run/milter-callback.sock, F=T, T=S:3m;R:6m')
assemble new sendmail.cf and restart sendmail. The system
should be ready. Consult the man page for supported switches and configuration file
directives.
BUGS
- Greylisting.
It used to say that greylisting fights with SMTP-callouts - basically that is not true.
Suppose we have a sending relay with greylisting enabled and a relay with milter-callback.
First time the sending relay will receive bounce, because callout will be greylisted. But as
soon as the sending relay will retry the relaying, milter-callback will do the callout again,
and it's obvious that after some time it will succeed. The only small problem with the
milter-callback and greylisting is that if the relay uses both greylisting and the callback,
the incoming e-mail will be checked twice with milter-callback, and this is because the message
flow scheme in libmilter. This will be fixed lated when the cache will be implemented.
- Mail with empty envelope-from.
At this moment milter-callback blocks such mail. This will be fixed in next version.
RFC FIGHTING
First of all, spammers that send mail from forged e-mail addresses don't violate the RFCs.
Second, sending mail through any permitting relay isn't RFCs violation too. Finally, openrelaying
isn't an RFCs violation at all. But there is other side of that. RFCs doesn't say that e-mail
MUST be relayed. It even doesn't say that the e-mail MUST be relayed on native MXes for that
domain. RFC only describes the procedures used when sending or receiving mail. milter-callback
uses all RFC-compliant procedures and codes in such procedures. Thus, it doesn't violate SMTP
RFCs directly or indirectly. Insisting on the reverse relaying isn't described in RFCs along
with relay-symmetric scheme, but it's neither prohibited.
LICENSING
milter-callback is distributed under the terms of the GPL license.
This article was last modified [an error occurred while processing the directive].