Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help 
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

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]
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

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 vali-
	     dated  on sending relay by opening reverse connection. In both mode
	     previous two modes are used sequentially. Plus, a fake  e-mail  ad-
	     dress  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.
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

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  dan-
     gerous  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(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

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 sub-
     ject to changing. The configuration file options are  mostly  same  as  the
     command-line keys and are self-explanatory.
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

LOGGING
     The  milter-callback logs to syslog and currently I have no plans to change
     that scheme or implement independent logging system.
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

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 mecha-
     nism 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  precau-
     tions.  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. Af-
     ter  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 re-
     lays, from e-mail lists and subscriptions, as they often use the same  out-
     bount-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 mail-
     ers those reply codes aren't separated by space. I won't change that behav-
     iour. Also, it used to say that greylisting fights with SMTP-callouts - ba-
     sically 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 implementa-
     tions 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.
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

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  re-
     layed.  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 re-
     ceiving mail.  milter-callback uses all RFC-compliant procedures and  codes
     in  such  procedures.  Thus, it doesn't violate SMTP RFCs directly or indi-
     rectly. Insisting on the reverse relaying isn't  described  in  RFCs  along
     with relay-symmetric scheme, but it's neither prohibited.
MILTER-CALLBACK(8)	     System Manager's Manual	      MILTER-CALLBACK(8)

AUTHORS
     The   milter-callback  and  manual  were  written	by  Eugene  M.	Zheganin
     <milter-callback@norma.perm.ru>.

FreeBSD ports 15.quarterly	 October 1, 2008	      MILTER-CALLBACK(8)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=milter-callback&sektion=8&manpath=FreeBSD+Ports+15.1.quarterly>

home | help