Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

Preventing Sender Forgery .

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


JDavila at languageworks

Aug 22, 2008, 10:18 AM

Post #1 of 19 (875 views)
Permalink
Preventing Sender Forgery .

Hi all ,

How can I prevent Sender Forgery for my server. Alot of people in my
company are getting e-mails from themselves. Any Ideas will be greatly
appreciated.

Best Regards,

Jeremy

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


Dan_Mitton at YMP

Aug 22, 2008, 10:30 AM

Post #2 of 19 (855 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Check out SPF - Sender Policy Framework:

http://www.openspf.org/

Exim has some configuration options you need to set when you build exim to
enable spf.

Dan



Sent by: exim-users-bounces[at]exim.org
To: exim-users[at]exim.org
cc: (bcc: Dan Mitton/YD/RWDOE)
Subject: [exim] Preventing Sender Forgery .
LSN: Not Relevant
User Filed as: Not a Record

Hi all ,

How can I prevent Sender Forgery for my server. Alot of people in my
company are getting e-mails from themselves. Any Ideas will be greatly
appreciated.

Best Regards,

Jeremy

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/




--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


jbriggs at esoft

Aug 22, 2008, 10:37 AM

Post #3 of 19 (856 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

On Aug 22, 2008, at 11:18 AM, JDavila[at]languageworks.com wrote:

> Hi all ,
>
> How can I prevent Sender Forgery for my server. Alot of people in my
> company are getting e-mails from themselves. Any Ideas will be greatly
> appreciated.


If your people use VPNs to work remotely, you could simply reject any
email claiming to be from a local domain from a foreign IP network.
--
Jonathan Briggs
eSoft, Inc.
jbriggs[at]esoft.com
Attachments: PGP.sig (0.19 KB)


marc at perkel

Aug 22, 2008, 10:46 AM

Post #4 of 19 (858 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

I disagree. SPF is a broken technology and no one should use it. It does
nothing to prevent spam and it creates false positives. It breaks email
forwarding.

The biggest thing you can do you reduce sender forgery is to eliminate
wildcard domains and reject invalid users at connect time. Forgers like
to spoof domains that will pass anything when queried with sender
verification.

Dan_Mitton[at]YMP.GOV wrote:
> Check out SPF - Sender Policy Framework:
>
> http://www.openspf.org/
>
> Exim has some configuration options you need to set when you build exim to
> enable spf.
>
> Dan
>
>
>
> Sent by: exim-users-bounces[at]exim.org
> To: exim-users[at]exim.org
> cc: (bcc: Dan Mitton/YD/RWDOE)
> Subject: [exim] Preventing Sender Forgery .
> LSN: Not Relevant
> User Filed as: Not a Record
>
> Hi all ,
>
> How can I prevent Sender Forgery for my server. Alot of people in my
> company are getting e-mails from themselves. Any Ideas will be greatly
> appreciated.
>
> Best Regards,
>
> Jeremy
>
>

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


maillist at ovb

Aug 22, 2008, 11:18 AM

Post #5 of 19 (860 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

JDavila[at]languageworks.com wrote:
> How can I prevent Sender Forgery for my server. Alot of people in my
> company are getting e-mails from themselves. Any Ideas will be greatly
> appreciated.
>
Only allow local domains to be used on authenticated SMTP sessions on
the submission port. I'm doing this here since a long time with no
probs. Below is an excerpt of the relevant configuration stuff, stripped
down to the essentials for this problem.

This set up assumes that all messages originating from your domains are
sent out through your own servers and not any other ISP provider mail
relays! Otherwise you run into problems if one of your users sends out a
mail to a recipient within your local_domains, as the ISP smarthost
would then send a message to one of your users with a sender address out
of your local_domains.
But this should not be a problem if you run a submission port anyway,
simply instruct all users on how to connect the your mail server
regardless of their provider/location.

Oliver


# Port 25 and local submissions result in TRUE here
IS_MTA_PORT = or{ \
{eq{$interface_port}{25}} \
{eq{$interface_port}{-1}} \
}

# Use different RCPT ACLs for MTA and MUA
acl_smtp_rcpt = ${if IS_MTA_PORT {acl_check_rcpt}{acl_check_rcpt_mua}}

acl_check_rcpt:
# Deny if sender uses local_domains as a sender, which is not expected
here
deny sender_domains = +local_domains
log_message = SMTP-SENDER-ADDRESS-AUTH-ONLY
message = Sender Domain only allowed on authenticated
submission port sessions

acl_check_rcpt_mua:
# MUA must authenticate
deny message = Authentication is required to send messages
log_message = SMTP-SUBMISSION-NO-AUTHENTICATION
!authenticated = *



--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


ahicks at p-o

Aug 22, 2008, 11:50 AM

Post #6 of 19 (856 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Marc Perkel wrote:
> I disagree. SPF is a broken technology and no one should use it. It does
> nothing to prevent spam and it creates false positives. It breaks email
> forwarding.
>
> The biggest thing you can do you reduce sender forgery is to eliminate
> wildcard domains and reject invalid users at connect time. Forgers like
> to spoof domains that will pass anything when queried with sender
> verification.

SPF works well for the domains I look after, though I do agree that it
is unsuitable where forwarding is needed.

It shouldn't be forgotten that SPF has two aspects, one where you
identify the points where email can be sent from and the second where
this information is used to block incoming mail. If I only used SPF to
block mail I would find that many domains already use SPF and this
removes much spam; as I also have SPF records to identify where mail is
sent from I have found that it completely eliminates spam sent to users
from themselves and has eliminated many of the attacks that I used to
have to deal with.

Best,
Alan

>
> Dan_Mitton[at]YMP.GOV wrote:
>> Check out SPF - Sender Policy Framework:
>>
>> http://www.openspf.org/
>>
>> Exim has some configuration options you need to set when you build exim to
>> enable spf.
>>
>> Dan
>>
>>
>>
>> Sent by: exim-users-bounces[at]exim.org
>> To: exim-users[at]exim.org
>> cc: (bcc: Dan Mitton/YD/RWDOE)
>> Subject: [exim] Preventing Sender Forgery .
>> LSN: Not Relevant
>> User Filed as: Not a Record
>>
>> Hi all ,
>>
>> How can I prevent Sender Forgery for my server. Alot of people in my
>> company are getting e-mails from themselves. Any Ideas will be greatly
>> appreciated.
>>
>> Best Regards,
>>
>> Jeremy
>>
>>
>

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


martin at antibodymx

Aug 22, 2008, 2:23 PM

Post #7 of 19 (849 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Marc Perkel wrote:
> I disagree. SPF is a broken technology and no one should use it. It does
> nothing to prevent spam

It's not an anti-spam system, so that's no real surprise.


> The biggest thing you can do you reduce sender forgery is to eliminate
> wildcard domains and reject invalid users at connect time.

The more I read that sentence, the less it makes sense. Please elaborate.




--

Martin A. Brooks | http://www.antibodymx.net/ | Anti-spam& anti-virus
Consultant | martin[at]antibodymx.net | filtering. Inoculate
antibodymx.net | m: +447792493388 | your mail system.


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


arekm at maven

Aug 22, 2008, 2:36 PM

Post #8 of 19 (845 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

On Friday 22 August 2008, Oliver von Bueren wrote:
> JDavila[at]languageworks.com wrote:
> > How can I prevent Sender Forgery for my server. Alot of people in my
> > company are getting e-mails from themselves. Any Ideas will be greatly
> > appreciated.
>
> Only allow local domains to be used on authenticated SMTP sessions on
> the submission port.

"local domains" is the problem. People have mostly non local domains. They get
emails from outside world.

Deny mail commit from local domains without smtp auth.

deny message = Not allowed without SMTP AUTH
domains = +local_domains
sender_domains = +local_domains
!authenticated = *


Note this has one big weakness. You can send mail with
MAIL FROM: <outside[at]outside.domain>
and then still put
From: inside[at]inside.domain
and this will go trough.

Some $h_from rule checking would be needed, too.

--
Arkadiusz Miƛkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


kroshka at atypon

Aug 22, 2008, 5:40 PM

Post #9 of 19 (848 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Oliver von Bueren wrote:
> JDavila[at]languageworks.com wrote:
>> How can I prevent Sender Forgery for my server. Alot of people in my
>> company are getting e-mails from themselves. Any Ideas will be greatly
>> appreciated.
>>
> Only allow local domains to be used on authenticated SMTP sessions on
> the submission port. I'm doing this here since a long time with no

You can't really stop forging the From: that way. Neither will SPF stop
forging email headers. Nothing really will, except a total redesign of
the smtp protocol or a totally new protocol.

Grey listing and other spam filtering techniques will help a lot. Since
emails with forged headers almost solely are from spammers you will
block many forged emails that way.

Greetings,
Jeroen

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


maillist at ovb

Aug 23, 2008, 12:57 AM

Post #10 of 19 (837 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Jeroen van Aart wrote:
> Oliver von Bueren wrote:
>
>> JDavila[at]languageworks.com wrote:
>>
>>> How can I prevent Sender Forgery for my server. Alot of people in my
>>> company are getting e-mails from themselves. Any Ideas will be greatly
>>> appreciated.
>>>
>>>
>> Only allow local domains to be used on authenticated SMTP sessions on
>> the submission port. I'm doing this here since a long time with no
>>
>
> You can't really stop forging the From: that way. Neither will SPF stop
> forging email headers. Nothing really will, except a total redesign of
> the smtp protocol or a totally new protocol.
>
As I wrote in my mail, this is only a small portion of what I do in my
set up to prevent this kind of attack. And for this discussion, I only
wrote about the checks on the SMTP sender/recipient level, content
scanning of the message, to which the From: / To: headers ultimately
belong to, is an entirely different topic in my configuration and for
obvious reasons not in the RCPT acl.
BTW: local_domains includes all domains for which I handle mail and have
control over, meaning the final MX destination is within my set up.

This part of the configuration only prevents simple spam senders to use
the MAIL FROM of the destination user (or any local user for that
matter), as is often done. This trick gets rid of a lot of simple Spam.
And, as you see from the original message, many systems treat mail sent
with a local_domains sender address in a way to just pass it. After
implementing this very simple step, which should be in place on a server
reachable from the internet anyway, otherwise you are an open relay,
you have to make sure that some basic or more extensive checks of the
sender address are performed, e.g. check the existence of the sender
domain, may be do callout verification for the sender, use RBLs, ....
Please note, these are all checks done on the way to accepting at RCPT
TO so more expensive checks at the data stage can be prevented because
the message gets rejected early on!

So my simple policies for accepting mail are:
0. HELO/EHLO abuse
1. Never relay mail without AUTH
2. Prevent abuse of local_domains as sender, only allow on AUTH sessions
3. RBLs, ...
4. Sender verify
5. Content analysis (might be SA, but can be simpler stuff as well)

0-4 generate deny at RCPT TO, 5 at DATA. Messages getting through will
be delivered as they have been accepted into the system in the first
place. Tagging might mark these as SPAM, though.

Oliver


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


Lena at lena

Aug 23, 2008, 5:05 AM

Post #11 of 19 (837 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

> From: JDavila

> How can I prevent Sender Forgery for my server.

In almost all spam letters sender is forged. What's the difference
what the forger specified as the sender - address of some innocent bystander
or address of the recipient?

You need to block spam (not throwing baby out with the dirty water,
i.e. minimizing false positives - a honest letter erroneously
classified as spam) irrespective of what is specified as sender
(except checking that sender domain exists: verify=sender).

You can safely reject if one of your domains is specified in HELO,
but not if it's specified as sender.

> Alot of people in my
> company are getting e-mails from themselves.

They should be able to get real (not spam) emails from themselves.
Some maillist servers don't change sender. Users should recieve
their own messages sent to maining lists. One of members' complaints
often quoten on mailing lists for moderators of mailing lists
is that GMail discards letters with same Message-Id as already kept
including copy of sent mail, so that members don't recive their own
messages sent to mailing lists, so cannot know whether the message
was disapproved or edited by a moderator.

Also, users should be able for a test to send a letter to an external
forwarder which forwards the letter to the user, it's the easiest way
to quickly test that both outgoing and incoming paths work at the time.

> Any Ideas will be greatly
> appreciated.

I attached my ACLs to http://wiki.exim.org/DbLessGreyListingRun
They proved to be surprisingly effective for fending spam and viruses
though my goal was minimizing false postives.

Lena

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at lists

Aug 23, 2008, 6:40 AM

Post #12 of 19 (838 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Jeroen van Aart wrote:

>>> How can I prevent Sender Forgery for my server. Alot of people in my
>>> company are getting e-mails from themselves. Any Ideas will be greatly
>>> appreciated.
>>>
>> Only allow local domains to be used on authenticated SMTP sessions on
>> the submission port. I'm doing this here since a long time with no
>
> You can't really stop forging the From: that way.

You can. In DATA acl:

deny message = Not allowed without SMTP AUTH
condition = ${if match_domain{${domain:$h_From:}}{+local_domains}}
!authenticated = *

> Neither will SPF stop
> forging email headers. Nothing really will, except a total redesign of
> the smtp protocol or a totally new protocol.

DKIM could stop people forging your domain in headers to a certain
extent. People need to start using it more first though.

> Grey listing and other spam filtering techniques will help a lot. Since
> emails with forged headers almost solely are from spammers you will
> block many forged emails that way.

Aye.

Mike

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


kroshka at atypon

Aug 25, 2008, 1:47 PM

Post #13 of 19 (795 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Oliver von Bueren wrote:
> As I wrote in my mail, this is only a small portion of what I do in my

I understand.

> So my simple policies for accepting mail are:
> 0. HELO/EHLO abuse
> 1. Never relay mail without AUTH
> 2. Prevent abuse of local_domains as sender, only allow on AUTH sessions
> 3. RBLs, ...
> 4. Sender verify
> 5. Content analysis (might be SA, but can be simpler stuff as well)

It looks like you don't have greylisting, I believe adding it as your
first check will prove to be very effective. It's an inexpensive check
and will likely block more than 90% of your spam, which includes many
forged emails.

Greetings,
Jeroen

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


iane at sussex

Aug 26, 2008, 4:42 AM

Post #14 of 19 (783 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

--On 22 August 2008 10:46:55 -0700 Marc Perkel <marc[at]perkel.com> wrote:

> I disagree. SPF is a broken technology and no one should use it. It does
> nothing to prevent spam and it creates false positives. It breaks email
> forwarding.

That entirely depends *how* you use it.


>
> The biggest thing you can do you reduce sender forgery is to eliminate
> wildcard domains and reject invalid users at connect time. Forgers like
> to spoof domains that will pass anything when queried with sender
> verification.
>
> Dan_Mitton[at]YMP.GOV wrote:
>> Check out SPF - Sender Policy Framework:
>>
>> http://www.openspf.org/
>>
>> Exim has some configuration options you need to set when you build exim
>> to enable spf.
>>
>> Dan
>>
>>
>>
>> Sent by: exim-users-bounces[at]exim.org
>> To: exim-users[at]exim.org
>> cc: (bcc: Dan Mitton/YD/RWDOE)
>> Subject: [exim] Preventing Sender Forgery .
>> LSN: Not Relevant
>> User Filed as: Not a Record
>>
>> Hi all ,
>>
>> How can I prevent Sender Forgery for my server. Alot of people in my
>> company are getting e-mails from themselves. Any Ideas will be greatly
>> appreciated.
>>
>> Best Regards,
>>
>> Jeremy
>>



--
Ian Eiloart
IT Services, University of Sussex
x3148

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


iane at sussex

Aug 26, 2008, 4:47 AM

Post #15 of 19 (784 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

--On 22 August 2008 13:18:58 -0400 JDavila[at]languageworks.com wrote:

> Hi all ,
>
> How can I prevent Sender Forgery for my server. Alot of people in my
> company are getting e-mails from themselves. Any Ideas will be greatly
> appreciated.

When we see email with the MAIL FROM argument in our domain, we reject the
email unless it contains a header that our servers have added. It isn't
anything fancy, but we could put some kind of digital signature in there -
eg with DKIM.

I filter my mail so that internal email is in a separate INBOX, and it's
virtually spam free. There's no good reason why that should be so, the
From: header domain doesn't have to match that in the envelope, but that's
my experience.

>
> Best Regards,
>
> Jeremy



--
Ian Eiloart
IT Services, University of Sussex
x3148

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


maillist at ovb

Aug 26, 2008, 1:14 PM

Post #16 of 19 (779 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Jeroen van Aart wrote:
> It looks like you don't have greylisting, I believe adding it as your
> first check will prove to be very effective. It's an inexpensive check
> and will likely block more than 90% of your spam, which includes many
> forged emails.
>
Up till now I had no reason to implement Graylisting.

I've considered it but carefully selecting my RBLs and also some
blocking with content scan (e.g. for know URLs of Spamvertising sites)
I've got very few Spam messages getting accepted. False-Positive is no
problem at my site as well.
All these facts lead me to the conclusion, that I don't bother the
hassle to implement Graylisting with all its problems and workarounds
(e.g. big providers like hotmail, ...).

In bare figures this means, of the 5% of accepted mail, get a couple out
more the max. Or in numbers, 50 mails per 1000 tries accepted, thereof
about 1 is spam. That is way too low to justify Graylisting, IMHO.

I won't disclose my exact RBL configuration, but I strongly suggest
everyone uses/buys one of the good DUHL lists to get rid of a lot of
Dialup and other "dynamic" IP addresses like xDSL/Cable/... A few other
well established lists and you reach 90% as well. The rest is fine
tuning and simple content scanning. All with the benefit, if a legit
message gets rejected (at SMTP RCPT TO or the latest after DATA), the
sender gets an error message stating his problem.

Oliver


--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


jethro.binks at strath

Aug 26, 2008, 1:41 PM

Post #17 of 19 (779 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

On Tue, 26 Aug 2008, Oliver von Bueren wrote:

> I won't disclose my exact RBL configuration,

Why?

Jethro.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


maillist at ovb

Aug 26, 2008, 2:02 PM

Post #18 of 19 (779 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

Jethro R Binks wrote:
> On Tue, 26 Aug 2008, Oliver von Bueren wrote:
>
>> I won't disclose my exact RBL configuration,
>>
>
> Why?
>
Hmm, that is a good question, as my experience tells me that security
through hiding doesn't work, on the other hand it somehow doesn't feel
right to me. Considering this sentence again, there's no real reason
other than my feeling.;-)
Anyway, if someone doesn't know http://openrbl.org/, try that as a
starting point (use JS client and click through the lists), a lot of
reading concerning the policies of the different lists compared to your
own policy you have running your mail server and also some DNSBL lists
from Google.
Said that, I don't think an exact copy of my list set up would help a
lot, IMHO every admin should decide for himself which lists are acceptable.

Oliver

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


jethro.binks at strath

Aug 26, 2008, 2:14 PM

Post #19 of 19 (778 views)
Permalink
Re: Preventing Sender Forgery . [In reply to]

On Tue, 26 Aug 2008, Oliver von Bueren wrote:

> > Why?
> >
> Hmm, that is a good question, as my experience tells me that security
> through hiding doesn't work, on the other hand it somehow doesn't feel
> right to me. Considering this sentence again, there's no real reason
> other than my feeling.;-)
> Anyway, if someone doesn't know http://openrbl.org/, try that as a
> starting point (use JS client and click through the lists), a lot of
> reading concerning the policies of the different lists compared to your
> own policy you have running your mail server and also some DNSBL lists
> from Google.
> Said that, I don't think an exact copy of my list set up would help a
> lot, IMHO every admin should decide for himself which lists are acceptable.

Of course, and I entirely agree, but many have found that the sharing of
particularly effective combinations of DNSBLs to be useful -- but always
with the caveat that the de/listing policies and operation must be
carefully considered by any administrator who is considering using any
particular one.

Added to that is the fact that DNSBLs come and go, and maybe there are
newer ones around these days that may prove effective that those who
already have an established DNSBL combination may wish to consider.

Jethro.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.