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

FreeBSD Manual Pages


home | help
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 performs sender verification of the envelope-from e-mail address us-
     ing 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 mil-
	     ter 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 re-
	     verse connection. In both mode previous two modes are used	se-
	     quentially. Plus, a fake e-mail address verification is per-
	     formed. Finally, the message is accepted only if following	condi-
	     tions 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	fea-
	     ture called graceful DNS relaying can be applied. See it's	de-
	     scription 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

     -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 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 per-
     formed. 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 call-
     backs. 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.  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.  will also appen the X-Callback-Cached header, if	the
     decision about a messages was taken using cache.  can be built with Post-
     greSQL support, that can simplify the lost	mail searching and whitelist
     handling using the	provided web-interface.

     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 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 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 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 ser-
     vices. 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. With-
     out 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
     code><space><reply	text>.	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 re-
     lay 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 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	veri-
     fication schemes that use non-RFC compliant methods of sender verifica-
     tion. 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 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 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
     receiving mail.  uses all RFC-compliant procedures	and codes in such pro-
     cedures. Thus, it doesn't violate SMTP RFCs directly or indirectly. In-
     sisting on	the reverse relaying isn't described in	RFCs along with	relay-
     symmetric scheme, but it's	neither	prohibited.

     The and manual were written by Eugene M. Zheganin

FreeBSD	13.0			October	1, 2008			  FreeBSD 13.0


Want to link to this manual page? Use this URL:

home | help