<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<!-- THIS PAGE IS AUTOMATICALLY GENERATED. DO NOT EDIT. -->
<!-- Mon Feb 9 14:16:01 2004 -->
<!-- USING HT2HTML 2.0 -->
<!-- SEE http://ht2html.sf.net -->
<!-- User-specified headers:
Title: TMDA Filter Sources
-->
<head>
<title>TMDA Filter Sources</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="generator" content="HT2HTML/2.0">
<style type="text/css">
body { margin: 0px; }
</style>
</head>
<body bgcolor="#ffffff" text="#000000"
marginwidth="0" marginheight="0"
link="#0000bb" vlink="#551a8b"
alink="#ff0000">
<!-- start of page table -->
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<!-- start of banner row -->
<tr>
<!-- start of corner cells -->
<td width="150" valign="middle" bgcolor="#afeeee" class="corner">
<center><font size="+2"
>>>> TMDA </font></center> </td>
<td width="15" bgcolor="#cccccc"> </td><!--spacer-->
<!-- end of corner cells -->
<!-- start of banner -->
<td width="90%" bgcolor="#cccccc" class="banner">
<!-- start of site links table -->
<table width="100%" border="0"
CELLSPACING=0 CELLPADDING=0
bgcolor="#ffffff">
<tr>
<td bgcolor="#cccccc">
<a href="./index.html">Home</a>
</td>
<td bgcolor="#cccccc">
<a href="./trouble.html">Help</a>
</td>
<td bgcolor="#cccccc">
<a href="tmda-cgi">TMDA-CGI</a>
</td>
<td bgcolor="#cccccc">
<a href="http://sourceforge.net/projects/tmda">SourceForge</a>
</td>
</tr><tr>
<td bgcolor="#cccccc">
[ <a href="http://www.au.tmda.net/" title="Australia Mirror">AU</a> | <a href="http://www.de.tmda.net/" title="Germany Mirror">DE</a> | <a href="http://www.it.tmda.net/" title="Italy Mirror">IT</a> | <a href="http://www.pl.tmda.net/" title="Poland Mirror">PL</a> | <a href="http://www.us.tmda.net/" title="USA Mirror">US</a> mirror ]
</td>
<td bgcolor="#cccccc">
<a href="http://tmda.net/faq.cgi">FAQ</a>
</td>
<td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/">Wiki</a>
</td>
<td bgcolor="#cccccc">
<a href="http://www.cafeshops.com/TMDA/">Store</a>
</td>
</tr>
</table><!-- end of site links table -->
</td><!-- end of banner -->
</tr><!-- end of banner row -->
<tr><!-- start of sidebar/body row -->
<!-- start of sidebar cells -->
<td width="150" valign="top" bgcolor="#cccccc" class="sidebar">
<!-- start of sidebar table -->
<table width="100%" border="0" cellspacing="0" cellpadding="3"
bgcolor="#ffffff">
<tr><td bgcolor="#191970"><b><font color="#ffffff">
About
</font></b></td></tr>
<tr><td bgcolor="#cccccc">
<a href="index.html">Introduction</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="history.html">History</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="features.html">Features</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="challengeresponse.html">Challenge / Response</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="donations.html">Donations</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaAdvocacy">Advocacy</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<tr><td bgcolor="#191970"><b><font color="#ffffff">
Install
</font></b></td></tr>
<tr><td bgcolor="#cccccc">
<a href="requirements.html">Requirements</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="download.html">Download</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="install.html">Installation</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="upgrade.html">Upgrading</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<tr><td bgcolor="#191970"><b><font color="#ffffff">
Configuration
</font></b></td></tr>
<tr><td bgcolor="#cccccc">
<a href="config.html">Overview</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="config-pre.html">Pre-Config</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="config-server.html">Server Config</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="config-client.html">Client Config</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="config-vars.html">Config Variables</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="config-filter.html">Filter Spec</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<b>Filter Sources</b>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="howto-template.html">Templates</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="tmda-vdomains.html">Virtual Domains</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="tmda-ofmipd.html">tmda-ofmipd</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaHowtos">User HOWTOs</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<tr><td bgcolor="#191970"><b><font color="#ffffff">
Support
</font></b></td></tr>
<tr><td bgcolor="#cccccc">
<a href="trouble.html">Help</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://tmda.net/faq.cgi">FAQ</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaMailingListsAndNewsgroups">Lists & Newsgroups</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaMailingListArchives">List Archives</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaCommercialSupport">Commercial Support</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaDocumentation">External Docs</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/">TmdaWiki</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<tr><td bgcolor="#191970"><b><font color="#ffffff">
Miscellaneous
</font></b></td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://wiki.tmda.net/index.cgi/TmdaMirrors">Mirrors</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="logos.html">Logos</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<a href="http://www.cafeshops.com/TMDA/" TARGET="Resource Window">Merchandise</a>
</td></tr>
<tr><td bgcolor="#cccccc">
<tr><td bgcolor="#191970"><b><font color="#ffffff">
Contact
</font></b></td></tr>
<tr><td bgcolor="#cccccc">
<a href="mailto:tmda-users@tmda.net">TMDA Users List</a>
</td></tr>
<tr><td bgcolor="#cccccc">
</td></tr>
<tr><td bgcolor="#cccccc">
© 2001-2004
</td></tr>
</table><!-- end of sidebar table -->
</td>
<td width="15"> </td><!--spacer-->
<!-- end of sidebar cell -->
<!-- start of body cell -->
<td valign="top" width="90%" class="body"><br>
<h3>TMDA Filter Sources</h3>
In the following list of sources, the expected match field is
documented as well as any optional or required arguments. Square
brackets (<b>[]</b>) indicate the the argument is optional. Words in
chevrons (<b><></b>) should be replaced by the appropriate
option, without the chevrons.
<br><br>
<strong>NOTE:</strong> <br>
The <code>from*</code> and <code>to*</code> sources match against
different addresses or sets of addresses depending on whether they are
used in an incoming filter or an outgoing filter.<br><br>
<table border="1" cellspacing="0">
<tr><th>Source</th><th>Incoming Filter</th><th>Outgoing Filter</th></tr>
<tr>
<th>from*</th>
<td><ul>
<li>envelope sender</li>
<li>From: header field</li>
<li>Reply-To: header field</li>
<li>X-Primary-Address header field if the <a
href="config-vars.html#PRIMARY_ADDRESS_MATCH">PRIMARY_ADDRESS_MATCH</a>
setting can be satisfied</li>
</ul>
</td>
<td><ul>
<li>From: header field
set by user's MUA</li>
</ul>
</td>
</tr>
<tr>
<th>to*</th>
<td><ul><li>envelope recipient</li></ul></td>
<td>One of:<ul>
<li>recipients on tmda-sendmail's command line</li>
<li>To: header field</li>
</ul>
</td>
</tr>
</table>
<h3>Domain Search</h3>
Domain names of the addresses given above are also used in the search.
The portion after the first <code>@</code> in an e-mail address is
considered the "domain". i.e,
<blockquote><pre>
jason@mastaler.com -> mastaler.com
mastaler@cs.yale.edu -> cs.yale.edu
</blockquote></pre>
Domains must be listed one per line when used in a file. e.g,
<blockquote><pre>
wingnet.net
mastaler.com
tmda.net
cs.yale.edu
</blockquote></pre>
The matching is exact. This isn't wildcarding, so with the above list,
<code>mastaler@cs.yale.edu</code> <strong>would</strong> match, but
<code>mastaler@wopr.cs.yale.edu</code> <strong>would not</strong> match.
You'd have to add <code>wopr.cs.yale.edu</code> to the list first.<br><br>
This feature may be useful for sites that wish to check a large number
of domain names, but don't want the overhead of the wildcard
code. This feature is less flexible than wildcarding, but is much
faster since the list of domains can be stored in a CDB or DBM (either directly,
or by using <code>-autocdb</code> / <code>-autodbm</code>).
<h3>Sources</h3>
This group of sources may be used in either incoming or outgoing
filter files.
<br><br>
<dl>
<dt> <code> from <a href="#email_address"><email_address></a><br>
to <a href="#email_address"><email_address></a> </code>
<dd> The <code>from</code> and <code>to</code> sources expect a match field
of either an explicit email address or a wildcarded email address. The format
of the email address is documented <a
href="#email_address">below</a>. <br>
<br>
<dt> <code> from-file [ <a href="#autoflags">-autocdb</a> | <a href="#autoflags">-autodbm</a>
] [ -optional ] <a href="#email_file"><textfile></a><br>
to-file [ <a href="#autoflags">-autocdb</a> | <a href="#autoflags">-autodbm</a>
] [ -optional ] <a href="#email_file"><textfile></a> </code>
<dd> The <code>from-file</code> and <code>to-file</code> sources expect the
name of a textfile as the match field. You can specify the entire path explicitly
or use a leading '~' to represent the user's home directory, like the shell
does. The match field is always the name of the textfile. You do not need
to add '.cdb' or '.db' if you use the <code>-auto*</code> flags. It will be
automatically appended to the filename. The format of the textfile is documented
<a
href="#email_file">below</a>. <br>
<br>
Both <code>from-file</code> and <code>to-file</code> can take one of the <code>-autocdb</code>
or <code>-autodbm flags</code>. The -autocdb and -autodbm flags are documented
<a
href="#autoflags">below</a>. <br>
<br>
If the <code>-optional</code> flag is given, the non-existence of the file
is not an error. If the file should exist, don't specify this flag; the parser
will log an error and will defer the mail so that you have a chance to fix
the problem. <br>
<br>
<dt> <code> from-cdb [ -optional ] <a href="#db_file"><database.cdb></a><br>
to-cdb [ -optional ] <a href="#db_file"><database.cdb></a> </code>
<dd> The <code>from-cdb</code> and <code>to-cdb</code> sources expect a match
field of a CDB database filename. You can specify the entire path or use a
leading '~' to represent the user's home directory. You should specify the
<b>.cdb</b> extension as part of the filename. The CDB format and expected
contents are documented <a
href="#db_file">below</a>. <br>
<br>
If the <code>-optional</code> flag is given, the non-existence of the file
is not an error. If the file should exist, don't specify this flag; the parser
will log an error and will defer the mail so that you have a chance to fix
the problem. <br>
<br>
<dt> <code> from-dbm [ -optional ] <a href="#db_file"><database.db></a><br>
to-dbm [ -optional ] <a href="#db_file"><database.db></a> </code>
<dd> The <code>from-dbm</code> and <code>to-dbm</code> sources expect the name
of a DBM database in the match field. You can specify the entire path or use
a leading '~' to represent the user's home directory. You should specify the
<b>.db</b> extension as part of the filename. The DBM format and expected
contents are documented <a
href="#db_file">below</a>. <br>
<br>
If the <code>-optional</code> flag is given, the non-existence of the file
is not an error. If the file should exist, don't specify this flag; the parser
will log an error and will defer the mail so that you have a chance to fix
the problem. <br>
<br>
<dt> <code> from-ezmlm [ -optional ] <path_to_subscribers_parent_dir><br>
to-ezmlm [ -optional ] <path_to_subscribers_parent_dir> </code>
<dd> The <code>from-ezmlm</code> and <code>to-ezmlm</code> sources match against
the subscriber list of an <a href="http://cr.yp.to/ezmlm.html"
TARGET="Resource Window">ezmlm</a> mailing list. They expect the match field to
be the full path of the <i>parent</i> directory of an ezmlm `subscribers'
directory. You should not include the `subscribers' portion of the path. <br>
<br>
If the <code>-optional</code> flag is given, the non-existence of the file
is not an error. If the file should exist, don't specify this flag; the parser
will log an error and will defer the mail so that you have a chance to fix
the problem. <br>
<br>
<dt> <code> from-mailman -attr=<attribute> [ -optional ] <path_to_list_dir><br>
to-mailman -attr=<attribute> [ -optional ] <path_to_list_dir>
</code>
<dd> The <code>from-mailman</code> and <code>to-mailman</code> sources match
against addresses contained in a <a href="http://list.org/"
TARGET="Resource Window">Mailman</a> configuration database. The match field should
be the full path to the list directory. Both Mailman 2.0 and 2.1-style configuration
databases are supported. <br>
<br>
The <code>-mailman</code> sources require you to specify an `attribute' to
search. Use the <code>-attr=attribute</code> flag to specify the name of an
attribute contained in the database. For example, `members' (subscriber addresses),
`digest_members' (digest subscriber addresses), or `owner' (list owner's address).
<br>
<br>
If the <code>-optional</code> flag is given, the non-existence of the file
is not an error. If the file should exist, don't specify this flag; the parser
will log an error and will defer the mail so that you have a chance to fix
the problem. <br>
<br>
<dt> <code> from-sql -wildcards | -addr_column=<column_name> [ -action_column=<column_name>] <SQL_query><br>
to-sql -wildcards | -addr_column=<column_name> [ -action_column=<column_name> ] <SQL_query> </code>
<dd> The <code>from-sql</code> and <code>to-sql</code> sources match
against addresses stored in a SQL database. The <SQL_query>
is a SQL SELECT statement that should retrieve the appropriate
data. Just what that data needs to be will vary, depending on how
you choose to use the <code>from-sql</code> and
<code>to-sql</code> rules. Remember to enclose the
<SQL_query> in quotes, since it will contain spaces. Double
quotes are recommended, to avoid clashing with the single quotes
used by SQL. <br>
<br>
For a simple SELECT statement, you can put it directly in your
<code>from-sql</code> or <code>to-sql</code> rule. For more
complex statements, you can define a macro in the filter
file or you can define a variable in either /etc/tmdarc or
~/.tmda/config and use the macro or variable name in the filter
rule. Defining a variable can be more flexible, especially for
multiple users at a single site who need the same SELECT statement
with minor modifications. For example, you could define this
SELECT statement in your /etc/tmdarc: <br>
<pre>
<code>SQL_WHITELIST = """
SELECT wl.address
FROM whitelist AS wl, users AS u
WHERE u.uid = wl.uid
AND u.address = %(recipient)s
AND %(criteria)s
LIMIT 1"""</code></pre>
This assumes a 'users' table with a unique ID (<code>uid</code>)
and the user's email address (<code>address</code>). It joins the
'users' and 'whitelist' tables based on the
<code>uid</code>. Details on '%(recipient)s' and '%(criteria)s'
can be found below. <br>
<br>
A rule in your incoming filter using this variable would look like
this: <br>
<pre>
<code>from-sql -addr_column=wl.address "${SQL_WHITELIST}" accept</code></pre>
Note that the variable is quoted because it is a string that
contains spaces. <br>
<br>
<i>Pre-requisite</i>: In either /etc/tmdarc or ~/.tmda/config you
must set the <a
href="config-vars.html#DB_CONNECTION">DB_CONNECTION</a> variable
so that TMDA can talk to the database. How this is done depends on
the database module used. Examples: <br>
<br>
<dl>
<dt>MySQLdb</dt>
<dd><pre><code>DB_CONNECTION = MySQLdb.connect(db='<dbname>',
host='<dbhost>',
user='<username>',
passwd='<password>')</code></pre></dd>
<dt>PyGreSQL</dt>
<dd><pre><code>DB_CONNECTION = pgdb.connect('<dbhost>:<dbname>:<username>:<password>')</code></pre>
</dd>
</dl>
<h4>Wildcard Searches</h4>
The <code>*-sql</code> rules can be used in two scenarios. If the
<code>-wildcards</code> argument is given, the <SQL_query>
is run and the resulting data set is read, in its entirety, from
the database. The first column should be the addresses to match
against. The second column is optional, but if it is present, it
should be the overriding action or NULL. The returned data is
searched in exactly the same way as text files containing
wildcards. See <a href="#email_address">Email Addresses</a>
below. <br>
<br>
Any columns beyond the second will be ignored. This can come in
handy if you need a column in the SELECT list for an ORDER BY
clause. Because the search code stops at the first match, unsorted
data could cause an incorrect match and the overriding action
might not be what you want. If you use wildcards in the address
column and you allow an overriding action, you should sort the
returned values using an ORDER BY clause.
<h4>Exact Match Searches</h4>
If an exact match of the sender or recipient is all you need,
e.g. you don't need wildcards, then you can use the *-sql rules to
have the database perform the search for you, returning only the
rows that exactly matched. You should specify the
<code>-addr_column</code> argument and provide the name of the
column that contains the addresses to search. You do <b>not</b>
need to include this column in the SELECT list. <br>
<br>
If you have an overriding action column, you should give its name
using the <code>-action_column</code> argument. If you use the
<code>-action_column</code> argument, you <b>must</b> include that
column in the SELECT list. <br>
<br>
<i>Caveat</i>: When the exact-match form of the
<code>from-sql</code> rule is used, TMDA can search for more than
one sender at once. If the SELECT statement returns more than one
row, TMDA will use the overriding action from the first row, since
it has no way of knowing which sender (the From:, the Reply-To: or
the envelope sender address) you care most about. Instead of
using overriding actions, consider using separate blacklists and
whitelists. <br>
<br>
Your SELECT statement can be as complex as you care to make it,
including joins, an ORDER BY clause, a LIMIT clause, etc. TMDA
must know where to place the search conditions ("<sender1> =
<addr_column> OR <sender2> = <addr_column>",
etc.). You should include the string "%(criteria)s" in your SELECT
statement at the appropriate location. TMDA will build the list of
conditions based on the addresses to be matched and will replace
"%(criteria)s" with that list. Here's an example to make this
clearer. <br>
<br>
Assume you have the following rule in your incoming filter.<br>
<pre>
<code>from-sql -addr_column=address <SQL_query> ok</code></pre>
An email arrives with a From: header of "friend@example.com" and
a Reply-To: header of "friend@another.com". TMDA will generate the
following criteria string: <br>
<pre>
<code>(address = 'friend@example.com' OR address = 'friend@another.com')</code></pre>
Your SELECT statement (<SQL_query>) might look something like this:<br>
<pre>
<code>SELECT address FROM addr_list WHERE %(criteria)s</code></pre>
The SQL code that TMDA actually sends to the database will look
like this (reformatted for easier readability):<br>
<pre>
<code>SELECT address
FROM addr_list
WHERE (address = 'friend@example.com' OR
address = 'friend@another.com')</code></pre>
If you store all of your users' whitelists in a single table (a
good schema design), you will need some way to restrict your
search to a single user's list; the user whose copy of TMDA is
querying the database. In order to facilitate that, the
<code>from-sql</code> and <code>to-sql</code> rules provide three
strings that can be used anywhere in your SELECT statement.<br>
<br>
<ul>
<li>username -- the value of the USERNAME variable from ~/.tmda/config
<li>hostname -- the value of the HOSTNAME variable from ~/.tmda/config
<li>recipient -- username@hostname
</ul>
<br>
You can place these in your SELECT statement by using
"%(username)s", "(%hostname)s" and/or "%(recipient)s", as needed.
TMDA will substitute the appropriate values into the SELECT at the
time of the search. Do not put quotes around the above
variables. The Python DB API takes care of that for you in a
manner appropriate for the database you are using. <br>
<br>
</dl>
The following group of sources may be used only in incoming filter files. <br>
<br>
<dl>
<dt>
<code>
body [ -case ] <regular_expression><br>
headers [ -case ] <regular_expression>
</code>
<dd>
The <code>body</code> and <code>headers</code> sources expect a match
field that is a regular expression as defined in Python's <a
href="http://www.python.org/doc/current/lib/module-re.html"
TARGET="Resource Window">re module</a>. The <code>body</code> source
matches against the body of the message while the <code>headers</code>
matches against the header fields.
<br><br>
Because regular expressions may include spaces, you must surround the
regular expressions with quotation marks. You may use either single
quotes (<code><b>'</b></code>) or double quotes
(<code><b>"</b></code>) as long as you use the the same one at both
the beginning and the end.
<br><br>
If you need to match a quote in your regular expression, simply use
the other style of quotes to surround the expression or escape the
embedded quote with a backslash (<code><b>\</b></code>).
<br><br>
The regular expression match is case-insensitive by default. If you
want a case-sensitive match, specify the <code>-case</code> flag.
<br><br>
<dt>
<code>
body-file [ -case ] [-optional ] <a href="#re_file"><regexp_file></a><br>
headers-file [ -case ] [-optional ] <a href="#re_file"><regexp_file></a>
</code>
<dd>
The <code>body-file</code> and <code>headers-file</code> sources
expect the match field to contain the filename of a textfile
containing one or more regular expressions as defined in Python's <a
href="http://www.python.org/doc/current/lib/module-re.html"
TARGET="Resource Window">re module</a>. The <code>body-file</code>
source matches against the body of the message while the
<code>headers-file</code> matches against the header fields. The
format of the regular expression file is documented <a
href="#re_file">below</a>.
<br><br>
The regular expression match is case-insensitive by default. If you
want a case-sensitive match, specify the <code>-case</code> flag.
<br><br>
If the <code>-optional</code> flag is given, the non-existence of the
file is not an error. If the file should exist, don't specify this
flag; the parser will log an error and will defer the mail so that you
have a chance to fix the problem.
<br><br>
<dt>
<code>
size < <size_in_bytes | >size_in_bytes >
</code>
<dd>
The <code>size</code> source expects a comparison operator and a
number of bytes to compare to the size of the message. Only the
`<' and `>' operators are supported. There must not be any
whitespace between the operator and the number.
<br><br>
<dt>
<code>
pipe <command_string>
</code>
<dd>
The <code>pipe</code> source expects a shell command string to which the
full contents of the incoming message will be piped to. A match is found
if <code>command_string</code> returns a zero exit status. Any non-zero
exit status is interpreted as a non-match. If <code>command_string</code>
contains whitespace, it should be quoted.
<br><br>
</dl>
<h3>Miscellaneous Notes</h3>
<dl>
<dt> <a name="email_address"><b>Email Addresses</b></a>
<dd> In addition to explicit email addresses, you can use expressions based
on UNIX shell-style wildcard characters anywhere an email address is expected.
<br>
<br>
<strong>NOTE:</strong> Wildcard characters are not recognized in a CDB or
DBM file and are only recognized in SQL databases if you specify
the -wildcards argument to the rule. <br>
<br>
The special characters are:
<blockquote><pre>
Characters(s) Description
------------- -----------
* Matches everything.
? Matches any single character.
[seq] Matches any character in seq.
[!seq] Matches any character not in seq.
</blockquote></pre>
In addition, `<code>@=</code>' (a custom rule) will expand to match both <code>@</code>
and <code>@*.</code> <br>
<br>
Here are some common examples:
<pre><blockquote>
# match only jdoe@domain.dom
jdoe@domain.dom
# match anyone@domain.dom, but not anyone@sub.domain.dom
*@domain.dom
# match anyone@sub.domain.dom, but not anyone@domain.dom
*@*.domain.dom
# match both anyone@domain.dom, and anyone@sub.domain.dom
*@=domain.dom
</blockquote></pre>
<strong>NOTE:</strong> To match the empty envelope sender such as bounce messages
are sent with, use <b><code><></code></b> as the expression. <br>
<br>
<dt> <a name="email_file"><b>Email Address Files</b></a>
<dd> Email address files are textfiles containing an email address, domain, or
wildcarded email address on each line.
When using the <code>from-file</code> and <code>to-file</code> sources, the
textfile is searched sequentially, with the first match terminating the search.
<br><br>
Address files may contain an optional second field on each line that specifies
an action (<code>ok, drop, bounce, etc.</code>). If the action is specified,
it overrides the action given in the filter rule. <br>
<br>
<dt> <a name="autoflags"><b>Auto- Database Flags</b></a>
<dd> If you have lengthy email address textfiles, you might want to consider
using the much faster hashed databases instead. The address files used by
the auto-building hashed database feature are the same email address textfiles
documented above with the sole exception that wildcards are not supported.
<br>
<br>
The <code>-autocdb</code> and <code>-autodbm</code> arguments are intended
to ease the use of CDB/DBM lists in TMDA by automatically rebuilding the CDB
or DBM file as necessary. This gives you the performance advantages of hashed
databases without the hassle of having to manually maintain them. With the
<code>-auto*</code> arguments, TMDA will rebuild the database if it doesn't
exist or if its timestamp is older than its source file. If the rebuild fails
for some reason, TMDA will fall back to matching from the textfile instead.
<br>
<br>
Before you try the CDB version of this feature, make sure you have the <a href="http://pilcrow.madison.wi.us/#pycdb" TARGET="Resource
Window">python-cdb</a> extension module installed. <br>
<br>
<dt> <a name="db_file"><b>Database Files</b></a>
<dd> CDB and DBM files are hashed databases. TMDA can look up email addresses
or domains in these files. Lookup in these files is much faster than in a textfile. On
the other hand, wildcards are not supported in database files -- only in textfiles.
<br>
<br>
In a CDB or DBM, the keys should be the email addresses or domain to match, and their
corresponding values (or records) should be empty unless you want to override
the action specified in the filter file. <br>
<br>
CDB or DBM files can be created outside of TMDA and merely referenced by your
filter files (use the <code>*-cdb</code> and <code>*-dbm</code> filter rules)
or can be automatically created by TMDA if you use the <code>-autocdb</code>
or <code>-autodbm</code> flags and the <code>*-file</code> rules. <br>
<br>
If you wish to explore CDB databases, make sure you have the <a
href="http://pilcrow.madison.wi.us/#pycdb" TARGET="Resource
Window">python-cdb</a> extension module installed. <br>
<br>
<dd></dt>
<dd></dt>
<dt> <a name="re_file"><b>Regular Expression Files</b></a>
<dd> A regular expression textfile is simply a text file with a regular expression
on each line. The file is read sequentially and each regular expression is
used to attempt a match. As soon as there is a match, the search stops. <br>
<br>
Because regular expressions may include spaces, you must surround the regular
expressions with quotation marks. You may use either single quotes (<code><b>'</b></code>)
or double quotes (<code><b>"</b></code>) as long as you use the the same one
at both the beginning and the end. <br>
<br>
If you need to match a quote in your regular expression, simply use the other
style of quotes to surround the expression or escape the embedded quote with
a backslash (<code><b>\</b></code>). <br>
<br>
</dl>
</td><!-- end of body cell -->
</tr><!-- end of sidebar/body row -->
</table><!-- end of page table -->
</body></html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
4c2411a08c8df257138f687227a41525
>
files
>
93
