[sqlite] Mailing list policy change
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
> > 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
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] Simple Math Question
On 28 Oct 2015, at 5:08pm, James K. Lowden wrote: > If we accept what you say, above, then why should > >> (9.2+7.8+0+3.0+1.3+1.7) > > in particular present any problem? There's no division. Each value > has an exact decimal representation. You didn't work it out yourself, did you ? 0.2 in binary is 0.0011001100110011... 0.3 in binary is 0.0100110011001100... They both recur at the 1/16th level. 0.7 and 0.8 are, of course, their complements. Only two tenths don't have problems in binary: point zero and point five. Simon.
[sqlite] Mailing list policy change
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
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
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
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
[sqlite] Simple Math Question
On Wed, Oct 28, 2015 at 10:08 AM, James K. Lowden
wrote:
> On Fri, 23 Oct 2015 10:43:44 -0700 Scott Hess wrote:
> > You're right, any base-2 representation right of the decimal should be
> > precise to represent in base-10. But it's the kind of thing where if
> > you find yourself counting on it, you probably made a grave error
> > earlier in your design :-).
>
> I'm either brave or naive enough to think I can still add to this
> discussion. If we accept what you say, above, then why should
>
> > (9.2+7.8+0+3.0+1.3+1.7)
>
> in particular present any problem? There's no division. Each value
> has an exact decimal representation. I'm prepared to assert that any
> permutation of their sums also has an exact decimal representation.
> Therefore they should have an exact binary representation, too.
Of those numbers, only 0 and 3.0 have an exact binary representation:
echo 9.2 7.8 0 3.0 1.3 1.7 | xargs -n1 -I{} printf "{} is %a\n" {}
9.2 is 0x1.2p+3
7.8 is 0x1.fp+2
0 is 0x0p+0
3.0 is 0x1.8p+1
1.3 is 0x1.4cccdp+0
1.7 is 0x1.bp+0
Those binary representations can be converted back into precise decimal
representations, but those decimal representations will not be the original
decimal values, because they were translated from decimal strings into
binary floating-point values and back into decimal strings.
-scott
