James
Translated
Downloads
Current Documentation
Older Documentation
Project
Jakarta Information (web)
Related Projects (web)
|
fetchmail |
fetchmail acts as a gateway between an external message store such as an IMAP
or POP3 server and James. Mail is fetched from the external message store and
injected into the James input spool.
fetchmail is useful when delivery via standard SMTP is not an option, as a
means of consolidating mail delivered to several external accounts into a single
James account, or to apply the mail processing capabilities of James to mail
stored in an external message store.
fetchmail has several configuration options that control the fetching and
filtering of mail injected into the James input spool. Once there, James'
flexible mail processing engine can be used to further process the mail, just as
if it had been delivered via standard SMTP.
How fetchmail Works
fetchmail Configuration Parameters
fetchmail Examples
fetchmail Caveats
|
How fetchmail Works |
Mail is delivered by periodically running fetch tasks that read messages from
an external message store and injects them into the James input spool. Fetch
tasks run concurrently.
A set of filters applies to each fetch task. Each filter provides the ability
to reject a message that matches the filter criteria. Rejected messages are not
injected into the James input spool; they are either marked as seen or deleted.
When a filter is configured to accept a message that matches its criteria,
messages are marked with a MailAttribute. This MailAttribute can be detected
within the James matcher/mailet chain, allowing further processing as
required.
Each fetch task is associated with a single host server. Accounts are defined
to the fetch task for each mailbox on the server from which mail is to be
fetched. Accounts run consecutively.
Optionally, the fetch task can be configured with an <alllocal> Account that
generates an Account entry for each user defined in the James user repository.
This removes the requirement to manually add or remove Account entries to the
fetchmail configuration each time a James user is added or removed. Currently
this is only useful if the server supports virtual mailboxes that allow the same
password to apply to all users within a domain.
Accounts can be configured to deliver all mail for an Account to a specified
recipient or to deduce the intended recipient from the mail headers.
Accounts are normally configured to deliver all mail for an Account to a
specified recipient, ignoring the recipient in the mail headers. This works well
in the majority of cases where a mailbox is guaranteed to contain mail for a sole
mailbox recipient.
Accounts are configured to deduce the intended recipient from the mail headers
when a mailbox contains mail for several users, typically all users in a domain.
Used alone, this is not foolproof as there are circumstances when a single unique
recipient cannot be deduced from the mail headers alone. Used in conjunction with
an appropriately configured <alllocal> account, it is always possible to deduce
the intended recipient when the recipient is a James user.
|
fetchmail Configuration Parameters |
The fetchmail configuration parameters are part of the James configuration,
whose base file is config.xml . For clarity and flexibility, the
fetchmail configuration parameters are stored in the file
james-fetchmail.xml , which is referenced within
config.xml .
The configuration parameters are described below.
fetch |
The fetch tag defines a fetch task to be run
periodically. Fetch tasks run concurrently.
The tag has these attributes:
-
name
- A string uniquely identifying the fetch task.
The tag has these child tags (minimum cardinality, maximum cardinality):
-
accounts (1, 1)
-
blacklist (1, 1)
-
defaultdomain (0, 1)
-
fetchall (1, 1)
-
fetched (1, 1)
-
host (1, 1)
-
interval (1, 1)
-
javaMailFolderName (1, 1)
-
javaMailProperties (0, 1)
-
javaMailProviderName (1, 1)
-
maxmessagesize (0, 1)
-
recipientnotfound (1, 1)
-
recursesubfolders (1, 1)
-
remoteReceivedHeader (0, 1)
-
remoterecipient (1, 1)
-
undeliverable (1, 1)
-
userundefined (1, 1)
 |  |  |
 |
<fetch name="mydomain.com">
...
</fetch>
|  |
 |  |  |
|
blacklist |
The blacklist tag declares a list of recipient addresses
for whom mail will be rejected and what happens to the rejected mail.
The tag value is a tab, comma or space delimited list of recipient
addresses, eg: wibble@mydomain.com, flobble@mydomain.com .
The tag has these attributes:
-
reject
- A boolean. If "true", mail for recipients in the blacklist will
not be injected into the James input spool. If "false", mail for
recipients in the blacklist will be injected into the James input spool with the
Mail Attribute
org.apache.james.fetchmail.isBlacklistedRecipient
added to the mail.
-
leaveonserver
- A boolean. If "true", mail for recipients in the blacklist will be
left on the server. If "false", mail for recipients in the blacklist
will be marked for deletion.
-
markseen
- A boolean. If "true", mail for recipients in the blacklist will be
marked as seen on the server. If "false", mail for recipients in the blacklist
will not be marked as seen.
 |  |  |
 |
<blacklist
reject="true"
leaveonserver="true"
markseen="true">
wibble@mydomain.com, flobble@mydomain.com
</blacklist>
|  |
 |  |  |
|
javaMailProperties |
The javaMailProperties tag declares the properties to be
applied to the JavaMail Session used by the fetch task. These override the
properties answered by System.getProperties() . Many JavaMail
properties are specific to the JavaMail Provider selected by the
javaMailProviderName tag.
Relying on the default values selected by the Provider can be
inappropriate. For instance, the default connection and I/O timeout
values of infinite for the default IMAP and POP3 Providers is rarely what is
required. Consult the documentation of the Provider for details and options.
Documentation for the default Provider for IMAP is located
here.
Documentation for the default Provider for POP3 is located
here.
Details of how to change a Provider are located
here.
The tag has these child tags (minimum cardinality, maximum cardinality):
 |  |  |
 |
<javaMailProperties>
...
</javaMailProperties>
|  |
 |  |  |
|
remoteReceivedHeader |
The remoteReceivedHeader tag declares the zero based
index of the RFC2822 compliant RECEIVED header used to determine the address and
host name of the remote MTA that sent a fetched message and what happens to
messages when the specified header is invalid.
Typically, the first (index = 0) RECEIVED header is for the local MTA that
delivered the message to the message store and the second (index = 1) RECEIVED
header is for the remote MTA that delivered the message to the local MTA. When
this configuration applies, the remoteReceivedHeaderIndex should
be set to 1.
To verify the correct setting, examine the RECEIVED headers for messages
delivered to the configured message store and locate the first one containing a
remote domain in the'from' field. Remembering that zero based indexing is used,
if this the second header, use an index of 1, if this is the third header, use an
index of 2, and so forth.
Matchers such as InSpammerBlacklist use the remote address and/or remote host
name to identify illegitimate remote MTAs. If you do not use such matchers, the
remoteReceivedHeaderIndex tag may be omitted or the default
index value of -1 can be specified. This causes the remote address to be set to
127.0.0.1 and the remote host name to be set to
localhost . Matchers almost always considered these values to be
legitimate.
The tag has these attributes:
-
index
- An integer whose meaning is described above.
-
reject
- A boolean. If "true", mail whose specified recieved header is invalid
will not be injected into the James input spool. If "false", mail whose
specified recieved header is invalid will be injected into the James input spool with
the Mail Attribute
org.apache.james.fetchmail.isInvalidReceivedHeader
added to the mail, the remote address set to 127.0.0.1 and the remote
host name set to localhost .
-
leaveonserver
- A boolean. If "true", mail whose specified recieved header is invalid
will be left on the server. If "false", mail whose specified recieved header
is invalid will be marked for deletion.
-
markseen
- A boolean. If "true", mail whose specified recieved header is invalid
will be marked as seen on the server. If "false", mail whose specified
recieved header is invalid will not be marked as seen.
 |  |  |
 |
<remoteReceivedHeader
index="1"
reject="true"
leaveonserver="true"
markseen="true"/>
|  |
 |  |  |
An example configuration using James mailet processing to notify the postmaster
of fetched messages that contain an invalid Received header can be found in the file
$PHOENIX_HOME/apps/james/conf/samples/fetchmail/remoteReceivedHeader.xml .
|
|
fetchmail Examples |
Full sources to the examples discussed below can be found in the directory
$PHOENIX_HOME/apps/james/conf/samples/fetchmail .
One Account, Many Users - Dynamic |
The
One Account, One User - Dynamic
example guarantees delivery of mail for all local users, but leaves other mail
on the external server unprocessed. The
One Account, Many Users example
processes all mail on the external server, but cannot guarantee delivery to the
intended recipient. By combining the two, it is possible to guarantee the
delivery of mail for all local users and process all mail.
In the snippet below, the alllocal tag declares dynamic
accounts for all local users and the account tag configures an
account to fetch all mail.
The recipientnotfound tag rejects mail for which a recipient
cannot be determined. By the time this processing is activated, the dynamic
accounts will have processed mail for all local users, so the mail can
only be mail for non-local users or newly arrived mail for local users. It is
not possible to know which, but we want to leave mail for local users to be
dealt with by the dynamic accounts. The next time the dynamic accounts run any
newly arrived mail for local users will be processed. The remainder will be for
non-local users and can now be safely dealt with.
The <recipientnotfound defer="true" attribute
enables deferal of the processing of messages for which the recipient cannot be
determined to the next iteration of the fetch task, and is used here. The
relevant tags are:
 |  |  |
 |
<accounts>
<alllocal
userprefix=""
usersuffix="@external.domain.com"
password="mypassword"
recipientprefix=""
recipientsuffix="@localhost"
ignorercpt-header="true"/>
<account
user="global@external.domain.com"
password="password"
recipient="fetchmail@localhost"
ignorercpt-header="false"/>
</accounts>
<recipientnotfound
defer="true"
reject="true"
leaveonserver="true"
markseen="true"/>
|  |
 |  |  |
|
|
fetchmail Caveats |
These are some things to be aware of when using fetchmail:
- As noted in the
One Account, One User - Dynamic
example, all virtual accounts and the global account must share the same
password. A future version might associate each James user to a set of account
credentials.
- When using dynamic accounts, an account is generated and an attempt made to
fetch mail for all James users defined to James even if there is no such mailbox
on the server. This is inefficient but not fatal. The solution is the same as
described above.
- When using dynamic accounts, as described in the
One Account, Many Users - Dynamic
example, the user name used to fetch the mail for all accounts must not be
defined as a James user. If it is, a dynamic account will be generated for it
and fetch all the mail before the account declared to process mail for all users
has an opportunity to run!
- The now deprecated fetchPOP interacted with the
FetchedFrom
matcher to detect mail injected by fetchPOP. This will not work with fetchmail.
Compared to fetchPOP, there are far fewer occasions when mail injected by
fetchmail requires special processing. When it does, use the HasMailAttribute
matcher to match the attribute named
org.apache.james.fetchmail.taskName to detect all mail injected by
fetchmail. To detect mail injected by a specific fetch task, use one of the
HasMailAttributeWithValue matchers to match on the attribute name and the
attribute value. The attribute value is the name of the fetch task that
injected the mail.
- The POP3 protocol does not enforce support of any of the Flags associated
with messages other than DELETED. This means that
markseen="true" will most likely have no effect and
therefore, the fetchall tag will be inoperative. In this
situation, the only way to avoid repeatedly fetching the same mail is to delete
it from the server using leaveonserver="false"/> .
|
|