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 <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. > > > > 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 > <sqlite-users at mailinglists.sqlite.org> 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
