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 re-
	       ject 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  follow-
	       ing  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 ap-
	       plied. 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 ad-
	       dress 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 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	imple-
       ments  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 mil-
       ter 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  ad-
       dress  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 writ-
       ing 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.
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	mechanism to distinguish spammers from relays  that  use  RFC-
       compliant  but still spam-like methods of sending mail. The key princi-
       ple 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 re-
       verse 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 pre-
       cautions. Those precautions are simple but uncomfortable: whitelist all
       known relays clusters that use outbound-only relay scheme without  hav-
       ing  proper  SPF	 record. Basically, these are large ISPs and public e-
       mail services. After all, it's up to you	to choose the comfortable bal-
       ance 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 of-
       ten 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	 enve-
       lope-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 be-
       haviour 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 re-
       lay isn't RFCs violation	too. Finally, openrelaying isn't an RFCs  vio-
       lation  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 re-
       layed on	native MXes for	that domain. RFC only describes	the procedures
       used when sending or receiving mail.  milter-callback uses all RFC-com-
       pliant procedures and codes in such procedures. Thus, it	 doesn't  vio-
       late  SMTP RFCs directly	or indirectly. Insisting on the	reverse	relay-
       ing 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 14.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+14.3.quarterly>

home | help