News Shogun

Low-Level Details

The overview page is a necessary prerequisite to understanding this page. If you want more information, please see the Extension API page.

Index:

• The spam.conf file
• Text substitution
• User resolution and authentication

The spam.conf file

This file is made up of nothing but keyword:value pairs. Parsing this file is the first thing that gets done by the package.. Every time it runs into a new keyword, it allocates space in a keyword list it maintains with a value being the stuff on the line after the colon.

There are seven keywords defined by the system:

mail

The mail program to use to send notification of spam.

mail.text

The text of the mail sending notification.

limitconf

User posting limits filename.

hold.dir

The directory in which to store delayed posts.

hold.deldir

The directory which holds posts pending deletion.

mail.error

program with arguments to call when an error occurs

mail.error.text

Text of the error message

It is also possible to hook into other functions using variable keyword names as parameters to a static function. Currently, you can set global substitution variables using this method (e.g. VAR(spammaster):staff@panix.com). Currently defined hooks are:

VAR(parameter):value

Set text substitution variable %parameter to value.

back to top

Text substitution

Text substitution happens on request. Strings of the format <%ID> are replaced according to a function set up for just this purpose.

System defined substitutions are:

%U

username of the person connected.

%P.CUR

number of posts sent out.

%P.SLOW

User's slowness threshhold.

%P.STOP

User's blocking threshhold.

%NOT

How often mail messages get sent out.

%F

Filename storing a user's post.

%E

Error string

%T

Text of the current file (%F above).

It is also possible to set substitution variables from the spam.conf file. This is done by directives of the form VAR(name):value. Instances of <%name> get replaced by value when doing substitution.

back to top

User resolution and authentication

This is actually external to the postlimit code, but since postlimit would be useless to admins without it, it's being described here.

We modify the format for the _PATH_NNRPACCESS file a bit, so that when the username is "+TAG" (without the quotes and where 'TAG' is a user's namespace), it is interpreted as a request to use a non-standard form of authentication. The precise form to use is determined by the third (or password) field, which is of the format

scheme(parameters to scheme),scheme(parameters to scheme)@domain....

The left and right parentheses must match (although, if there are no parentheses, the specified function is called with an argument of null), and of course, no part of the parameter can contain a colon. Apart from that, there are no restrictions placed on the format of the parameters.

Although the default authenticators we provide should be adequate for most sites, having an extensible format should be much better for cross-platformness (crypt(3) doesn't necessarily exist, or yield the same values on different platforms) and security (yes, I know the pw is being sent in cleartext anyway, but if the site is otherwise more security conscious and doesn't like how easy 64-bit DES is to crack..)

Note that we will also accept output from generic authenticators to set the username, so if you write a default authenticator, please make it emit username and domain info.

back to top