sendmail milter using sender verification.
path to sendmail socket
milter email address
fake email address
verification of the envelope-from e-mail address using 3 basic
on the sender MXes and/or
The options are as follows:
- The path to sendmail socket file, by which sendmail and the milter will
communicate. Defaults to
- E-mail address user in MAIL FROM: in
SMTP callout sessions.
- A user to
suid() to. Currently this
option is not used. This will be fixed in later releases.
- Fake e-mail address used in RCPT TO: to
check if the relay is an open relay.
- Callback mode, can be rfc,
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.
- 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
0 is the less detailed level, and
3 is the most.
- Don't detach from controlling terminal and log to stdout.
One of the first features implemented was graceful
. It means that if, for example, the envelope-from e-mail
address is email@example.com
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, 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.
, 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 X-Callback-Cached
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
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
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
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 isn't 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, 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
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
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
. 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 it's obvious that after some time it will succeed. The only small problem
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, RFC 821
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
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.
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.
and manual were written
by Eugene M. Zheganin