Benchmark-Perl-Formance-Cargo

 view release on metacpan or  search on metacpan

MANIFEST  view on Meta::CPAN

share/SpamAssassin/easy_ham_2/01399.ca6b00b7b341bbde9a9ea3dd6a7bf896
share/SpamAssassin/easy_ham_2/01400.f897f0931e461e7b2e964d28e927c35e
share/SpamAssassin/easy_ham_2/cmds
share/SpamAssassin/easy_ham_subset/00009.371eca25b0169ce5cb4f71d3e07b9e2d
share/SpamAssassin/easy_ham_subset/00064.cb4bd5482454f02b6c3d70343af090a8
share/SpamAssassin/easy_ham_subset/00087.03a92f5753c44cb83d28837121d82b06
share/SpamAssassin/easy_ham_subset/00182.8e6541320c6c08e0a899455a0a21f91c
share/SpamAssassin/easy_ham_subset/00271.b67b5b37ce874d5ccea3391922f14506
share/SpamAssassin/easy_ham_subset/00677.b957e34b4dd0d9263b56bf71b1168d8a
share/SpamAssassin/sa-learn.cfg
share/SpamAssassin/sa-learn.prefs
share/SpamAssassin/spam/0000.7b1b73cf36cf9dbc3d64e3f2ee2b91f1
share/SpamAssassin/spam/0001.bfc8d64d12b325ff385cca8d07b84288
share/SpamAssassin/spam/0002.24b47bb3ce90708ae29d0aec1da08610
share/SpamAssassin/spam/0003.4b3d943b8df71af248d12f8b2e7a224a
share/SpamAssassin/spam/0004.1874ab60c71f0b31b580f313a3f6e777
share/SpamAssassin/spam/0005.1f42bb885de0ef7fc5cd09d34dc2ba54
share/SpamAssassin/spam/0006.7a32642f8c22bbeb85d6c3b5f3890a2c
share/SpamAssassin/spam/0007.859c901719011d56f8b652ea071c1f8b
share/SpamAssassin/spam/0008.9562918b57e044abfbce260cc875acde
share/SpamAssassin/spam/0009.c05e264fbf18783099b53dbc9a9aacda

share/SpamAssassin/easy_ham/00010.145d22c053c1a0c410242e46c01635b3  view on Meta::CPAN

List-Subscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
    <mailto:spamassassin-talk-request@lists.sourceforge.net?subject=subscribe>
List-Id: Talk about SpamAssassin <spamassassin-talk.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
    <mailto:spamassassin-talk-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=spamassassin-talk>
X-Original-Date: Thu, 22 Aug 2002 10:16:36 -0400
Date: Thu, 22 Aug 2002 10:16:36 -0400

I have been trying to research via SA mirrors and search engines if a canned
script exists giving clients access to their user_prefs options via a
web-based CGI interface. Numerous ISPs provide this feature to clients, but
so far I can find nothing. Our configuration uses Amavis-Postfix and ClamAV
for virus filtering and Procmail with SpamAssassin for spam filtering. I
would prefer not to have to write a script myself, but will appreciate any
suggestions.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old

share/SpamAssassin/easy_ham/00392.1a94887ca585cbdaeec97524b9308b63  view on Meta::CPAN




>>>>> On Sat, 24 Aug 2002, "Harlan" == Harlan Feinstein wrote:

  Harlan> What's the trick again to have it default to showing
  Harlan> text/plain instead of html?

In ~/.exmh/exmh-defaults add:

*mime_alternative_prefs: text/plain text/enriched text/richtext text/html

Order possible alternatives from _your_ most preferred to least
preferred.

--Hal




_______________________________________________

share/SpamAssassin/easy_ham/01313.f8778c3339382c5514c9e201847f75ee  view on Meta::CPAN

Date: Thu, 22 Aug 2002 13:01:44 -0500 (CDT)

As the subject line indicates, I'm sure these are stupid questions, but
I'm having trouble getting SA working like I understand it should work,
and have about given up on trying to figure it out myself.

If a user has a line like:

whitelist_from *@yahoogroups.com

in his .spamassassin/user_prefs file, does that line not, in effect,
tell the program to take no action at all against any mail coming in from
yahoogroups.com, or is there still checking being done against it?  And if
the latter, what does he need to place in user_prefs to cause such mail
to be ignored?  I'm testing SA here with a few users who happen to be on
yahoogroups lists, before deploying it system-wide, and although the above
line has been added to their user_prefs files, much of their list mail is
still going to the spam folder due to all the usual things you would
expect to trigger SA.

Thanks in advance for any help.

--
Ken Scott,
admin@shellworld.net


share/SpamAssassin/easy_ham/01314.ba7b992d372c23964b8b4a1de885a095  view on Meta::CPAN



--lteA1dqeVaWQ9QQl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 22, 2002 at 01:01:44PM -0500, Ken Scott wrote:
> whitelist_from *@yahoogroups.com
>=20
> in his .spamassassin/user_prefs file, does that line not, in effect,
> tell the program to take no action at all against any mail coming in from
> yahoogroups.com, or is there still checking being done against it?  And if

It still gets checked, but a negative score is added in.  And it doesn't
mean "coming in from" it means "From: address is @yahoogroups.com".
There's a Yahoo Groups compensation rule in 2.40 though. :)

> the latter, what does he need to place in user_prefs to cause such mail
> to be ignored?  I'm testing SA here with a few users who happen to be on

ignored completely?  you can't do that, put in a procmail rule.

> yahoogroups lists, before deploying it system-wide, and although the above
> line has been added to their user_prefs files, much of their list mail is
> still going to the spam folder due to all the usual things you would
> expect to trigger SA.

You'd want to either add your own compensation rule or up (negatively)
the whitelist score.

--=20
Randomly Generated Tagline:
There are perfectly good answers to those questions, but they'll have
 to wait for another night.

share/SpamAssassin/easy_ham/01386.4421abca51be5e71c1651102468420e2  view on Meta::CPAN

X-Original-Date: Thu, 29 Aug 2002 13:33:53 +0100
Date: Thu, 29 Aug 2002 13:33:53 +0100

Urban Boquist wrote:
> Hi Matt, and thanks for your quick reply.
> 
> Matt> Don't run SA on mails this large.
> 
> That would be fine, if I only understood how I should do that. I can't
> find anything in the SA documention that mentions some kind of upper
> limit for the size of a message. What should I put in my user_prefs
> file?
> 
> I run SA from procmail btw, but I can't imagine that procmail would be
> able to check the size of a message before handing it over to SA?

That's exactly what it can do:

:0fw <250000
| spamassassin -P

share/SpamAssassin/easy_ham/01503.5e13994a5676296ed31b14e83367031c  view on Meta::CPAN

Received: from ns1.apexvoice.com ([64.52.111.15]
    helo=popeye.apexvoice.com) by usw-sf-list1.sourceforge.net with esmtp
    (Exim 3.31-VA-mm2 #1 (Debian)) id 17ty84-00085i-00 for
    <spamassassin-talk@lists.sourceforge.net>; Tue, 24 Sep 2002 15:26:04 -0700
Received: from sthomas (64-52-111-64.apexvoice.com [64.52.111.64]) by
    popeye.apexvoice.com (8.12.3/8.12.3) with SMTP id g8OMPrba011319;
    Tue, 24 Sep 2002 15:25:53 -0700
From: "Steve Thomas" <sthomas@apexvoice.com>
To: "Cheryl L. Southard" <cld@astro.caltech.edu>,
	<spamassassin-talk@lists.sourceforge.net>
Subject: RE: [SAtalk] user_prefs ignored
Message-Id: <PIEHJPLNKGMNAHJKHLFCCECJCEAA.sthomas@apexvoice.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <20020924212731.GA24786@deimos.caltech.edu>

share/SpamAssassin/easy_ham/01503.5e13994a5676296ed31b14e83367031c  view on Meta::CPAN

    <mailto:spamassassin-talk-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchives/forum.php?forum=spamassassin-talk>
X-Original-Date: Tue, 24 Sep 2002 15:25:54 -0700
Date: Tue, 24 Sep 2002 15:25:54 -0700

This is just an semi-educated guess - if I'm wrong, someone please correct
me!

Spamd setuid's to the user running spamc. Since you're calling spamc from a
global procmailrc file, it's being run as root (most likely). If called as
root, spamd won't open user_prefs files.

>>From the spamc man page:

       -u username
           This argument has been semi-obsoleted.  To have spamd use
           per-user-config files, run spamc as the user whose config
           files spamd should load.  If you're running spamc as some
           other user though (eg. root, mail, nobody, cyrus, etc.)
           then you can still use this flag.

share/SpamAssassin/easy_ham/01503.5e13994a5676296ed31b14e83367031c  view on Meta::CPAN


St-


| -----Original Message-----
| From: spamassassin-talk-admin@example.sourceforge.net
| [mailto:spamassassin-talk-admin@lists.sourceforge.net]On Behalf Of
| Cheryl L. Southard
| Sent: Tuesday, September 24, 2002 2:28 PM
| To: spamassassin-talk@example.sourceforge.net
| Subject: [SAtalk] user_prefs ignored
|
|
| Hi All,
|
| I am running SpamAssassin 2.41 with procmail as my local delivery agent
| with sendmail.  I use spamc/spamd so that it runs site-wide from
| /etc/procmailrc.
|
| spamd is run as root with the flags "-d -a -c", and spamc isn't run with
| any flags.
|
| When I was testing the program, I deployed spamc from my personal
| ~/.procmailrc file, my ~/.spamassassin/user_prefs file was read each time.
| I can see this because I have a non-default "required_hits" value which
| gets reported in every e-mail on the "X-Spam-Status" line.
|
| Now that I run spamc from the global /etc/procmailrc file, my
| ~/.spamassassin/user_prefs file is no longer being read or processed from
| e-mails from outside computers.  The "required_hits" value gets set back
| to the one in /etc/mail/spamassassin/local.cf.  However, if I send local
| e-mail, my user_prefs file is read and processed correctly.
|
| Does anyone know how to fix this problem?  if this is a spamassassin or
| procmail bug?
|
| Thanks,
|
| Cheryl
|
| --
| Cheryl Southard

share/SpamAssassin/easy_ham/01512.9a1a7937d7a0691e79d806bdfbda28a3  view on Meta::CPAN

retrieving revision 1.115.2.12
diff -b -w -u -d -r1.115.2.11 -r1.115.2.12
--- SpamAssassin.pm	24 Sep 2002 18:51:37 -0000	1.115.2.11
+++ SpamAssassin.pm	2 Oct 2002 13:19:28 -0000	1.115.2.12
@@ -696,7 +696,13 @@
 }
 
 ###########################################################################
-# non-public methods.
+
+=item $f->init ($use_user_prefs)
+
+Read and parse the current configuration. C<$use_user_prefs> can
+be C<0> (do not read user preferences) or C<1> (do).
+
+=cut
 
 sub init {
   my ($self, $use_user_pref) = @_;
@@ -767,6 +773,9 @@
 
   # TODO -- open DNS cache etc. if necessary
 }

share/SpamAssassin/easy_ham/01591.7504f83163aa1c627354192d452a43e3  view on Meta::CPAN

> In my experience, there are spam messages that sneak past Spam Assassin,
> that Razor will pick up. Those are the ones that I'm calling "marginal".
> Basically, I'm hoping that "the collective" of Razor users make a better
> judge of spam than any single program like SA can, and therefore I can
> benefit from their judgement and get more extensive spam filtering. I've
> seen examples of this already, where SA doesn't score the spam high enough
> to bounce it, but Razor does.

I think perhaps you missed the fact that SA scores are adjustable.  If
you want SA to tag all messages listed in Razor then you can put this
in your ~/.spamassassin/user_prefs file.

  score RAZOR_CHECK 10

The default score is 3 and the default threshold needed is 5.
Therefore if you wish to have any razor listed messages tagged by SA
then setting a score for any razor listed messages to anything above 5
would be sufficient.

If you are already using SA then the above would be more efficient.
Otherwise you are running all of the mail through razor twice, once

share/SpamAssassin/easy_ham/01932.f8c1d938ebba259e2926cf4400891c86  view on Meta::CPAN

default on Win32 (overwhelmingly) is to bring up a context menu on a mouse up. 
If you don't like it, complain about Win32, but don't cite this as a Mozilla 
usability problem when we're following the conventions of the operating system. 
(We simply listen for the WM_CONTEXTMENU message. That message fires when Win32 
wants to fire it.)

- Validation - Err, no. Not a usability problem. To the average bear, this is 
completely irrelevant.

- Preferences - IMO this should be much higher on the list. Preferences are a 
tangled pathetic mess. Again, separating prefs for individual apps into unique 
dialogs would simplify things a great deal, but we should also remove nearly 
half the preferences that exist from the GUI. Mozilla is ridiculously 
overconfigurable.



[1] http://www.blakeross.com/archives/2002_08_18_index.html#80418641
[2] http://mpt.phrasewise.com


share/SpamAssassin/easy_ham_2/00637.b8b627542a5af9e99890aff7a73c7754  view on Meta::CPAN

List-Subscribe: <https://example.sourceforge.net/lists/listinfo/razor-users>,
    <mailto:razor-users-request@lists.sourceforge.net?subject=subscribe>
List-Id: <razor-users.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/razor-users>,
    <mailto:razor-users-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=razor-users>
X-Original-Date: Tue, 13 Aug 2002 13:06:16 -0500
Date: Tue, 13 Aug 2002 13:06:16 -0500

At 12:20 PM -0500 8/13/02, Mike Burger wrote:
>Make sure you have this in your .spamassassin/user_prefs:

This might be a problem.  I'll have to look into it further.  I just 
got SA working yesterday.  It's being called from MIMEDefang.  I'm 
not sure if it will look for user preferences when run like that. 
One would hope it would be I can't say for certain.  I'll look in to 
it.

># By default, the subject lines of suspected spam will be tagged.
># This can be disabled here.
>#

share/SpamAssassin/easy_ham_2/00641.a4e760e8ab2d1fb7302559751ab28d27  view on Meta::CPAN


> To actually answer Justin's question, (one can assume that he has
> rewrite_subject and report_header turned on because he wants them..and
> that he would like to be able to strip the added bits off before he sends
> them to razor) something as simple as the following would probably work
> just fine.  Just pipe your message through this, then on into
> razor-report:

I wouldn't make that assumption.  I'd assume that rewrite_subject was on, 
and report_header was off, because that's the default configuration, and 
not everyone knows to go look in the user_prefs file to make those 
changes.



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Razor-users mailing list

share/SpamAssassin/easy_ham_2/01277.d7a43a4dd78dc466c8808f370ae2b2bb  view on Meta::CPAN


     - run the Update Agent on each affected server.


---------------------------------
Changing Notification Preferences
---------------------------------
To enable/disable your Errata Alert preferences globally please log in to RHN
and navigate from "Your RHN" / "Your Account" to the "Preferences" tab.

        URL: https://rhn.spamassassin.taint.org/network/my_account/my_prefs.pxt

You can also enable/disable notification on a per system basis by selecting an
individual system from the "Systems List". From the individual system view
click the "Details" tab.


---------------------
Affected Systems List
---------------------
This Errata Advisory may apply to the systems listed below. If you know that

share/SpamAssassin/easy_ham_2/01281.c6dc8af12840f7e67f50ed2346e204de  view on Meta::CPAN

spamassassin.sf.net is the US mirror, also accessible through 
us.spamassassin.org.

> They appear to be the same page, but until recently I could get to the
> www. spamassassin.org one, but it hasn't been responsive the last couple
> days.

For me it worked until yesterday or the day before.

> But then, I also haven't been able to get anyone to answer my questions
> about user_prefs files (not the one from earlier today, but from a couple
> days ago).

About this question: No, that's currently not possible. But I was thinking 
about implementing a feature like this; it might be in the next release.

Malte

-- 
-- Coding is art.
-- 

share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b  view on Meta::CPAN

       initialization code so that it can be manually set to true, even
       if neither host is running Windows. (This may be useful, e.g.,
       when using Unison running on a Unix system with a FAT volume
       mounted.)
     * Small improvements and bug fixes:
          + Errors in preference files now generate fatal errors rather
            than warnings at startup time. (I.e., you can't go on from
            them.) Also, we fixed a bug that was preventing these
            warnings from appearing in the text UI, so some users who
            have been running (unsuspectingly) with garbage in their
            prefs files may now get error reports.
          + Error reporting for preference files now provides file name
            and line number.
          + More intelligible message in the case of identical change to
            the same files: ``Nothing to do: replicas have been changed
            only in identical ways since last sync.''
          + Files with prefix '.#' excluded when scanning for preference
            files.
          + Rsync instructions are send directly instead of first
            marshaled.
          + Won't try forever to get the fingerprint of a continuously

share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b  view on Meta::CPAN

            Windows).
          + Added the option to compile unison on the Windows platform
            with Cygwin GNU C compiler. This option only supports
            building dynamically linked unison executables.
       
   Changes since 2.7.4:
     * Fixed a silly (but debilitating) bug in the client startup
       sequence.
       
   Changes since 2.7.1:
     * Added addprefsto preference, which (when set) controls which
       preference file new preferences (e.g. new ignore patterns) are
       added to.
     * Bug fix: read the initial connection header one byte at a time, so
       that we don't block if the header is shorter than expected. (This
       bug did not affect normal operation --- it just made it hard to
       tell when you were trying to use Unison incorrectly with an old
       version of the server, since it would hang instead of giving an
       error message.)
       
   Changes since 2.6.59:

share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b  view on Meta::CPAN

       precompiled binaries on Windows, please upgrade.
     * Added a -debug command line flag, which controls debugging of
       various modules. Say -debug XXX to enable debug tracing for module
       XXX, or -debug all to turn on absolutely everything.
     * Fixed a small bug where the text UI on NT was raising a 'no such
       signal' exception.
       
   Changes since 1.111:
     * INCOMPATIBLE CHANGE: The names and formats of the preference files
       in the .unison directory have changed. In particular:
          + the file ``prefs'' should be renamed to default.prf
          + the contents of the file ``ignore'' should be merged into
            default.prf. Each line of the form REGEXP in ignore should
            become a line of the form ignore = REGEXP in default.prf.
     * Unison now handles permission bits and symbolic links. See the
       manual for details.
     * You can now have different preference files in your .unison
       directory. If you start unison like this

             unison profilename
       (i.e. with just one ``anonymous'' command-line argument), then the

share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b  view on Meta::CPAN

       initialization code so that it can be manually set to true, even
       if neither host is running Windows. (This may be useful, e.g.,
       when using Unison running on a Unix system with a FAT volume
       mounted.)
     * Small improvements and bug fixes:
          + Errors in preference files now generate fatal errors rather
            than warnings at startup time. (I.e., you can't go on from
            them.) Also, we fixed a bug that was preventing these
            warnings from appearing in the text UI, so some users who
            have been running (unsuspectingly) with garbage in their
            prefs files may now get error reports.
          + Error reporting for preference files now provides file name
            and line number.
          + More intelligible message in the case of identical change to
            the same files: ``Nothing to do: replicas have been changed
            only in identical ways since last sync.''
          + Files with prefix '.#' excluded when scanning for preference
            files.
          + Rsync instructions are send directly instead of first
            marshaled.
          + Won't try forever to get the fingerprint of a continuously

share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b  view on Meta::CPAN

            Windows).
          + Added the option to compile unison on the Windows platform
            with Cygwin GNU C compiler. This option only supports
            building dynamically linked unison executables.
       
   Changes since 2.7.4:
     * Fixed a silly (but debilitating) bug in the client startup
       sequence.
       
   Changes since 2.7.1:
     * Added addprefsto preference, which (when set) controls which
       preference file new preferences (e.g. new ignore patterns) are
       added to.
     * Bug fix: read the initial connection header one byte at a time, so
       that we don't block if the header is shorter than expected. (This
       bug did not affect normal operation --- it just made it hard to
       tell when you were trying to use Unison incorrectly with an old
       version of the server, since it would hang instead of giving an
       error message.)
       
   Changes since 2.6.59:

share/SpamAssassin/easy_ham_2/01380.e3fad5af747d3a110008f94a046bf31b  view on Meta::CPAN

       precompiled binaries on Windows, please upgrade.
     * Added a -debug command line flag, which controls debugging of
       various modules. Say -debug XXX to enable debug tracing for module
       XXX, or -debug all to turn on absolutely everything.
     * Fixed a small bug where the text UI on NT was raising a 'no such
       signal' exception.
       
   Changes since 1.111:
     * INCOMPATIBLE CHANGE: The names and formats of the preference files
       in the .unison directory have changed. In particular:
          + the file ``prefs'' should be renamed to default.prf
          + the contents of the file ``ignore'' should be merged into
            default.prf. Each line of the form REGEXP in ignore should
            become a line of the form ignore = REGEXP in default.prf.
     * Unison now handles permission bits and symbolic links. See the
       manual for details.
     * You can now have different preference files in your .unison
       directory. If you start unison like this

             unison profilename
       (i.e. with just one ``anonymous'' command-line argument), then the

share/SpamAssassin/easy_ham_2/01391.00e6f3a6dc816f22335f1b0fd6098eda  view on Meta::CPAN

List-Post: <mailto:spamassassin-talk@example.sourceforge.net>
List-Subscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
    <mailto:spamassassin-talk-request@lists.sourceforge.net?subject=subscribe>
List-Id: Talk about SpamAssassin <spamassassin-talk.example.sourceforge.net>
List-Unsubscribe: <https://example.sourceforge.net/lists/listinfo/spamassassin-talk>,
    <mailto:spamassassin-talk-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=spamassassin-talk>
X-Original-Date: Wed, 24 Jul 2002 09:15:53 -0700
Date: Wed, 24 Jul 2002 09:15:53 -0700

Amis-v or there is another prefs file that SA is using. I had a heck of a time
figuring out where to find my site wide file because of my configuration.

If your using spamd and you want your users to have some control using
user_prefs then check their ~/spamassassin file.
If your using spamd and you have a site wide only policy then make sure that
spamd is started with the -x option.
If you used the -x option then the only place that it should get the rules from
would be from the local.cf in the /etc/mail/spamassassin directory. Assuming a
default install.

Theo Van Dinter wrote:
> 
> On Wed, Jul 24, 2002 at 10:18:28AM -0500, Stewart, John wrote:
> > X-Virus-Scanned: by amavisd-new amavisd-new-20020630

share/SpamAssassin/spam_2/00556.098b57f5108ba34d21825f176e492786  view on Meta::CPAN

<p align="center"><font face="Verdana, Arial, Helvetica, sans-
serif" size="2" color="#132E65">More Info</font><br>
<br>
</a>Join our mailing list to be first to know about fresh 
quality
programs and utilities. Our list includes selected, tested and
quality freeware, shareware and other software only.<br>
<br>
<!--START CODE-->
<center><A target="_blank" 
HREF="http://lb.bcentral.com/ex/manage/subscriberprefs.aspx?
customerid=21671" ><IMG 
SRC="http://lb.bcentral.com/images/alist/signup.gif" BORDER="0" 
WIDTH="100" HEIGHT="35"></A>
<!--END CODE --></center><BR><BR>
</p><br><br>
</div>
</td>
</tr>
<tr align="right"> 
<td valign="top"> </td>



( run in 1.532 second using v1.01-cache-2.11-cpan-0bb4e1dffa6 )