5.17. How to create j-policy.db (policy database) - Version 1.8 and newers

You need to create the text file with your rules : /etc/mail/jchkmail/j-policy, and define it to /etc/mail/jchkmail/Makefile.db :

    $ more Makefile.db
    ...
    OBJ = j-urlbl.db j-policy.db
    ...

If you've already configured your system to automatically get URL database from our site, the policy database will be automatically updated. To force database update, you may launch :

    # make -f Makefile.db
    /usr/bin/j-makemap -b j-policy.db -m e < j-policy.txt
    * Total :     68 records read
                  67 records added
                   0 errors
    #

HINT :j-policy.txt is composed of entries from a common part (which are valid for all sites using j-chkmail) and other entries which are valid only for your site. The common part can be found at j-chkmail distribution or at j-chkmail web site. Instead of using a single big file, you can use smaller files and concatenate them. At /etc/mail/jchkmail/Makefile.db, you'll have to define :

POLICYSRC = j-policy.grey.txt j-policy.badmx.txt j-policy.site.txt

j-policy.txt : $(POLICYSRC)
        cat  $(POLICYSRC) > $@

if you're using GNU make, you can replace POLICYSRC line by :

POLICYSRC = $(wildcard j-policy.*.txt)

When using Sun make, the same results are got with :

POLICYSRC:sh =ls j-policy.*.txt

This way, you can add or remove files without modifying Makefile, provided their filename follows the rule j-policy.*.txt.

5.18. What's the syntax of j-urlbl.txt file ?

The syntax is :

     URLBL:domain                  value

     URLBL:123-good-health.com     20:1096537749:127.2.0.1:j-chkmail

• The score of this entry
• The date this entry was added (seconds since epoch)
• An IP code for this entry at the BL
• The name of the blacklist this entry comes from

5.19. What's the content of j-policy.txt file ?

Beginning with j-chkmail release 1.8, many configuration data is being moved to j-policy database. The idea is almost the same of sendmail access database.

Roughly speaking, most data which may be vary depending on the situation, and may be defined with a couple (key, value) will be put in this database.

Tipically, data in this file are :

• Limits associated to some parameters, e.g., maximum connection rate allowed for some IP networks or domains, or the class to be associated to some IP network.
• Actions associated to some bad situations, e.g., reply codes when the domain part of the sender address is unreacheable (BadMX).
• Access rules or conditions allowing to evaluate if some check shall be done, e.g., entries allowing to check if some message shall be checked against viruses. This kind of data may have three kind of keys (Connect, From, To), as some situations need to combine all these three values to define the rule.

5.20. What's the syntax of j-policy.txt file ?

The syntax of this file is very simple but flexible and strong. It's idea is very similar to that found at sendmail access database. At the moment, all possibilities aren't yet exploited.

It's syntax is :

   Tag:Key          Value

• Tag - is the kind of information we're looking for.
• Key - is the key of the information
• Value - is the value associated with the Tag and Key

An example of already implemented kind of entries follows :

     CtrlChan:DEFAULT           REJECT
     CtrlChan:127.0.0.1         OK
     CtrlChan:194.21.16.16      OK
     #
     ConnRate:DEFAULT           15
     ConnRate:127.0.0.1         1000
     ConnRate:LOCAL             500
     ConnRate:DOMAIN            300
     #
     NetClass:199.199.123       DOMAIN
     NetClass:192.168           LOCAL
     #
     BadMX:192.168              ERROR:421:4.5.1:DNS problems... Try later !
     BadMX:192.168.128.200      OK
     BadMX:saveinternet.net     ERROR:421:4.5.1:Too busy now... Try later !
     #
     ReplyMsg:TOO_MUCH_BADRCPT  *** Harvesting ???

5.21. How key values are matched against database entries ?

There are three cases : IP addresses, host names and e-mail addresses.

Matching logic is :

   if (key is e-mail)
     query full key
     if found return result
   end if

   extract domain part
   if (domain part is IP address)
     query IP address and network addresses
     if found return best matching result
   else 
     query domains and sub domains
     if found return best matching result
   end if

   if (key is e-mail)
     query user part
     if found return result
   end if

   query default value
   if found return result

5.22. How are triplets access rules evaluated from j-policy database ?

When used with triplets, the tags will have three values : prefixConnect, prefixFrom, and prefixTo.

The function used to evaluate the access function uses four parameters :

• Client IP address - used with Connect prefix
• Client hostname - used with Connect prefix
• Enveloppe From address - used with From prefix
• Enveloppe To Address - used with To prefix

Values which may be associated to each entry are : YES, NO, YES-QUICK and NO-QUICK.

When YES-QUICK or NO-QUICK are found, evaluation stops immediately.

Databases entries keys are formed as follows :

    prefix + Connect + : + IP           -> GreyCheckConnect:1.2.3           YES
    prefix + Connect + : + Hostname     -> GreyCheckConnect:yahoo.com       NO
    prefix + From    + : + From address -> GreyCheckFrom:joe@j-chkmail.org  YES-QUICK
    prefix + To      + : + To address   -> GreyCheckTo:joe@                 NO

The evaluation algorithm looks like

  result = NO
  if queryDatabase(prefix, "Connect", IP, &value)
    result = value
    if result == YES-QUICK  return YES
    if result == NO-QUICK   return NO
  else
    if queryDatabase(prefix, "Connect", Hostname, &value)
      result = value
      if result == YES-QUICK  return YES
      if result == NO-QUICK   return NO
    else
      if queryDatabase(prefix, "Connect", "DEFAULT", &value)
        result = value
        if result == YES-QUICK  return YES
        if result == NO-QUICK   return NO
      endif
    endif
  endif
      
  if queryDatabase(prefix, "From", From, &value)
    result = value
    if result == YES-QUICK  return YES
    if result == NO-QUICK   return NO
  else
    if queryDatabase(prefix, "From", "DEFAULT", &value)
      result = value
      if result == YES-QUICK  return YES
      if result == NO-QUICK   return NO
    endif
  endif

  if queryDatabase(prefix, "To", To, &value)
    result = value
     if result == YES-QUICK  return YES
     if result == NO-QUICK   return NO
   else
     if queryDatabase(prefix, "To", DEFAULT, &value)
       result = value
       if result == YES-QUICK  return YES
       if result == NO-QUICK   return NO
     endif
  endif

  if result == YES-QUICK  result = YES
  if result == NO-QUICK   result =  NO

  return result

5.23. Does j-chkmail use environnement variables and how can I define them ?

Yes ! Since version 1.7, j-chkmail can use some environnement variables, if they are defined. Variables defined at environnement overrides values defined as command line options or configuration file.

Here is a list of variables. This list will be augmented for each new release.

• JCHKMAIL_LOG_LEVEL - this corresponds to the LOG_LEVEL configuration variable
• MILTER_DEBUG_LEVEL - this corresponds to the libmilter library log level
• JCHKMAIL_SOCKET - this corresponds to the SOCKET configuration variable - the communication socket between sendmail and j-chkmail
• DB_CACHE_SIZE - this corresponds to the memory amount dedicated to database cache (per database).
• FILE_EXT - this corresponds to the the file extensions used to define XFILES.

To define environnement variables you can put them at environnement, if you're launching j-chkmail by hand, or depending on your operating system, you can define them at some file read before launching j-chkmail. Usual files are : /etc/default/jchkmail or /etc/sysconfig/jchkmail. An exemple of the contents of this file is :

  #
  JCHKMAIL_LOG_LEVEL=10
  #
  FILE_EXT="exe pif zip cpl"
  #
  JCHKMAIL_SOCKET=unix:/var/tmp/jchkmail.sock

5.24. What's the content of j-rcpt.txt file ?

This file is used to define recipient access (both local and remote recipients). Recipient access means :

• Valid recipients
• Spam traps
• Recipients accepting messages only from local networks

5.25. What's the syntax of j-rcpt.txt file, and how do I fill it ?

There are two kind of records :

• Domain records - These records allow you to configure for which domains you want to do recipient access. Syntax for these entries are as follows :

  	CheckRcptDomain:KEY		VALUE
  

  KEY may be something like domain.com or .domain.com. The first entry matches only domain.com and the second one matches all subdomains of domain.com.

  VALUE may be one of :

  • NO - No check for this domain
  • YES - Access check will be done for this domain.
  • LOCAL - Access check will be done for this domain, for the full address and for the recipient part only. This option is useful if you're checking user access for many domains and the same user exists in all domains. This option is useful if you're lazy and you absolutely know what you're doing.
  • REJECT - All messages for this domain will be rejected.

• Recipient records - These records allow you to configure access for each recipient.
  • OK - This is a normal recipient
  • REJECT - Reject all messages for this recipient
  • SPAMTRAP - This is a fake recipient
  • IGNORE - This is a normal recipient, but don't apply any other filtering check at this SMTP command step : filtering will be reconducted for this recipient, for DATA content.
  • LOCAL-NET - Accept messages for this recipient only if the connection comes from the LOCAL network.
  • DOMAIN-NET - Accept messages for this recipient only if the connection comes from a LOCAL or DOMAIN network..
  • FRIEND-NET - Accept messages for this recipient only if the connection comes from a LOCAL or DOMAIN or FRIEND network.
  • KNOWN-NET - Accept messages for this recipient only if the connection comes from any defined and known network.
  • USER-UNKNOWN - This is an unknown or inexistent recipient.

5.26. How can I get the list of valid addresses and how to convert it to j-rcpt.txt format ?

	#! /bin/sh

	cp /dev/null j-rcpt.base.txt

	getent passwd | awk '{print $1}' >> j-rcpt.base.txt

	for db in /etc/mail/aliases*.db
        do
	  makemap -u hash $db | awk '{printf "RcptAccess:%s OK\n", $1}' >> j-rcpt.base.txt
	done

	db=/etc/mail/virtusertable.db
        makemap -u hash $db | awk '{printf "RcptAccess:%s OK\n", $1}' >> j-rcpt.base.txt

5.27. Give me some examples of j-rcpt.txt content !

1. Checking access for local users. This kind of configuration is useful when it's possible to enumerate all valid users.

   # Check recipient access for domain.com ...
   CheckRcptDomain:domain.com               LOCAL
   #
   # ... and for all sub domains of this domain
   CheckRcptDomain:.domain.com              LOCAL
   #
   # default is "Unknown user" if not defined
   RcptAccess:domain.com                    USER-UNKNOWN
   #
   # toto exists in domain.com and all sub domains
   RcptAccess:toto@                         OK
   #
   # titi exists only in domain.com
   RcptAccess:titi@domain.com               OK
   #
   # this is a spamtrap
   RcptAccess:spam@domain.com               SPAMTRAP
   #
   # accept messages for everybody only if the connection comes from a known network
   RcptAccess:everybody@domain.com          KNOWN-NET
   

2. Checking recipient access for some users of some directions. This configuration is useful when it isn't possible to list all valid users.

   #
   CheckRcptDomain:domain.com               YES
   #
   # default access is "OK"
   RcptAccess:domain.com                    OK
   #
   # this is a spamtrap
   RcptAccess:spam@domain.com               SPAMTRAP
   #
   # accept messages for everybody only if the connection comes from a known network
   RcptAccess:everybody@domain.com          KNOWN-NET