[sqlite] Mailing list policy change

[Simon Slavin]

On 29 Oct 2015, at 2:21pm, Adam Devita  wrote:

> Question:  Is it possible for the admin to easily backup the list,
> bisect it, and test for spam?
> That technique should identify the offending address in
> log2(N-Users-Subscribed) attempts.

You don't even need to mess with the genuine list server.  Just grab all the 
addresses it sends to and use another computer to send messages directly to 
those addresses using the binary-chop thing.  You only need to send the second 
message to half the subscribers and the third to a quarter.

I'm not saying that this should be done, just that there's an easier way to do 
it.

Simon.

[sqlite] Mailing list policy change

[Adam Devita]

Assuming the A*spammer is a basic algo subscribed to the list, and
sending to any sender in a reasonably short time after posting;

Question:  Is it possible for the admin to easily backup the list,
bisect it, and test for spam?
That technique should identify the offending address in
log2(N-Users-Subscribed) attempts.

If unfeasible, I'd prefer mangling / salting the e-mail addresses of
users (if this can be done easily) displayed to thwart bot spammers
and still see the names of the poster.   I follow interesting 'topics'
rather than people, but I think seeing the names of posters up-front
is part of the community dynamic that has been built, and makes
following the exchanges easier to follow, particularly for longer
threads.

Adam D



On Thu, Oct 29, 2015 at 4:01 AM, SQLite mailing list
 wrote:
> On Wed, Oct 28, 2015 at 6:52 PM, General Discussion of SQLite Database <
> sqlite-users at mailinglists.sqlite.org> wrote:
>
>> Effective immediately, the sender email address for mailing list posts
>> will be elided.  All replies must go back to the mailing list itself.
>>
>
> Please reconsider. Not knowing who's talking is untenable.
>
> Let each and everyone's SPAM filter take care of it.
>
> As someone already mentioned, there are tons of way to harvest past email
> addresses from archives anyway.
>
> --DD
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



-- 
--
VerifEye Technologies Inc.
151 Whitehall Dr. Unit 2
Markham, ON
L3R 9T1

[sqlite] Mailing list policy change

[SQLite mailing list]

On Wed, Oct 28, 2015 at 6:52 PM, General Discussion of SQLite Database <
sqlite-users at mailinglists.sqlite.org> wrote:

> Effective immediately, the sender email address for mailing list posts
> will be elided.  All replies must go back to the mailing list itself.
>

Please reconsider. Not knowing who's talking is untenable.

Let each and everyone's SPAM filter take care of it.

As someone already mentioned, there are tons of way to harvest past email
addresses from archives anyway.

--DD

[sqlite] Mailing list policy change

[SQLite mailing list]

I think I received about four, which I removed in a couple of seconds. 
Obviously it is a problem, but I don't think it calls for a change that 
makes it impossible to see the sender of each message. I always open 
messages from the SqLite developers sort of by default, for instance, 
which I can no longer do.

Kind regards,

Philip Bennefall

On 10/28/2015 11:49 PM, SQLite mailing list wrote:
>   
>> Has anybody received email from Alexa since the policy change?  I have
>> not
> I have never received any ... presumably Alexa's MTA (s if more than one) is 
> blacklisted ...
>
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> .
>

[sqlite] Mailing list policy change

[SQLite mailing list]

On 2015-10-28 10:34 PM, SQLite mailing list wrote:
> On 10/28/15, SQLite mailing list  
> wrote:
>> This is ridiculous.  I know how to handle spam.  I can do nothing
>> about not knowing who sent these emails.
>>
> One thing you could do is add a signature line, to tell the rest of us
> who you are  :-)
>

I think you've made his point for him precisely. If any of us fail to 
add such a line, as I never do, then it's a guess.

I'm starting to miss Alexa.

[sqlite] Mailing list policy change

[SQLite mailing list]

Yeah.  Let's not admit defeat to a lone a**hole.  My spam filter is bored 
anyway -- let's give it something to do. 

Eric

Sent from my iPhone

> On Oct 28, 2015, at 19:12, SQLite mailing list  mailinglists.sqlite.org> wrote:
> 
> I agree.  This cure is worse than the disease.
> 
> At least for now (from the 2 I got) the Alexa sender address was constant and 
> can be blacklisted.  Regardless of how Alexa got our email addresses, they 
> have them and can send spam like any spammer.
> 
> -- Darren Duncan
> 
>> On 2015-10-28 2:50 PM, SQLite mailing list wrote:
>> This really is awful and unworkable. There a re a few options
>> 
>> 1. maintain things as they are now - and everyone has to add a
>> signature line and we need to open every message to see who has sent
>> it. There are some posters I make a point of reading and just seeing
>> their name in a mail header makes me much more likely to open it.
>> 
>> 2. Somehow configure the system to display the senders name and not
>> their email address - seems frought with issues
>> 
>> 3. Go back to the old system and we have one more bit of spam that we
>> need to get rid of (something I have already done).
>> 
>> I vote for 3. Alexa was a minor inconvenience and the solution imposed
>> is much more of a PITA than she was.
>> 
>> 
>> 
>> 
>> On 28 October 2015 at 20:34, SQLite mailing list
>>  wrote:
>>> On 10/28/15, SQLite mailing list  
>>> wrote:
 
 This is ridiculous.  I know how to handle spam.  I can do nothing
 about not knowing who sent these emails.
>>> 
>>> One thing you could do is add a signature line, to tell the rest of us
>>> who you are  :-)
>>> 
>>> --
>>> D. Richard Hipp
>>> drh at sqlite.org
> 
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Mailing list policy change

[SQLite mailing list]

This really is awful and unworkable. There a re a few options

1. maintain things as they are now - and everyone has to add a
signature line and we need to open every message to see who has sent
it. There are some posters I make a point of reading and just seeing
their name in a mail header makes me much more likely to open it.

2. Somehow configure the system to display the senders name and not
their email address - seems frought with issues

3. Go back to the old system and we have one more bit of spam that we
need to get rid of (something I have already done).

I vote for 3. Alexa was a minor inconvenience and the solution imposed
is much more of a PITA than she was.




On 28 October 2015 at 20:34, SQLite mailing list
 wrote:
> On 10/28/15, SQLite mailing list  
> wrote:
>>
>> This is ridiculous.  I know how to handle spam.  I can do nothing
>> about not knowing who sent these emails.
>>
>
> One thing you could do is add a signature line, to tell the rest of us
> who you are  :-)
>
> --
> D. Richard Hipp
> drh at sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Mailing list policy change

[SQLite mailing list]

On Wed, Oct 28, 2015 at 9:08 PM, SQLite
 wrote:
>
> On 28 Oct 2015, at 7:36pm, General Discussion of SQLite Database 
>  wrote:
>
>> Has anybody received email from Alexa since the policy change?  I have 
>> not
>
> Nor me.  I reliably got one for every post I made for about a week before the 
> change.

This is ridiculous.  I know how to handle spam.  I can do nothing
about not knowing who sent these emails.

Dr Hipp, please reconsider.

[sqlite] Mailing list policy change

[SQLite]

On 28 Oct 2015, at 7:36pm, General Discussion of SQLite Database  wrote:

> Has anybody received email from Alexa since the policy change?  I have not

Nor me.  I reliably got one for every post I made for about a week before the 
change.

Simon.

[sqlite] Mailing list policy change

[SQLite]

Actually looking at this thread (in gmail) since the policy change is
a very retrograde step - all messages are displayed as  from SQLite.

There are numerous scenarios where I want to see the name of the
sender (not necessarily the email address) so that I can pick and
choose which messages I read.

I fear the cure here is going to be worse than the disease.
Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
-Forensic Toolkit for SQLite
email from a work address for a fully functional demo licence


On 28 October 2015 at 19:46, SQLite
 wrote:
> Is this over-reacting a bit. I have had one email from alexa (about
> 3/4 weeks ago). If it starts to become a real problem then do
> something about it - until then I would think we all have more
> important things to worry about.
>
>
>
> Paul
> www.sandersonforensics.com
> skype: r3scue193
> twitter: @sandersonforens
> Tel +44 (0)1326 572786
> http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
> -Forensic Toolkit for SQLite
> email from a work address for a fully functional demo licence
>
>
> On 28 October 2015 at 19:42, SQLite
>  wrote:
>> On Wed, Oct 28, 2015 at 11:22 AM, General Discussion of SQLite Database <
>> sqlite-users at mailinglists.sqlite.org> wrote:
>>
>>> On 28.10.2015 18:52, General Discussion of SQLite Database wrote:
>>>
 Hence, we have token the radical approach of denying the sender email
 address to*everyone*.

>>>
>>> Could you preserve the sender's name in the from header instead of
>>> substituting the generic "General Discussion of SQLite Database"?
>>>
>>> This would make it possible to automatically highlight messages by author,
>>> i.e. the SQLite dev team.
>>
>>
>> My suggestion is to go whole-hog and find a mailing-list system or host
>> which allows routing return addresses back through the server.  It could be
>> blob-7fe742b at mailinglists.sqlite.org , or it could even use info stripped
>> from the email, so ScottHess-7fe742b at mailinglists.sqlite.org.  The basic
>> goal being to have a readable part and an unpredictable part.  Then people
>> abusing the system in simple ways can be directly identified.  [If the
>> spammer is going to spend time looking up old email addresses, then
>> changing the list policies will take a long time to help, much, since there
>> are years of addresses already out there.]
>>
>> Another option would be to have the server forward emails with various
>> delays so that when people report spam you could (maybe) figure out by the
>> timing which subset of recipients were at fault.
>>
>> Personally, I'd rather know who's communicating on the channel and deal
>> with periodic spam.
>>
>> -scott (shess at google.com)
>> ___
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Mailing list policy change

[SQLite]

Is this over-reacting a bit. I have had one email from alexa (about
3/4 weeks ago). If it starts to become a real problem then do
something about it - until then I would think we all have more
important things to worry about.



Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
-Forensic Toolkit for SQLite
email from a work address for a fully functional demo licence


On 28 October 2015 at 19:42, SQLite
 wrote:
> On Wed, Oct 28, 2015 at 11:22 AM, General Discussion of SQLite Database <
> sqlite-users at mailinglists.sqlite.org> wrote:
>
>> On 28.10.2015 18:52, General Discussion of SQLite Database wrote:
>>
>>> Hence, we have token the radical approach of denying the sender email
>>> address to*everyone*.
>>>
>>
>> Could you preserve the sender's name in the from header instead of
>> substituting the generic "General Discussion of SQLite Database"?
>>
>> This would make it possible to automatically highlight messages by author,
>> i.e. the SQLite dev team.
>
>
> My suggestion is to go whole-hog and find a mailing-list system or host
> which allows routing return addresses back through the server.  It could be
> blob-7fe742b at mailinglists.sqlite.org , or it could even use info stripped
> from the email, so ScottHess-7fe742b at mailinglists.sqlite.org.  The basic
> goal being to have a readable part and an unpredictable part.  Then people
> abusing the system in simple ways can be directly identified.  [If the
> spammer is going to spend time looking up old email addresses, then
> changing the list policies will take a long time to help, much, since there
> are years of addresses already out there.]
>
> Another option would be to have the server forward emails with various
> delays so that when people report spam you could (maybe) figure out by the
> timing which subset of recipients were at fault.
>
> Personally, I'd rather know who's communicating on the channel and deal
> with periodic spam.
>
> -scott (shess at google.com)
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

On 28.10.2015 18:52, General Discussion of SQLite Database wrote:

> Hence, we have token the radical approach of denying the sender email
> address to*everyone*.

Could you preserve the sender's name in the from header instead of 
substituting the generic "General Discussion of SQLite Database"?

This would make it possible to automatically highlight messages by 
author, i.e. the SQLite dev team.

Ralf

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

>
> Could you preserve the sender's name in the from header instead of
> substituting the generic "General Discussion of SQLite Database"?
>
> This would make it possible to automatically highlight messages by
> author, i.e. the SQLite dev team.

I second that request!

--
Bill Drago
Staff Engineer
L3 Narda-MITEQ
435 Moreland Road
Hauppauge, NY 11788
631-272-5947 / William.Drago at L-3COM.com

CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any 
attachments are solely for the use of the addressee and may contain information 
that is privileged or confidential. Any disclosure, use or distribution of the 
information contained herein is prohibited. In the event this e-mail contains 
technical data within the definition of the International Traffic in Arms 
Regulations or Export Administration Regulations, it is subject to the export 
control laws of the U.S.Government. The recipient should check this e-mail and 
any attachments for the presence of viruses as L-3 does not accept any 
liability associated with the transmission of this e-mail. If you have received 
this communication in error, please notify the sender by reply e-mail and 
immediately delete this message and any attachments.

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

On 28 Oct 2015, at 5:52pm, General Discussion of SQLite Database  wrote:

> All replies must go back to the mailing list itself.

Erm ... just a warning from an experienced mailadmin.  If you do this exactly 
the way you described they can trigger an endless loop of spam just by 
subscribing Alexa's email address to this list.  So, of course, you have made 
this impossible.

Simon.

[sqlite] Mailing list policy change

[SQLite mailing list]

> Has anybody received email from Alexa since the policy change?  I have
> not

I have never received any ... presumably Alexa's MTA (s if more than one) is 
blacklisted ...

[sqlite] Mailing list policy change

[SQLite mailing list]

On 10/28/15, SQLite mailing list  
wrote:
>
> This is ridiculous.  I know how to handle spam.  I can do nothing
> about not knowing who sent these emails.
>

One thing you could do is add a signature line, to tell the rest of us
who you are  :-)

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] Mailing list policy change

[SQLite mailing list]

I agree.  This cure is worse than the disease.

At least for now (from the 2 I got) the Alexa sender address was constant and 
can be blacklisted.  Regardless of how Alexa got our email addresses, they have 
them and can send spam like any spammer.

-- Darren Duncan

On 2015-10-28 2:50 PM, SQLite mailing list wrote:
> This really is awful and unworkable. There a re a few options
>
> 1. maintain things as they are now - and everyone has to add a
> signature line and we need to open every message to see who has sent
> it. There are some posters I make a point of reading and just seeing
> their name in a mail header makes me much more likely to open it.
>
> 2. Somehow configure the system to display the senders name and not
> their email address - seems frought with issues
>
> 3. Go back to the old system and we have one more bit of spam that we
> need to get rid of (something I have already done).
>
> I vote for 3. Alexa was a minor inconvenience and the solution imposed
> is much more of a PITA than she was.
>
>
>
>
> On 28 October 2015 at 20:34, SQLite mailing list
>  wrote:
>> On 10/28/15, SQLite mailing list  
>> wrote:
>>>
>>> This is ridiculous.  I know how to handle spam.  I can do nothing
>>> about not knowing who sent these emails.
>>>
>>
>> One thing you could do is add a signature line, to tell the rest of us
>> who you are  :-)
>>
>> --
>> D. Richard Hipp
>> drh at sqlite.org

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

On 10/28/15, General Discussion of SQLite Database
 wrote:
> On 2015-10-28 10:52 AM, General Discussion of SQLite Database wrote:
>> The reason for this change is to combat the "Alexa" spam.  For the
>> past few weeks, whenever anybody posts to the mailing list, that
>> person gets a reply from "Alexa"...
>
> While that was often the case, I recall someone saying they got the Alexa
> spam
> simply by subscribing to the list, without posting.  This implies a
> server-side
> leak.  Unless that poster was wrong. -- Darren Duncan
>

Has anybody received email from Alexa since the policy change?  I have not

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] Mailing list policy change

[SQLite]

On Wed, Oct 28, 2015 at 1:46 PM, SQLite <
sqlite-users at mailinglists.sqlite.org> wrote:

> Is this over-reacting a bit. I have had one email from alexa (about
> 3/4 weeks ago). If it starts to become a real problem then do
> something about it - until then I would think we all have more
> important things to worry about.
>

For some people it is a larger problem. I've received a few (I think 4)
Alexa emails since this began. It sounds like some people get a lot more
(like DRH).

SDR


>
>
>
> Paul
> www.sandersonforensics.com
> skype: r3scue193
> twitter: @sandersonforens
> Tel +44 (0)1326 572786
> http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
> -Forensic
> 
> Toolkit for SQLite
> email from a work address for a fully functional demo licence
>
>
> On 28 October 2015 at 19:42, SQLite
>  wrote:
> > On Wed, Oct 28, 2015 at 11:22 AM, General Discussion of SQLite Database <
> > sqlite-users at mailinglists.sqlite.org> wrote:
> >
> >> On 28.10.2015 18:52, General Discussion of SQLite Database wrote:
> >>
> >>> Hence, we have token the radical approach of denying the sender email
> >>> address to*everyone*.
> >>>
> >>
> >> Could you preserve the sender's name in the from header instead of
> >> substituting the generic "General Discussion of SQLite Database"?
> >>
> >> This would make it possible to automatically highlight messages by
> author,
> >> i.e. the SQLite dev team.
> >
> >
> > My suggestion is to go whole-hog and find a mailing-list system or host
> > which allows routing return addresses back through the server.  It could
> be
> > blob-7fe742b at mailinglists.sqlite.org , or it could even use info
> stripped
> > from the email, so ScottHess-7fe742b at mailinglists.sqlite.org.  The basic
> > goal being to have a readable part and an unpredictable part.  Then
> people
> > abusing the system in simple ways can be directly identified.  [If the
> > spammer is going to spend time looking up old email addresses, then
> > changing the list policies will take a long time to help, much, since
> there
> > are years of addresses already out there.]
> >
> > Another option would be to have the server forward emails with various
> > delays so that when people report spam you could (maybe) figure out by
> the
> > timing which subset of recipients were at fault.
> >
> > Personally, I'd rather know who's communicating on the channel and deal
> > with periodic spam.
> >
> > -scott (shess at google.com)
> > ___
> > sqlite-users mailing list
> > sqlite-users at mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Scott Robison

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

Effective immediately, the sender email address for mailing list posts
will be elided.  All replies must go back to the mailing list itself.

The reason for this change is to combat the "Alexa" spam.  For the
past few weeks, whenever anybody posts to the mailing list, that
person gets a reply from "Alexa" that contains not-safe-for-work
photos and also (presumably) malware.  We have tried other techniques
to thwart Alexa, but we have so far been unable to figure out which of
2000+ subscribers is providing Alexa with the sender's email address.
Hence, we have token the radical approach of denying the sender email
address to *everyone*.

This is sad.  It means that sending off-list replies (something I do
frequently) is no longer possible unless the sender includes their
email address in the signature line (as I do - see below).  But it is
what it is.  We live in a fallen world.  Pray for the wretched soul of
the Alexa spammer that he might turn from his wicked ways and find
forgiveness.

-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] Mailing list policy change

[SQLite]

On Wed, Oct 28, 2015 at 1:32 PM, General Discussion of SQLite Database <
sqlite-users at mailinglists.sqlite.org> wrote:

> On 2015-10-28 10:52 AM, General Discussion of SQLite Database wrote:
>
>> The reason for this change is to combat the "Alexa" spam.  For the
>> past few weeks, whenever anybody posts to the mailing list, that
>> person gets a reply from "Alexa"...
>>
>
> While that was often the case, I recall someone saying they got the Alexa
> spam simply by subscribing to the list, without posting.  This implies a
> server-side leak.  Unless that poster was wrong. -- Darren Duncan


I (Scott Robison) tried to exercise that by signing up a new account with a
new email address and never received Alexa spam to the new address with my
(very obviously faked) user name. I can't say whether it is because the
list admins saw the (very obviously faked) account and deleted it (as they
did a day or so later) or if the Alexa spam generator requires manual
intervention, but at the very least the process of signing up for the
address was not enough.

Also, I have not received Alexa spam to every email I have sent to the
list. I've received a few, but not every time.

-- 
Scott Robison

[sqlite] Mailing list policy change

[SQLite]

On Wed, Oct 28, 2015 at 11:22 AM, General Discussion of SQLite Database <
sqlite-users at mailinglists.sqlite.org> wrote:

> On 28.10.2015 18:52, General Discussion of SQLite Database wrote:
>
>> Hence, we have token the radical approach of denying the sender email
>> address to*everyone*.
>>
>
> Could you preserve the sender's name in the from header instead of
> substituting the generic "General Discussion of SQLite Database"?
>
> This would make it possible to automatically highlight messages by author,
> i.e. the SQLite dev team.


My suggestion is to go whole-hog and find a mailing-list system or host
which allows routing return addresses back through the server.  It could be
blob-7fe742b at mailinglists.sqlite.org , or it could even use info stripped
from the email, so ScottHess-7fe742b at mailinglists.sqlite.org.  The basic
goal being to have a readable part and an unpredictable part.  Then people
abusing the system in simple ways can be directly identified.  [If the
spammer is going to spend time looking up old email addresses, then
changing the list policies will take a long time to help, much, since there
are years of addresses already out there.]

Another option would be to have the server forward emails with various
delays so that when people report spam you could (maybe) figure out by the
timing which subset of recipients were at fault.

Personally, I'd rather know who's communicating on the channel and deal
with periodic spam.

-scott (shess at google.com)

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

On 2015-10-28 10:52 AM, General Discussion of SQLite Database wrote:
> The reason for this change is to combat the "Alexa" spam.  For the
> past few weeks, whenever anybody posts to the mailing list, that
> person gets a reply from "Alexa"...

While that was often the case, I recall someone saying they got the Alexa spam 
simply by subscribing to the list, without posting.  This implies a server-side 
leak.  Unless that poster was wrong. -- Darren Duncan

[sqlite] Mailing list policy change

[General Discussion of SQLite Database]

On 2015-10-28 11:25 AM, General Discussion of SQLite Database wrote:
>>
>> Could you preserve the sender's name in the from header instead of
>> substituting the generic "General Discussion of SQLite Database"?
>>
>> This would make it possible to automatically highlight messages by
>> author, i.e. the SQLite dev team.
>
> I second that request!

I third that request!

Even if the sender email address is hidden, it is immensely important to know 
at 
a glance (in the headers) who is the one speaking.  The SQLite lists receive a 
lot of traffic and I only read a fraction of them, often deciding what to read 
by who sent it (along with subject).

The list message headers should still have 2 email addresses, one being the 
list 
address and name as usual, and the other being the sender's name, but for them 
have a faux address such as no-reply at mailinglists.sqlite.org so that 
people's 
address books don't automatically associate some random poster's name with the 
mailing list itself.

-- Darren Duncan