Ok. I've had no problems with the default (file based solution) so far. ( and
really more concerned with time to get it running than a bullet-proof solution: this
is an "academic/personal" project for me. ) I solved my problem by putting the
following section in the config.xml file:
><!-- The 'catchall' process attempts to catch all emails into a
>central account -->
><!-- central account is hardcoded ("ToRepository" accesses files
>directly) -->
><processor name="catchall">
><!-- Logs any messages to the repository specified -->
><mailet match="All" class="ToRepository">
><repositoryPath>
>file://var/mail/inboxes/jnorment/</repositoryPath>
><passThrough>�true </passThrough>
></mailet>
></processor>
>
>
><!-- The error processor is required. �James may internally set
>emails to the -->
(a slimmed down version of the error processor that follows it)
and making this change:
><!-- If the host is handled by this server and it did not get -->
><!-- locally delivered, this is an invalid recipient -->
><mailet match="HostIsLocal" class="ToProcessor">
><processor>catchall</processor>
><!-- <processor>error</processor>�-->
></mailet>
It seems to do the trick...
On Fri, 20 Dec 2002 07:47:20 -0800, Kenny Smith wrote:
>Hi J,
>
>Yeah, it's a database solution (and works really well in my
>experience).
>
>Kenny
>
>J. Norment wrote:
>
>>Do you need a database to use that?
>>
>>
>>On Fri, 20 Dec 2002 04:11:43 -0500, Noel J. Bergman wrote:
>>
>>>In case no one mentioned it, the JDBCVirtualUserTable mailet
>>>provides that
>>>feature.
>
>
>
>--
>To unsubscribe, e-mail: � <mailto:james-user-
>[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:james-user-
>[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
