Manual Reference Pages - MILTER-CALLBACK (8)
- sendmail milter using sender verification.
[-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]
performs sender verification of the envelope-from e-mail address
using 3 basic
on the sender MXes and/or sending relay.
The options are as follows:
The path to sendmail socket file, by which sendmail and the milter will communicate.
|-t sendmail timeout
-m e-mail address
E-mail address user in
in SMTP callout sessions.
|-u milter user
A user to
to. Currently this option is not used. This will be fixed in later releases.
|-f e-mail address
Fake e-mail address used in
to check if the relay is an open relay.
Callback mode, can be
mode the sender is validated according to
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
mode sender is validated on sending relay by opening reverse connection. In
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 its trying to send. The message is rejected if all of the MXes rejected reverse e-mail, otherwise the message is tempfailed. In
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 its description below. Note: the
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.
Level of logging detail. Supported levels are
is the less detailed level, and
is the most.
Dont 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
and the IP of the relay that is sending such mail resolves to
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.
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
will insert 4 headers to e-mails it has processed: one,
, that will indicate that the message was processes by milter and the version of the milter, and another,
, that will contain reasons why this message was passed.
, 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.
will also appen the
header, if the decision about a messages was taken using cache.
can be built with PostgreSQL support, that can simplify the lost mail searching and whitelist handling using the provided web-interface.
looks for a configuration file in
and at the time of this writing this is defined only in
sources. This behaviour is a subject to changing. The configuration file options are mostly same as the command-line keys and are self-explanatory.
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
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
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 isnt a strong rule (see section
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, its up to you to choose the comfortable balance level between amount of received spam and the amount of bouncing e-mails. Without whitelisting
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
insists that SMTP replies use the scheme <3 digit code><space><reply text>.
usually bounces the mailers those reply codes arent separated by space. I wont 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
First time the sending relay will receive bounce, because callout will be greylisted. But as soon as the sending relay will retry the relaying,
will do the callout again, and its obvious that after some time it will succeed. The only small problem with the
and greylisting is that if the relay uses both greylisting and the
the incoming e-mail will be checked twice with milter-callback, and this is because the message flow scheme in libmilter. Finally,
bounces mail from others sender verification schemes that use non-RFC compliant methods of sender verification. Once again,
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
and I wont change that RFC behaviour too. I dont 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 dont violate the RFCs. Second, sending mail through any permitting relay isnt RFCs violation too. Finally, openrelaying isnt an RFCs violation at all. But there is other side of that. RFCs doesnt say that e-mail MUST be relayed. It even doesnt 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.
uses all RFC-compliant procedures and codes in such procedures. Thus, it doesnt violate SMTP RFCs directly or indirectly. Insisting on the reverse relaying isnt described in RFCs along with relay-symmetric scheme, but its neither prohibited.
and manual were written by
.An Eugene M. Zheganin Aq email@example.com .
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.