MILTER-CALLBACK

• 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.

• 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.