Mailing List Archive: SpamAssassin: users

rbl checks not running

Index | Next | Previous | View Threaded

hedges at scriptdolphin

Nov 20, 2009, 12:07 PM

Post #1 of 15 (1226 views)
Permalink

rbl checks not running

Hi. I've set up my own rbldnsd server. It's responding to
queries correctly, for example, I am trying to block the
server that this message comes from, 64.22.103.163.

hedges [at] d10:~$ nslookup 163.103.22.64.spammers.rbl.dmz
Server: 192.168.6.21
Address: 192.168.6.21#53

Non-authoritative answer:
Name: 163.103.22.64.spammers.rbl.dmz
Address: 127.0.0.2

It looks it up backwards, right? I verified with a script that
that Net::DNS gives the same answer.

header RCVD_IN_COV_SPAMMERS eval:check_rbl('cov_spammers', 'spammers.rbl.dmz.')
describe RCVD_IN_COV_SPAMMERS Spammer blocked by CompanyV RBL
tflags RCVD_IN_COV_SPAMMERS net
priority RCVD_IN_COV_SPAMMERS -100

score RCVD_IN_COV_SPAMMERS 5.0

I also tried turning off all settings for trusted_networks
and internal_networks, tried with the -lastexternal and
-untrusted suffixes to the set part of the definition, etc.

I'm running spamd with full debugging turned on with
--debug and I've attached an example log from startup to
scan of the message. When the message comes in, I do see
this in the debug log:

Fri Nov 20 11:49:32 2009 [26661] dbg: dns: checking RBL spammers.rbl.dmz., set cov_spammers.

I added a header using the _RBL_ replacement tag to get more
info:

X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on d100.companyv.net
X-Spam-Level:
X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50 autolearn=no
version=3.2.5
X-Spam-RBL-Report: <dns:scriptdolphin.com?type=MX> [10 mail.scriptdolphin.com.]
<dns:scriptdolphin.com> [64.22.103.163]

What do I do to get the test to run?

Incidentally, in the attached log, what's up with the pyzor
errors, could those be interfering or causing further header
tests to be skipped?

Thanks,
--mark--

Attachments:

sa_debug.log (96.8 KB)

hedges at scriptdolphin

Nov 20, 2009, 12:29 PM

Post #2 of 15 (1192 views)
Permalink

Re: rbl checks not running [In reply to]

On Fri, 20 Nov 2009, Mark Hedges wrote:
>
> Hi. I've set up my own rbldnsd server. It's responding
> to queries correctly, for example, I am trying to block
> the server that this message comes from, 64.22.103.163.
>

I forgot to say, I'm using 3.2.5 on CentOS 5.3 which runs
Perl 5.8.8.

I also tried clear_trusted_networks and
clear_internal_networks but the test still does not run.

It doesn't matter about pyzor, I tried turning off pyzor and
dcc and the RBL test still doesn't fire.

Help? Thanks. --mark--

me at junc

Nov 20, 2009, 12:46 PM

Post #3 of 15 (1196 views)
Permalink

Re: rbl checks not running [In reply to]

On fre 20 nov 2009 21:07:00 CET, Mark Hedges wrote

> Hi. I've set up my own rbldnsd server. It's responding to
> queries correctly, for example, I am trying to block the
> server that this message comes from, 64.22.103.163.

spamassassin 2>&1 -D metadata -t msg | less

the ip above is not in the mail

--
xpoint

richard at buzzhost

Nov 20, 2009, 12:52 PM

Post #4 of 15 (1202 views)
Permalink

Re: rbl checks not running [In reply to]

On Fri, 2009-11-20 at 12:29 -0800, Mark Hedges wrote:
> On Fri, 20 Nov 2009, Mark Hedges wrote:
> >
> > Hi. I've set up my own rbldnsd server. It's responding
> > to queries correctly, for example, I am trying to block
> > the server that this message comes from, 64.22.103.163.
> >
>
> I forgot to say, I'm using 3.2.5 on CentOS 5.3 which runs
> Perl 5.8.8.
>
> I also tried clear_trusted_networks and
> clear_internal_networks but the test still does not run.
>
> It doesn't matter about pyzor, I tried turning off pyzor and
> dcc and the RBL test still doesn't fire.
>
> Help? Thanks. --mark--
>
>
Hi Mark, I'm no expert, but I have my own bind DNSBL's running with SA.

Checks that may help you:

1. In local.cf, confirm skip_rbl_checks is set to 0

2. Add a rule for your custom dnsbl (either in local.cf or your own
custom rules.cf file);

header CUSTOM_BLOCKLIST eval:check_rbl('rbl.dmz',
'spammers.rbl.dmz.')
describe CUSTOM_BLOCKLIST Relay in Local DNS Blocklist
tflags CUSTOM_BLOCKLIST net
score CUSTOM_BLOCKLIST 2.5

3. Test the rule: spamassassin --debug --lint
(grep or look for DNS tests) and if clear reload/restart SA

4. Check your system is set to use your DNS server (or that the DNS
server it used by default resolve queries for spammers.rbl.dmz.)
Depending on how you have system logging set up, I would tail the syslog
or dns log whilst sending test messages in, or feed SA with a test
message to check: spamassassin -D
< /usr/share/spamassassin/doc/spamassassin-3.0.3/sample-spam.txt

I hope this is of some use to you, but I'm sure one of the resident
experts will spot your issue in moments and post. I apologise if my
answer is of little use.

hedges at scriptdolphin

Nov 20, 2009, 2:56 PM

Post #5 of 15 (1188 views)
Permalink

Re: rbl checks not running [In reply to]

On Fri, 20 Nov 2009, Benny Pedersen wrote:

> On fre 20 nov 2009 21:07:00 CET, Mark Hedges wrote
>
> > Hi. I've set up my own rbldnsd server. It's responding to
> > queries correctly, for example, I am trying to block the
> > server that this message comes from, 64.22.103.163.
>
> spamassassin 2>&1 -D metadata -t msg | less
>
> the ip above is not in the mail

Hi Benny, thanks for the suggestion. Actually, the IP is in
the mail, for example check the headers of this,
64.22.103.163 is mail.scriptdolphin.com, the server that I'm
sending from.

Trying your suggestion, I found something rather odd. The
test is not triggered (or does not run) when received by
sendmail and scanned via ~/procmailrc. But the test DOES
run, and scores correctly, when I run through the command
line as you suggested. Details follow. Actually it doesn't
matter if I remove the X-* headers, the original message
produces the same results. Thanks for your help. --mark--

hedges [at] d10:/tmp$ cat testmsg_as_scanned
>From hedges [at] scriptdolphin Fri Nov 20 14:49:01 2009
Return-Path: <hedges [at] scriptdolphin>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on d100.companyv.net
X-Spam-Level:
X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50 autolearn=no
version=3.2.5
X-Spam-RBL-Report: <dns:scriptdolphin.com?type=MX> [10 mail.scriptdolphin.com.]
<dns:scriptdolphin.com> [64.22.103.163]
Received: from li16-163.members.linode.com (li16-163.members.linode.com [64.22.103.163])
by d100.companyv.net (8.13.8/8.13.8) with ESMTP id nAKMmwMB011232
(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO)
for <hedges [at] digicine>; Fri, 20 Nov 2009 14:49:01 -0800
Received: from localhost ([127.0.0.1])
by li16-163.members.linode.com with esmtp (Exim 4.69)
(envelope-from <hedges [at] scriptdolphin>)
id 1NBcGz-0002I5-LW
for hedges [at] digicine; Fri, 20 Nov 2009 14:48:13 -0800
Date: Fri, 20 Nov 2009 14:48:13 -0800 (PST)
From: Mark Hedges <hedges [at] scriptdolphin>
To: hedges [at] digicine
Subject: testing 1 2 3 testing
Message-ID: <alpine.DEB.1.10.0911201446480.8666 [at] li16-163>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
X-Ray: Vision
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: hedges [at] digicine
X-SA-Exim-Mail-From: hedges [at] scriptdolphin
X-SA-Exim-Scanned: No (on li16-163.members.linode.com); SAEximRunCond expanded to false
X-Scanned-By: MIMEDefang 2.67 on 207.151.82.60

test 1 2 3 test

hedges [at] d10:/tmp$ cat testmsg_as_scanned | grep -v '^X-' > testmsg_minus_xheaders
hedges [at] d10:/tmp$ spamassassin --no-create-prefs --siteconfigpath=/etc/mail/spamassassin/digicine/ -D metadata -t testmsg_minus_xheaders 2>&1
[11390] dbg: metadata: X-Spam-Relays-Trusted:
[11390] dbg: metadata: X-Spam-Relays-Untrusted: [. ip=64.22.103.163 rdns=li16-163.members.linode.com helo=li16-163.members.linode.com by=d100.companyv.net ident= envfrom= intl=0 id=nAKMmwMB011232 auth= msa=0 ] [. ip=127.0.0.1 rdns=localhost helo=localhost by=li16-163.members.linode.com ident= envfrom=hedges [at] scriptdolphin intl=0 id=1NBcGz-0002I5-LW auth= msa=0 ]
[11390] dbg: metadata: X-Spam-Relays-Internal:
[11390] dbg: metadata: X-Spam-Relays-External: [. ip=64.22.103.163 rdns=li16-163.members.linode.com helo=li16-163.members.linode.com by=d100.companyv.net ident= envfrom= intl=0 id=nAKMmwMB011232 auth= msa=0 ] [. ip=127.0.0.1 rdns=localhost helo=localhost by=li16-163.members.linode.com ident= envfrom=hedges [at] scriptdolphin intl=0 id=1NBcGz-0002I5-LW auth= msa=0 ]
[11390] dbg: metadata: X-Relay-Countries: US **
>From hedges [at] scriptdolphin Fri Nov 20 14:49:01 2009
Return-Path: <hedges [at] scriptdolphin>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on d100.companyv.net
X-Spam-Level: SSSSS
X-Spam-Status: Yes, score=5.5 required=5.0 tests=BAYES_50,RCVD_IN_COV_SPAMMERS
autolearn=no version=3.2.5
X-Spam-RBL-Report: <dns:163.103.22.64.spammers.rbl.dmz> [127.0.0.2]
X-Spam-Report:
* 5.0 RCVD_IN_COV_SPAMMERS RBL: Spammer blocked by CompanyV RBL
* [64.22.103.163 listed in spammers.rbl.dmz]
* 0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
* [score: 0.4847]
version=3.2.5
<dns:scriptdolphin.com> [64.22.103.163]
Received: from li16-163.members.linode.com (li16-163.members.linode.com [64.22.103.163])
by d100.companyv.net (8.13.8/8.13.8) with ESMTP id nAKMmwMB011232
(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO)
for <hedges [at] digicine>; Fri, 20 Nov 2009 14:49:01 -0800
Received: from localhost ([127.0.0.1])
by li16-163.members.linode.com with esmtp (Exim 4.69)
(envelope-from <hedges [at] scriptdolphin>)
id 1NBcGz-0002I5-LW
for hedges [at] digicine; Fri, 20 Nov 2009 14:48:13 -0800
Date: Fri, 20 Nov 2009 14:48:13 -0800 (PST)
From: Mark Hedges <hedges [at] scriptdolphin>
To: hedges [at] digicine
Subject: *****SPAM***** testing 1 2 3 testing
Message-ID: <alpine.DEB.1.10.0911201446480.8666 [at] li16-163>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Prev-Subject: testing 1 2 3 testing

test 1 2 3 test

Spam detection software, running on the system "d100.companyv.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
'postmaster [at] companyv' for details.

Content preview: test 1 2 3 test [...]

Content analysis details: (5.5 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
5.0 RCVD_IN_COV_SPAMMERS RBL: Spammer blocked by CompanyV RBL
[64.22.103.163 listed in spammers.rbl.dmz]
0.5 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.4847]

martin at gregorie

Nov 20, 2009, 3:11 PM

Post #6 of 15 (1186 views)
Permalink

Re: rbl checks not running [In reply to]

On Fri, 2009-11-20 at 14:56 -0800, Mark Hedges wrote:
>
> Trying your suggestion, I found something rather odd. The
> test is not triggered (or does not run) when received by
> sendmail and scanned via ~/procmailrc. But the test DOES
> run, and scores correctly, when I run through the command
> line as you suggested. Details follow. Actually it doesn't
> matter if I remove the X-* headers, the original message
> produces the same results. Thanks for your help. --mark--
>
Where did you put the new test? To be globally accessible, i.e. used by
SA regardless of which user runs it, the test needs to be in the default
location, usually /etc/mail/spamassassin, in a *.cf file.

Martin

hedges at scriptdolphin

Nov 20, 2009, 3:20 PM

Post #7 of 15 (1191 views)
Permalink

Re: rbl checks not running [In reply to]

On Fri, 20 Nov 2009, Martin Gregorie wrote:

> On Fri, 2009-11-20 at 14:56 -0800, Mark Hedges wrote:
> >
> > Trying your suggestion, I found something rather odd. The
> > test is not triggered (or does not run) when received by
> > sendmail and scanned via ~/procmailrc. But the test DOES
> > run, and scores correctly, when I run through the command
> > line as you suggested. Details follow. Actually it doesn't
> > matter if I remove the X-* headers, the original message
> > produces the same results. Thanks for your help. --mark--
> >
> Where did you put the new test? To be globally accessible, i.e. used by
> SA regardless of which user runs it, the test needs to be in the default
> location, usually /etc/mail/spamassassin, in a *.cf file.

As I've already confirmed by including the debugging log
attachment in my first message, the test rule is loaded, it
expects to be looking at spammers.rbl.dmz. (I have a
somewhat complex setup due to multiple scanners with
different preferences and mostly shared options.) Trust me,
this is a weird problem or I wouldn't be asking. From my
example, the local.cf in the siteconfigpath includes
/etc/mail/spamassassin/local.cf, which then includes the cf
file where the test is defined, which I already included in
a previous message. And, it doesn't explain why the rule is
correctly loaded, but not run when scanned, and is run when
I put the message through the command line.

Mark

rickm at ummm-beer

Nov 20, 2009, 3:48 PM

Post #8 of 15 (1188 views)
Permalink

Re: rbl checks not running [In reply to]

Mark Hedges wrote:
>
> As I've already confirmed by including the debugging log
> attachment in my first message, the test rule is loaded, it
> expects to be looking at spammers.rbl.dmz. (I have a
> somewhat complex setup due to multiple scanners with
> different preferences and mostly shared options.) Trust me,
> this is a weird problem or I wouldn't be asking. From my
> example, the local.cf in the siteconfigpath includes
> /etc/mail/spamassassin/local.cf, which then includes the cf
> file where the test is defined, which I already included in
> a previous message. And, it doesn't explain why the rule is
> correctly loaded, but not run when scanned, and is run when
> I put the message through the command line.
>

Hi,

Running spamassassin -D from the command line will load all the .cf
files. Perhaps spamd needs to be restarted for it to see any changes
you've made ?

Regards,

Rick

martin at gregorie

Nov 20, 2009, 4:00 PM

Post #9 of 15 (1193 views)
Permalink

Re: rbl checks not running [In reply to]

On Fri, 2009-11-20 at 15:20 -0800, Mark Hedges wrote:
> As I've already confirmed by including the debugging log
> attachment in my first message, the test rule is loaded,
>
When run under sendmail and procmail as well?

I might have missed something, but saw that you confirmed the test was
loaded and called in your test rig but not that this was necessarily
true in the other two cases.

> And, it doesn't explain why the rule is
> correctly loaded, but not run when scanned, and is run when
> I put the message through the command line.
>
That's often a mark of location dependency, hence my comment. Is it
possible that the sendmail wrapper and/or the procmail environment are
overriding the siteconfig path? Does your site use spamc/spamd in some
places and spamassassin in others?

Probably teaching you to such eggs, I know...

Martin

hedges at scriptdolphin

Nov 20, 2009, 5:15 PM

Post #10 of 15 (1172 views)
Permalink

Re: rbl checks not running [In reply to]

On Sat, 21 Nov 2009, Martin Gregorie wrote:

> On Fri, 2009-11-20 at 15:20 -0800, Mark Hedges wrote:
> > As I've already confirmed by including the debugging log
> > attachment in my first message, the test rule is loaded,
> >
> When run under sendmail and procmail as well?

The debug log that I sent the first time was the output when
running spamc from .procmailrc.

During message scan:

Fri Nov 20 11:49:32 2009 [26661] dbg: dns: checking RBL spammers.rbl.dmz., set cov_spammers

It's apparently aware of the rule, so I don't understand
why the rule is not running.

> I might have missed something, but saw that you confirmed
> the test was loaded and called in your test rig but not
> that this was necessarily true in the other two cases.
>
> > And, it doesn't explain why the rule is correctly
> > loaded, but not run when scanned, and is run when I put
> > the message through the command line.
> >
> That's often a mark of location dependency, hence my
> comment. Is it possible that the sendmail wrapper and/or
> the procmail environment are overriding the siteconfig
> path? Does your site use spamc/spamd in some places and
> spamassassin in others?

We always use spamc from .procmailrc. I used `spamassassin`
for the test recommended earlier by Benny Pedersen.
`spamassassin` works, but `spamc` does not work.

I verified that spamd is starting with the same siteconfigpath in
both `spamd` and `spamassassin`, by adding a special header only
in that cf file. So, `spamc` is talking to the correct spamd.

spamd is running like this:

spamd --max-conn-per-child=15 --timeout-child=1200 --daemonize --nouser-config --sql-config --username=defang --listen-ip=192.168.6.100 --allowed-ips=192.168.0.0/16 --debug --max-children=8 --port=793 --siteconfigpath=/etc/mail/spamassassin/digicine/ --helper-home-dir=/var/cache/spamassassin/digicine --syslog=/var/log/spamassassin/digicine.log --pidfile=/var/run/spamassassin/spamd-digicine.pid

That's the same siteconfigpath that I used with `spamassassin`.

The helper home dir is writeable by the process user. It does
not matter if I run with --paranoid or not.

I also added a header that prints _RELAYSUNTRUSTED_ for info.
The relay I'm trying to block appears in both instances.
_SUBTESTS(,)_ is also the same in both instances.

I am at the point of adding more debugging statements to the
source code. Thanks very much for your help!

Mark

cgregory at hwcn

Nov 21, 2009, 5:37 AM

Post #11 of 15 (1161 views)
Permalink

Re: rbl checks not running [In reply to]

Analysis 101:

> ..... the rule is correctly loaded, but not run when scanned
> but run when I put the message through the command line.

Did you look at the logs you posted?
NONE of the DNS tests are being launched on msg 26661....

Also, for that message, there are a suspicious set of entries that do not
appear in the second msg but appear in the first:

Fri Nov 20 11:49:31 2009 [26661] dbg: config: fixed relative path:
/var/lib/spamassassin/3.002005/updates_spamassassin_org/20_dnsbl_tests.cf

Fri Nov 20 11:49:31 2009 [26661] dbg: config: using
"/var/lib/spamassassin/3.002005/updates_spamassassin_org/20_dnsbl_tests.cf"
for included file

Fri Nov 20 11:49:31 2009 [26661] dbg: config: read file
/var/lib/spamassassin/3.002005/updates_spamassassin_org/20_dnsbl_tests.cf

..... so spamassassin definitely thinks something is different about
the enviornment, and tries to fix things. Why is it a 'relative path',
and does this interfere with any other path-based functions?

- Charles

hedges at scriptdolphin

Nov 21, 2009, 12:17 PM

Post #12 of 15 (1159 views)
Permalink

Re: rbl checks not running [In reply to]

On Sat, 21 Nov 2009, Charles Gregory wrote:
>
> Did you look at the logs you posted?
> NONE of the DNS tests are being launched on msg 26661....

Yes, that is the problem. They run with `spamassassin`, but
they do not run from `spamd`.

Do other people see this running `spamd --debug`,
although it works with `spamassassin`?

> Also, for that message, there are a suspicious set of
> entries that do not appear in the second msg but appear in
> the first:
>
> Fri Nov 20 11:49:31 2009 [26661] dbg: config: fixed relative path:
> /var/lib/spamassassin/3.002005/updates_spamassassin_org/20_dnsbl_tests.cf
>
> Fri Nov 20 11:49:31 2009 [26661] dbg: config: using
> "/var/lib/spamassassin/3.002005/updates_spamassassin_org/20_dnsbl_tests.cf"
> for included file
>
> Fri Nov 20 11:49:31 2009 [26661] dbg: config: read file
> /var/lib/spamassassin/3.002005/updates_spamassassin_org/20_dnsbl_tests.cf
>
> ..... so spamassassin definitely thinks something is
> different about the enviornment, and tries to fix things.
> Why is it a 'relative path', and does this interfere with
> any other path-based functions?

`sa-update` creates its cf with relative paths, which is
correct. When I ran the test Benny recommended using
`spamassassin` but with full '-D' debugging instead of just
'-D metadata', I see all the same messages about fixing
relative paths, and I still get the same results:
`spamassassin` runs RBL tests, but running through spamd
does not. Both logs show that all the cf files were read
and parsed correctly. I don't think that's the problem.

$ head /var/lib/spamassassin/3.002005/updates_spamassassin_org.cf
# UPDATE version 795855
include updates_spamassassin_org/10_default_prefs.cf
include updates_spamassassin_org/20_advance_fee.cf
include updates_spamassassin_org/20_body_tests.cf
include updates_spamassassin_org/20_compensate.cf
include updates_spamassassin_org/20_dnsbl_tests.cf
include updates_spamassassin_org/20_drugs.cf
include updates_spamassassin_org/20_dynrdns.cf
include updates_spamassassin_org/20_fake_helo_tests.cf
include updates_spamassassin_org/20_head_tests.cf
...

Thanks for the ideas though...

I will try comparing the full debugging output of running
`spamassassin -D` versus the startup of `spamd --debug` and
see where things are different.

Then I guess I'll have to start hacking debug messages into
the confounded source.

--mark--

hedges at scriptdolphin

Nov 23, 2009, 2:29 PM

Post #13 of 15 (1122 views)
Permalink

Re: rbl checks not running [In reply to]

On Sat, 21 Nov 2009, Mark Hedges wrote:

> On Sat, 21 Nov 2009, Charles Gregory wrote:
> >
> > Did you look at the logs you posted?
> > NONE of the DNS tests are being launched on msg 26661....
>
> Yes, that is the problem. They run with `spamassassin`, but
> they do not run from `spamd`.
>
> Do other people see this running `spamd --debug`,
> although it works with `spamassassin`?

This is weird... the test actually works fine with one of
the other instances, which is running with identical
configuration, just using a different Bayes DB. Hrmm,
curiouser and curiouser.

Mark

hedges at scriptdolphin

Nov 23, 2009, 2:41 PM

Post #14 of 15 (1119 views)
Permalink

Re: rbl checks not running [In reply to]

OMG I am SO DUMB - I had skip_rbl_checks set in my personal
userconf. DUH.

Thanks everyone for your helpful suggestions - actually it
was working fine from the beginning.

Mark

cgregory at hwcn

Nov 24, 2009, 7:44 AM

Post #15 of 15 (1068 views)
Permalink

Re: rbl checks not running [In reply to]

On Mon, 23 Nov 2009, Mark Hedges wrote:
> OMG I am SO DUMB - I had skip_rbl_checks set in my personal
> userconf. DUH.

(nod) Thanks for posting the full logs for both messages.
Once the problem is properly defined, the solution is usually
not too hard to find (though occasionally embarrassing *grin*).

Find defined. Hmmmm.... Good slogan for a company Search engine. :)

- C

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads