FileRegexMatcher

HasMailAttributeWithValueRegex

This Matcher determines if the mail contains the attribute specified in the condition and that attribute matches the supplied regular expression, it returns all recipients if that is the case.

Sample configuration:

<mailet match="HasMailAttributeWithValueRegex=whatever," class="<any-class>">

InSpammerBlacklist

• blackholes.mail-abuse.org: Rejected - see http://www.mail-abuse.org/rbl/
• dialups.mail-abuse.org: Dialup - see http://www.mail-abuse.org/dul/
• relays.mail-abuse.org: Open spam relay - see http://www.mail-abuse.org/rss/

IsInWhiteList

Matches recipients having the mail sender in the recipient's private whitelist .

The recipient name is always converted to its primary name (handling aliases).

Configuration string: The database name containing the white list table.

Example:

<mailet match="IsInWhiteList=db://maildb" class="ToProcessor">
<processor> transport </processor>
</mailet>

NESSpamCheck

RecipientIsOverFixedQuota

Experimental: Checks whether a recipient has exceeded a maximum allowed quota for messages standing in his inbox. Such quota is the same for all users.

Will check if the total size of all his messages in the inbox are greater than a certain number of bytes. You can use 'k' and 'm' as optional postfixes. In other words, "1m" is the same as writing "1024k", which is the same as "1048576".

Here follows an example of a config.xml definition:

<processor name="transport">
.
.
.
<mailet match=match="RecipientIsOverFixedQuota=40M" class="ToProcessor">
<processor> error </processor>
<notice>The recipient has exceeded maximum allowed size quota</notice>
</mailet>
.
.
.
</processor>

This matcher need to calculate the mailbox size everytime it is called. This can slow down things if there are many mails in the mailbox. Some users also report big problems with the matcher if a JDBC based mailrepository is used.

RecipientIsRegex

Matches recipients whose address matches a regular expression.

Is equivalent to the {@link SenderIsRegex} matcher but matching on the recipient.

Configuration string: a regular expression.

<mailet match="RecipientIsRegex=<regular-expression>" class="<any-class>">

The example below will match any recipient in the format user@log.anything

<mailet match="RecipientIsRegex=(.*)@log\.(.*)" class="<any-class>">
</mailet>

RemoteAddrInNetwork

See AbstractNetworkMatcher for details on how to specify entries.

RemoteAddrNotInNetwork

See AbstractNetworkMatcher for details on how to specify entries.

SenderInFakeDomain

SenderIsRegex

Matches mails that are sent by a sender whose address matches a regular expression.

Is equivalent to the {@link RecipientIsRegex} matcher but matching on the sender.

Configuration string: a regular expression.

<mailet match="SenderIsRegex=<regular-expression>" class="<any-class>">

The example below will match any sender in the format user@log.anything

<mailet match="SenderIsRegex=(.*)@log\.(.*)" class="<any-class>">
</mailet>

Another example below will match any sender having some variations of the string mp3 inside the username part.

<mailet match="SenderIsRegex=(.*)(mp3|emmepitre)(.*)@" class="<any-class>">
</mailet>

AvalonListserv

Requires a configuration element in the config.xml file of the form:
<mailet match="RecipientIs=LIST-ADDRESS" class="AvalonListserv">
<repositoryName>LIST-NAME</repositoryName>
<membersonly>[true|false]</membersonly>
<attachmentsallowed>[true|false]</attachmentsallowed>
<replytolist>[true|false]</replytolist>
<autobracket>[true|false]</autobracket>
<subjectprefix [xml:space="preserve"]>SUBJECT-PREFIX</subjectprefix>
</mailet>

repositoryName - the name of a user repository configured in the UsersStore block, e.g.,
<repository name="list-name" class="org.apache.james.userrepository.ListUsersJdbcRepository" destinationURL="db://maildb/lists/list-name">
<sqlFile>file://conf/sqlResources.xml</sqlFile>
</repository>

or
<repository name="list-name" class="org.apache.james.userrepository.UsersFileRepository">
<destination URL="file://var/lists/list-name/"/>
</repository>

membersonly - if true only members can post to the list

attachmentsallowed - if false attachments are not allowed

replytolist - if true, replies go back to the list address; if false they go to the sender.

subjectprefix - a prefix that will be inserted at the front of the subject. If autobracketing is disabled (see below), the xml:space="preserve" attribute can be used to precisely control the prefix.

autobracket - if true the subject prefix will be rendered as "[PREFIX] ", if false, the prefix will be used literally.

AvalonListservManager

Sample configuration:
<mailet match="CommandForListserv=james@list.working-dogs.com" class="AvalonListservManager">
<repositoryName>name of user repository configured in UsersStore block </repositoryName>
</mailet>

BayesianAnalysis

Spam detection mailet using bayesian analysis techniques.

Sets an email message header indicating the probability that an email message is SPAM.

Based upon the principals described in: A Plan For Spam by Paul Graham. Extended to Paul Grahams' Better Bayesian Filtering.

The analysis capabilities are based on token frequencies (the Corpus) learned through a training process (see {@link BayesianAnalysisFeeder}) and stored in a JDBC database. After a training session, the Corpus must be rebuilt from the database in order to acquire the new frequencies. Every 10 minutes a special thread in this mailet will check if any change was made to the database by the feeder, and rebuild the corpus if necessary.

A org.apache.james.spam.probability mail attribute will be created containing the computed spam probability as a {@link java.lang.Double}. The headerName message header string will be created containing such probability in floating point representation.

Sample configuration:

<mailet match="All" class="BayesianAnalysis">
<repositoryPath>db://maildb</repositoryPath>
<!--
Set this to the header name to add with the spam probability
(default is "X-MessageIsSpamProbability").
-->
<headerName>X-MessageIsSpamProbability</headerName>
<!--
Set this to true if you want to ignore messages coming from local senders
(default is false).
By local sender we mean a return-path with a local server part (server listed
in <servernames> in config.xml).
-->
<ignoreLocalSender>true</ignoreLocalSender>
<!--
Set this to the maximum message size (in bytes) that a message may have
to be considered spam (default is 100000).
-->
<maxSize>100000</maxSize>
<!--
Set this to false if you not want to tag the message if spam is detected (Default is true).
-->
<tagSubject>true</tagSubject>
</mailet>

The probability of being spam is pre-pended to the subject if it is > 0.1 (10%).

The required tables are automatically created if not already there (see sqlResources.xml). The token field in both the ham and spam tables is case sensitive.

BayesianAnalysisFeeder

Feeds ham OR spam messages to train the {@link BayesianAnalysis} mailet.

The new token frequencies will be stored in a JDBC database.

Sample configuration:

<processor name="root">

<mailet match="RecipientIs=not.spam@thisdomain.com" class="BayesianAnalysisFeeder">
<repositoryPath> db://maildb </repositoryPath>
<feedType>ham</feedType>
<!--
Set this to the maximum message size (in bytes) that a message may have
to be analyzed (default is 100000).
-->
<maxSize>100000</maxSize>
</mailet>

<mailet match="RecipientIs=spam@thisdomain.com" class="BayesianAnalysisFeeder">
<repositoryPath> db://maildb </repositoryPath>
<feedType>spam</feedType>
<!--
Set this to the maximum message size (in bytes) that a message may have
to be analyzed (default is 100000).
-->
<maxSize>100000</maxSize>
</mailet>

<processor>

The previous example will allow the user to send messages to the server and use the recipient email address as the indicator for whether the message is ham or spam.

Using the example above, send good messages (ham not spam) to the email address "not.spam@thisdomain.com" to pump good messages into the feeder, and send spam messages (spam not ham) to the email address "spam@thisdomain.com" to pump spam messages into the feeder.

The bayesian database tables will be updated during the training reflecting the new data

At the end the mail will be destroyed (ghosted).

The correct approach is to send the original ham/spam message as an attachment to another message sent to the feeder; all the headers of the enveloping message will be removed and only the original message's tokens will be analyzed.

After a training session, the frequency Corpus used by BayesianAnalysis must be rebuilt from the database, in order to take advantage of the new token frequencies. Every 10 minutes a special thread in the BayesianAnalysis mailet will check if any change was made to the database, and rebuild the corpus if necessary.

Only one message at a time is scanned (the database update activity is synchronized) in order to avoid too much database locking, as thousands of rows may be updated just for one message fed.

Bounce

Generates a response to the reverse-path address. Note that this is different than a mail-client's reply, which would use the Reply-To or From header.

Bounced messages are attached in their entirety (headers and content) and the resulting MIME part type is "message/rfc822".
The reverse-path and the Return-Path header of the response is set to "null" ("<>"), meaning that no reply should be sent.

A sender of the notification message can optionally be specified. If one is not specified, the postmaster's address will be used.
A notice text can be specified, and in such case will be inserted into the notification inline text.
If the notified message has an "error message" set, it will be inserted into the notification inline text. If the attachStackTrace init parameter is set to true, such error message will be attached to the notification message.

Supports the passThrough init parameter (true if missing).

Sample configuration:

<mailet match="All" class="Bounce">
<sender>an address or postmaster or sender or unaltered, default=postmaster</sender>
<attachError>true or false, default=false</attachError>
<message>notice attached to the original message text (optional)</message>
<prefix>optional subject prefix prepended to the original message</prefix>
<inline>see {@link Resend}, default=none</inline>
<attachment>see {@link Resend}, default=message</attachment>
<passThrough>true or false, default=true</passThrough>
<fakeDomainCheck>true or false, default=true</fakeDomainCheck>
<debug>true or false, default=false</debug>
</mailet>

The behaviour of this mailet is equivalent to using Resend with the following configuration:

<mailet match="All" class="Resend">
<sender>an address or postmaster or sender or unaltered</sender>
<attachError>true or false</attachError>
<message>dynamically built</message>
<prefix>a string</prefix>
<passThrough>true or false</passThrough>
<fakeDomainCheck>true or false</fakeDomainCheck>
<recipients>sender</recipients>
<reversePath>null</reversePath>
<inline>see {@link Resend}</inline>
<attachment>see {@link Resend}</attachment>
<isReply>true</isReply>
<debug>true or false</debug>
</mailet>

notice and sendingAddress can be used instead of message and sender; such names are kept for backward compatibility.

CommandListservManager

<listName>-<commandName>@domain

<mailet match="CommandListservMatcher=announce@localhost" class="CommandListservManager">
<listName>announce</listName>
<displayName>Announce mailing list</displayName>
<listOwner>owner@localhost</listOwner>
<repositoryName>list-announce</repositoryName>
<listDomain>localhost</listDomain>

<commandpackages>
<commandpackage>org.apache.james.transport.mailets.listservcommands</commandpackage>
</commandpackages>

<commands>
<command name="subscribe" class="Subscribe"/>
<command name="subscribe-confirm" class="SubscribeConfirm"/>
<command name="unsubscribe" class="UnSubscribe"/>
<command name="unsubscribe-confirm" class="UnSubscribeConfirm"/>
<command name="error" class="ErrorCommand"/>
<command name="owner" class="Owner"/>
<command name="info" class="Info"/>
</commands>
</mailet>

<listName>-<commandName>-<optCommandParam>@domain

CommandListservProcessor

<mailet match="RecipientIs=announce@localhost" class="CommandListservProcessor">
<membersonly>false</membersonly>
<attachmentsallowed>true</attachmentsallowed>
<replytolist>true</replytolist>
<repositoryName>list-announce</repositoryName>
<subjectprefix>Announce</subjectprefix>
<autobracket>true</autobracket>
<listOwner>owner@localhost</listOwner>
<listName>announce</listName>
<addFooter>true</addFooter>
</mailet>

DSNBounce

Generates a Delivery Status Notification (DSN) Note that this is different than a mail-client's reply, which would use the Reply-To or From header.

Bounced messages are attached in their entirety (headers and content) and the resulting MIME part type is "message/rfc822".
The reverse-path and the Return-Path header of the response is set to "null" ("<>"), meaning that no reply should be sent.

A sender of the notification message can optionally be specified. If one is not specified, the postmaster's address will be used.

Supports the passThrough init parameter (true if missing).

Sample configuration:

<mailet match="All" class="DSNBounce">
<sender>an address or postmaster or sender or unaltered,
default=postmaster</sender>
<prefix>optional subject prefix prepended to the original
message</prefix>
<attachment>message, heads or none, default=message</attachment>
<messageString>the message sent in the bounce, the first occurrence of the pattern [machine] is replaced with the name of the executing machine, default=Hi. This is the James mail server at [machine] ... </messageString>
<passThrough>true or false, default=true</passThrough>
<debug>true or false, default=false</debug>
</mailet>

Forward

Replaces incoming recipients with those specified, and resends the message unaltered.

Can be totally replaced by an equivalent usage of {@link Resend} (see below), simply replacing <forwardto> with <recipients>.

Sample configuration:

<mailet match="All" class="Forward">
<forwardTo>comma delimited list of email addresses</forwardTo>
<passThrough>true or false, default=false</passThrough>
<fakeDomainCheck>true or false, default=true</fakeDomainCheck>
<debug>true or false, default=false</debug>
</mailet>

The behaviour of this mailet is equivalent to using Resend with the following configuration:

<mailet match="All" class="Resend">
<recipients>comma delimited list of email addresses</recipients>
<passThrough>true or false</passThrough>
<fakeDomainCheck>true or false</fakeDomainCheck>
<debug>true or false</debug>
</mailet>

forwardto can be used instead of forwardTo; such name is kept for backward compatibility.

FromRepository

JDBCAlias

JDBCListserv

JDBCVirtualUserTable

Implements a Virtual User Table for JAMES. Derived from the JDBCAlias mailet, but whereas that mailet uses a simple map from a source address to a destination address, this handles simple wildcard selection, verifies that a catchall address is for a domain in the Virtual User Table, and handles forwarding. JDBCVirtualUserTable does not provide any administation tools. You'll have to create the VirtualUserTable yourself. The standard configuration is as follows: CREATE TABLE VirtualUserTable ( user varchar(64) NOT NULL default '', domain varchar(255) NOT NULL default '', target_address varchar(255) NOT NULL default '', PRIMARY KEY (user,domain) ); The user column specifies the username of the virtual recipient, the domain column the domain of the virtual recipient, and the target_address column the email address of the real recipient. The target_address column can contain just the username in the case of a local user, and multiple recipients can be specified in a list separated by commas, semi-colons or colons. The standard query used with VirtualUserTable is: select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains where (VirtualUserTable.user like ? or VirtualUserTable.user like "\%") and (VirtualUserTable.domain like ? or (VirtualUserTable.domain like "\%" and VUTDomains.domain like ?)) order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1 For a given [user, domain, domain] used with the query, this will match as follows (in precedence order): 1. user@domain - explicit mapping for user@domain 2. user@% - catchall mapping for user anywhere 3. %@domain - catchall mapping for anyone at domain 4. null - no valid mapping You need to set the connection. At the moment, there is a limit to what you can change regarding the SQL Query, because there isn't a means to specify where in the query to replace parameters. [TODO] <mailet match="All" class="JDBCVirtualUserTable"> <table>db://maildb/VirtualUserTable</table> <sqlquery>sqlquery</sqlquery> </mailet>

NotifyPostmaster

Mailet Info: NotifyPostmaster Mailet

Sends a notification message to the Postmaster.

A sender of the notification message can optionally be specified. If one is not specified, the postmaster's address will be used.
The "To:" header of the notification message can be set to "unaltered"; if missing will be set to the postmaster.
A notice text can be specified, and in such case will be inserted into the notification inline text.
If the notified message has an "error message" set, it will be inserted into the notification inline text. If the attachStackTrace init parameter is set to true, such error message will be attached to the notification message.
The notified messages are attached in their entirety (headers and content) and the resulting MIME part type is "message/rfc822".

Supports the passThrough init parameter (true if missing).

Sample configuration:

<mailet match="All" class="NotifyPostmaster">
<sender>an address or postmaster or sender or unaltered, default=postmaster</sender>
<attachError>true or false, default=false</attachError>
<message>notice attached to the original message text (optional)</message>
<prefix>optional subject prefix prepended to the original message, default="Re:"</prefix>
<inline>see {@link Resend}, default=none</inline>
<attachment>see {@link Resend}, default=message</attachment>
<passThrough>true or false, default=true</passThrough>
<fakeDomainCheck>true or false, default=true</fakeDomainCheck>
<to>unaltered (optional, defaults to postmaster)</to>
<debug>true or false, default=false</debug>
</mailet>

The behaviour of this mailet is equivalent to using Resend with the following configuration:

<mailet match="All" class="Resend">
<sender>an address or postmaster or sender or unaltered</sender>
<attachError>true or false</attachError>
<message>dynamically built</message>
<prefix>a string</prefix>
<passThrough>true or false</passThrough>
<fakeDomainCheck>true or false</fakeDomainCheck>
<to>unaltered or postmaster</to>
<recipients>postmaster</recipients>
<inline>see {@link Resend}</inline>
<attachment>see {@link Resend}</attachment>
<isReply>true</isReply>
<debug>true or false</debug>
</mailet>

notice, sendingAddress and attachStackTrace can be used instead of message, sender and attachError; such names are kept for backward compatibility.

NotifySender

Mailet Info: NotifySender Mailet

Sends a notification message to the sender of a message.

A sender of the notification message can optionally be specified. If one is not specified, the postmaster's address will be used.
The "To:" header of the notification message can be set to "unaltered"; if missing will be set to the sender of the notified message.
A notice text can be specified, and in such case will be inserted into the notification inline text.
If the notified message has an "error message" set, it will be inserted into the notification inline text. If the attachStackTrace init parameter is set to true, such error message will be attached to the notification message.
The notified messages are attached in their entirety (headers and content) and the resulting MIME part type is "message/rfc822".

Supports the passThrough init parameter (true if missing).

Sample configuration:

<mailet match="All" class="NotifySender">
<sender>an address or postmaster or sender or unaltered, default=postmaster</sender>
<attachError>true or false, default=false</attachError>
<prefix>optional subject prefix prepended to the original message</prefix>
<inline>see {@link Resend}, default=none</inline>
<attachment>see {@link Resend}, default=message</attachment>
<passThrough>true or false, default=true</passThrough>
<fakeDomainCheck>true or false, default=true</fakeDomainCheck>
<to>unaltered or sender or from(optional, defaults to sender)</to>
<debug>true or false, default=false</debug>
</mailet>

The behaviour of this mailet is equivalent to using Resend with the following configuration:

<mailet match="All" class="Resend">
<sender>an address or postmaster or sender or unaltered</sender>
<attachError>true or false</attachError>
<message>dynamically built</message>
<prefix>a string</prefix>
<passThrough>true</passThrough>
<fakeDomainCheck>true or false</fakeDomainCheck>
<to>unaltered or sender or from<;/to>
<recipients>sender</recipients>
<inline>none</inline>
<attachment>message</attachment>
<isReply>true</isReply>
<debug>true or false</debug>
</mailet>

notice, sendingAddress and attachStackTrace can be used instead of message, sender and attachError; such names are kept for backward compatibility.

Redirect

Mailet Info: Redirect Mailet

A mailet providing configurable redirection services.

Can produce listserver, forward and notify behaviour, with the original message intact, attached, appended or left out altogether.

It differs from {@link Resend} because (i) some defaults are different, notably for the following parameters: <recipients>, <to>, <reversePath> and <inline>; (ii) because it allows the use of the <static> parameter;.
Use Resend if you need full control, Redirect if the more automatic behaviour of some parameters is appropriate.

This built in functionality is controlled by the configuration as laid out below. In the table please note that the parameters controlling message headers accept the "unaltered" value, whose meaning is to keep the associated header unchanged and, unless stated differently, corresponds to the assumed default if the parameter is missing.

The configuration parameters are:

Example:

<mailet match="RecipientIs=test@localhost" class="Redirect">
<recipients>x@localhost, y@localhost, z@localhost</recipients>
<to>list@localhost</to>
<sender>owner@localhost</sender>
<message>sent on from James</message>
<inline>unaltered</inline>
<passThrough>FALSE</passThrough>
<replyTo>postmaster</replyTo>
<prefix xml:space="preserve">[test mailing] </prefix>
<!-- note the xml:space="preserve" to preserve whitespace -->
<static>TRUE</static>
</mailet>

and:

<mailet match="All" class="Redirect">
<recipients>x@localhost</recipients>
<sender>postmaster</sender>
<message xml:space="preserve">Message marked as spam:</message>
<inline>heads</inline>
<attachment>message</attachment>
<passThrough>FALSE</passThrough>
<attachError>TRUE</attachError>
<replyTo>postmaster</replyTo>
<prefix>[spam notification]</prefix>
<static>TRUE</static>
</mailet>

replyto can be used instead of replyTo; such name is kept for backward compatibility.

RemoteDelivery

Mailet Info: RemoteDelivery Mailet

Receives a MessageContainer from JamesSpoolManager and takes care of delivery the message to remote hosts. If for some reason mail can't be delivered store it in the "outgoing" Repository and set an Alarm. After the next "delayTime" the Alarm will wake the servlet that will try to send it again. After "maxRetries" the mail will be considered undeliverable and will be returned to sender.

TO DO (in priority):

1. Support a gateway (a single server where all mail will be delivered) (DONE)
2. Provide better failure messages (DONE)
3. More efficiently handle numerous recipients
4. Migrate to use Phoenix for the delivery threads

You really want to read the JavaMail documentation if you are working in here, and you will want to view the list of JavaMail attributes, which are documented here as well as other places.

Resend

Mailet Info: Redirect Mailet

A mailet providing configurable redirection services.

Can produce listserver, forward and notify behaviour, with the original message intact, attached, appended or left out altogether. Can be used as a replacement to {@link Redirect}, having more consistent defaults, and new options available.
Use Resend if you need full control, Redirect if the more automatic behaviour of some parameters is appropriate.

This built in functionality is controlled by the configuration as laid out below. In the table please note that the parameters controlling message headers accept the "unaltered" value, whose meaning is to keep the associated header unchanged and, unless stated differently, corresponds to the assumed default if the parameter is missing.

The configuration parameters are:

Example:

<mailet match="RecipientIs=test@localhost" class="Resend">
<recipients>x@localhost, y@localhost, z@localhost</recipients>
<to>list@localhost</to>
<sender>owner@localhost</sender>
<message>sent on from James</message>
<inline>unaltered</inline>
<passThrough>FALSE</passThrough>
<replyTo>postmaster</replyTo>
<prefix xml:space="preserve">[test mailing] </prefix>
<!-- note the xml:space="preserve" to preserve whitespace -->
<static>TRUE</static>
</mailet>

and:

<mailet match="All" class="Resend">
<recipients>x@localhost</recipients>
<sender>postmaster</sender>
<message xml:space="preserve">Message marked as spam:</message>
<inline>heads</inline>
<attachment>message</attachment>
<passThrough>FALSE</passThrough>
<attachError>TRUE</attachError>
<replyTo>postmaster</replyTo>
<prefix>[spam notification]</prefix>
</mailet>

The following example forwards the message without any modification, based on the defaults:

<mailet match="All" class="Resend"/;>

replyto can be used instead of replyTo; such name is kept for backward compatibility.

WARNING: as the message (or a copy of it) is reinjected in the spool without any modification, the preceding example is very likely to cause a "configuration loop" in your system, unless some other mailet has previously modified something (a header for instance) that could force the resent message follow a different path so that it does not return here unchanged.

Retry

Mailet Info: Retry Mailet

This Mailet retries delivery of a mail based on schedule specified in the James configuration file by the 'delayTime' attribute. The format of the 'delayTime' attribute is: [attempts*]delay[units]

For example, if the delay times were specified as follows:
4*15 minutes 3*1 hour 3*4 hours 10 after the initial failure, the message will be retried by sending it to the processor specified by the 'retryProcessor' attribute, as per the following schedule: 1) 4 attempts will be made every 15 minutes. 2) 3 attempts will be made every hour. 3) 3 attempts will be made every 4 hours. If the message still fails, it will be sent for error processing to the processor specified by the 'errorProcessor' attribute.

Following list summarizes all the attributes of this Mailet that can be configured:

• retryRepository - Spool repository where mails are stored.
• delayTime - Delay time (See description above).
• maxRetries - Maximum no. of retry attempts.
• retryThreads - No. of Threads used for retrying.
• retryProcessor - Processor used for retrying.
• errorProcessor - Error processor that will be used when all retry attempts fail.
• isDebug - Can be set to 'true' for debugging.

SPF

Check the ip, sender, helo against SPF. Add the following attributes to the mail object: org.apache.james.transport.mailets.spf.explanation org.apache.james.transport.mailets.spf.result Sample configuration: true false

SpamAssassin

Mailet Info: Checks message against SpamAssassin

Sends the message through daemonized SpamAssassin (spamd), visit SpamAssassin.org for info on configuration. The header X-Spam-Status is added to every message, this contains the score and the threshold score for spam (usually 5.0). If the message exceeds the threshold, the header X-Spam-Flag will be added with the value of YES. The default host for spamd is localhost and the default port is 783.
org.apache.james.spamassassin.status - Holds the status org.apache.james.spamassassin.flag - Holds the flag
Sample Configuration:

<mailet notmatch="SenderHostIsLocal" class="SpamAssassin"> <spamdHost>localhost</spamdHost> <spamdPort>783</spamdPort>

ToRepository

Mailet Info: ToRepository Mailet

Stores incoming Mail in the specified Repository. If the "passThrough" in confs is true the mail will be returned untouched in the pipe. If false will be destroyed.

WhiteListManager

Mailet Info: White List Manager mailet

Manages for each local user a "white list" of remote addresses whose messages should never be blocked as spam.

The normal behaviour is to check, for a local sender, if a remote recipient is already in the list: if not, it will be automatically inserted. This is under the interpretation that if a local sender X sends a message to a remote recipient Y, then later on if a message is sent by Y to X it should be considered always valid and never blocked; hence Y should be in the white list of X.

Another mode of operations is when a local sender sends a message to whitelistManagerAddress with one of three specific values in the subject, to (i) send back a message displaying a list of the addresses in his own list; (ii) insert some new addresses in his own list; (iii) remove some addresses from his own list. In all this cases the message will be ghosted and the postmaster will reply to the sender.

The sender name is always converted to its primary name (handling aliases).

Sample configuration:

<mailet match="SMTPAuthSuccessful" class="WhiteListManager">
<repositoryPath> db://maildb </repositoryPath>
<!--
If true automatically inserts the local sender to remote recipients entries in the whitelist (default is false).
-->
<automaticInsert>true</automaticInsert>
<!--
Set this to an email address of the "whitelist manager" to send commands to (default is null).
-->
<whitelistManagerAddress>whitelist.manager@xxx.yyy</whitelistManagerAddress>
<!--
Set this to a unique text that you can use (by sending a message to the "whitelist manager" above)
to tell the mailet to send back the contents of the white list (default is null).
-->
<displayFlag>display whitelist</displayFlag>
<!--
Set this to a unique text that you can use (by sending a message to the "whitelist manager" above)
to tell the mailet to insert some new remote recipients to the white list (default is null).
-->
<insertFlag>insert whitelist</insertFlag>
<!--
Set this to a unique text that you can use (by sending a message to the "whitelist manager" above)
to tell the mailet to remove some remote recipients from the white list (default is null).
-->
<removeFlag>remove whitelist</removeFlag>
</mailet>

XMLVirtualUserTable

Mailet Info: XML Virtual User Table mailet

Implements a Virtual User Table to translate virtual users to real users. This implementation has the same functionality as JDBCVirtualUserTable, but is configured in the JAMES configuration and is thus probably most suitable for smaller and less dynamic mapping requirements. The configuration is specified in the form: <mailet match="All" class="XMLVirtualUserTable"> <mapping>virtualuser@xxx=realuser[@yyy][;anotherrealuser[@zzz]]</mapping> <mapping>virtualuser2@*=realuser2[@yyy][;anotherrealuser2[@zzz]]</mapping> ... </mailet> As many <mapping> elements can be added as necessary. As indicated, wildcards are supported, and multiple recipients can be specified with a semicolon-separated list. The target domain does not need to be specified if the real user is local to the server. Matching is done in the following order: 1. user@domain - explicit mapping for user@domain 2. user@* - catchall mapping for user anywhere 3. *@domain - catchall mapping for anyone at domain 4. null - no valid mapping