Nothing for several days from the forum
(1) By doug (doug9forester) on 2021-05-13 15:14:12 [link] [source]
I have gotten nothing from the Sqlite forum since Monday. What happened? Did it go offline?
There have been a number of postings, per: https://sqlite.org/forum/forum
I've gotten a number of emails, so you may want to check your subscription information and also check your email client for overactive spam detection.
Somebody on the internet (I'm not sure who yet) has decided that SQLite.org - which is the domain from which forum email messages originate - is a spam source. Lots of email traffic to and from sqlite.org is being blocked. I don't know how to fix this.
(4) By curmudgeon on 2021-05-13 16:09:33 in reply to 1 [link] [source]
I'm the same (fossil forum also) and started a thread 'Not receiving emails' below. Today they started again out of the blue (going to junk) but it doesn't seem like they're all getting through.
let me share my version
- Online blacklist host checkers (like https://mxtoolbox.com/blacklists.aspx ) point to UCEPROTECT-Level3 list for sqlite.org ip (22.214.171.124)
- Querying sqlite.org ip at https://www.uceprotect.net/en/rblcheck.php (126.96.36.199) shows level3 listing and explanation that there are too many abuses from the ip range of sqlite.org provider AS63949 (Linode).
The page explains different details including that in this case the said ip is probably not responsible. So either the provider will naturally crosses the threshold back or will have to take some measures if the clients (mostly innocent) encourage it to do so.
In the case of UCEPROTECT you can pay them to exclude you from level 2 (allocation) or level 3 (asn) listing. See www.whitelisted.org
I used to use UCEPROTECT Level 3 lists, but they are too aggressive. Level 1 (direct spam sources) and Level 2 (allocation blocks) seem fine.
I did visit www.whitelist.org and they do list 188.8.131.52 as level-3. I suppose that means that somebody else in the 184.108.40.206/24 block is spamming. That IP address is assigned by the ISP (Linode) so there isn't much I can do to prevent this. I've had the same IP address for over 15 years.
Whitelist.org offers to exclude 220.127.116.11 from the level-2 and level-3 lists for $100 (90 CHF) for two years. But that seems like ransomware to me. ("Nice email domain you got there. It'd be a shame if somein' happened to it.")
(8) By doug (doug9forester) on 2021-05-16 00:03:21 in reply to 7 [link] [source]
I'm getting emails from the forum again. What did you do to solve the problem? Pay the ransom?
A theory of the problem:
When sqlite.org is sending email, it might send the message from either of two different IP address:
- ipv4: 18.104.22.168
- ipv6: 2600:3c00::f03c:91ff:fe96:b959
The metrics provided to me by Google Postmaster Tools show that 22.214.171.124 has the best possible "IP Reputation", but that 2600:3c00::f03c:91ff:fe96:b959 has the worst possible IP Reputation. The bad IP Reputation for 2600:3c00::f03c:91ff:fe96:b959 appears to be because Gmail is grouping all traffic from any 2600:3600:: IP address into a single pool. At least, that is what Google Postmaster Tools is telling me. It is as if they are only considering the first 32 bits of the 128-bit IP address.
I have adjusted the configuration of postfix on sqlite.org so that it now only sends email via IPv4. Perhaps this will help.
If you have alternative suggestions, please speak up.
I have made contact with the people at Gmail who tell me that they use the first 64 bits of the 128-bit IPv6 address, not the first 32-bits as reported above. Nevertheless, they do recommend that for projects that send email to Gmail from a VPS (such as a Linode, on which SQLite.org has run since 2004) should send email over IPv4, not IPv6. I thought I had done that. But apparently I didn't change the Postfix setting correctly. The correct fix is to run:
postconf -e inet_protocol=ipv4
That has now been done and the mail logs do seem to show that outbound email is now always going over IPv4. For reference, to change this back, you set the inet_protocol value to "all".
Hopefully this will resolve any lingering mail delivery problems. If you continue to have trouble, please post follow-ups.
Note that you can also request assignment of a dedicated (static) IPv6 /64 subnet from Linode rather than using the "default" IPv6 subnet assigned to the cluster (and thus other hosts). While this /64 is still assigned from the overall /32 delegation to the same Linode ASN from ARIN, it is not shared by other Linode customers.
This means that things which track access based on the network part of the IPv6 address (the /64) will see you only and not other Linode customers on this subnet -- this includes almost everything (although it is in the same ASN, only very limited DNSBL list entire ASNs, most work at the /64 (network) prefix level).
I did this way back because RIPE was returning unexpected access errors and it turns out they (and a lot of others) track by /64 and access was being impacted by other Linode customers on the shared network segment.