 |
|
| |
MILTER-CALLBACK(8) |
FreeBSD System Manager's Manual |
MILTER-CALLBACK(8) |
milter-callback —
sendmail milter using sender verification.
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 ] |
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.
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.
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.
The milter-callback logs to syslog and
currently I have no plans to change that scheme or implement independent
logging system.
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.
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.
The milter-callback and manual were
written by Eugene M. Zheganin
⟨milter-callback@norma.perm.ru⟩.
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc.
|