NAME

milter-callback —

sendmail milter using sender verification.

SYNOPSIS

milter-callback [-s path to sendmail socket] [-t sendmail timeout] [-m milter email address] [-u milter user] [-f fake email address] [-c callback mode] [-i IP address] [-l loglevel] [-D]

DESCRIPTION

The milter-callback performs sender verification of the envelope-from e-mail address using 3 basic callback modes on the sender MXes and/or sending relay.

The options are as follows:

-s path: The path to sendmail socket file, by which sendmail and the milter will communicate. Defaults to /var/run/milter-callback.sock.
-t sendmail timeout
-m e-mail address: E-mail address user in MAIL FROM: in SMTP callout sessions.
-u milter user: A user to suid() to. Currently this option is not used. This will be fixed in later releases.
-f e-mail address: Fake e-mail address used in RCPT TO: to check if the relay is an open relay.
-c mode: Callback mode, can be rfc, direct or both. Defaults to both mode. In rfc mode the sender is validated according to RFC 821: 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. In direct mode sender is validated on sending relay by opening reverse connection. In both mode previous two modes are used sequentially. 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. Note: the direct mode is considered as weird and exotic, and it exists only because it exist internally inside the program on procedural level. I see no reason to use it.
-i IP address: this option enables IP address test mode, the supplied IP address will be tested against whitelisted networks, then program will exit.
-l loglevel: Level of logging detail. Supported levels are 0, 1, 2 and 3. 0 is the less detailed level, and 3 is the most.
-D: Don't detach from controlling terminal and log to stdout.

FEATURES

One of the first features implemented was graceful DNS relaying. 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. milter-callback also implements the cache, the main idea of teh cache is to minimize the traffic sent and received during callbacks. Also I should say here that 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. X-Callback-Envelope-From , that will e-mail address that sending relay told receiving relay in MAIL FROM. This address may be different from the e-mail address in From header, and this will indicate possible address forgery. milter-callback will also appen the X-Callback-Cached header, if the decision about a messages was taken using cache. milter-callback can be built with PostgreSQL support, that can simplify the lost mail searching and whitelist handling using the provided web-interface.

CONFIGURATION FILE.

milter-callback looks for a configuration file in /usr/local/etc/mail/milter-callback.conf and at the time of this writing this is defined only in milter-callback sources. This behaviour is a subject to changing. The configuration file options are mostly same as the command-line keys and are self-explanatory.

LOGGING

The milter-callback logs to syslog and currently I have no plans to change that scheme or implement independent logging system.

BUGS

Currently the only way to pass the mail from RFC-compliant but spam-alike sumbission-only relays is either whitelist them, or using SPF, but on their side. That means, that in both and direct modes it has no standard mechanism to distinguish spammers from relays that use RFC-compliant but still spam-like methods of sending mail. The key principle that in both mode the decision about relaying a message is taken basing on the ability of the sending relay to pass the e-mail in reverse direction. Basically, this isn't a strong rule (see section RFC FIGHTINGS ),
but in modern environment this can be relied on, if we take some precautions. Those precautions are simple but uncomfortable: whitelist all known relays clusters that use outbound-only relay scheme without having proper SPF record. Basically, these are large ISPs and public e-mail services. After all, it's up to you to choose the comfortable balance level between amount of received spam and the amount of bouncing e-mails. Without whitelisting milter-callback will bounce the mail from outbound-only relays, from e-mail lists and subscriptions, as they often use the same outbount-only scheme. Plus, it bounces the mail from non-RFC mailers and non-RFC mail filters. The RFC 821 insists that SMTP replies use the scheme <3 digit code><space><reply text>. milter-callback usually bounces the mailers those reply codes aren't separated by space. I won't change that behaviour. Also, 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 milter-callback the incoming e-mail will be checked twice with milter-callback, and this is because the message flow scheme in libmilter. Finally, milter-callback bounces mail from others sender verification schemes that use non-RFC compliant methods of sender verification. Once again, RFC 821 insists that envelope-from address must be valid e-mail address, but some of the sender verification implementations use the <> empty invalid address. This mail is bounced in the milter-callback and I won't change that RFC behaviour too. I don't see a single reason why not to use a valid e-mail address in sender verification scheme.

RFC FIGHTINGS

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.

AUTHORS

The milter-callback and manual were written by Eugene M. Zheganin ⟨milter-callback@norma.perm.ru⟩.