Re: [mailop] too many bad IP blocked
On 2024-06-20 17:20, Jeff Pang via mailop wrote: today I clear up iptables rules, and run fail2ban again. in half of an hour, it blocked 1400+ IPs. $ sudo iptables -L -n|grep DROP|wc -l 1407 I am afraid too many iptables will slow down the performance of systems. do you have any suggestion for handling this case? use the iptables hashtable or migrate to nftables and use a similar technique ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Off-Topic - VMWare ESXI 7.0
On 2024-04-15 22:47, Bruno Flückiger via mailop wrote: On 15.04.2024 22:40, Kevin A. McGrail via mailop wrote: Hi All, We have four servers where we can't retrieve our free ESXi VMWare license after Broadcom shut things down and they are in evaluation mode for about 30 more days. Similar products are Microsoft Hyper-V, Oracle Linux Virtualization Manager (OLVM), Proxmox and Nutanix. Each one of these products has some shortcommings compared to VMware. If you don't need a GUI to manage your virtual environment you might consider using KVM (Linux) or bhyve (FreeBSD) as hypervisor. What sort of shortcomings do you see for, say, Proxmox? I would say that by using Open vSwitch & Free Range Routing (with EVPN), one can get pretty close to the VMware NSX. And with enabling Ceph on Proxmox, one can get the VSan-like functional distributed/block storage. Then throw Ansible at it for automation. And Prometheus/Grafana for monitoring/observability. At work we are currently building a PoC with OLVM as we have Oracle licenses anyway. And because OVLM is the one product that comes closest to the feature set of VMware we need. But I still hope we find a way forward with VMware. Moving everything to Oracle gives me nightmares. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On 2020-01-26 11:32 a.m., Andrew C Aitchison via mailop wrote: On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote: Similar thing happened to me recently when I wanted to re-login to one of those test accounts from my home computer, but I installed a new browser which was not yet used with that account. Usually there are no problems in such a case, but my home Internet connection just went down that day and I had to switch to a backup connection via cellular modem. Probably because of IP address belonging to a generally-accessible mobile operator's pool, Google behaved differently when I logged in to the account. After I already provided a correct password, Google demanded from me to enter a phone number that can be used for verification (!) and I couldn't successfully complete the login procedure, because I didn't want to associate any phone number with that account. Hmm. Proving that you can read a text sent to a number you provide today does not prove that you are the person who used the ID and password yesterday. So they demand you provide a new verification channel so that you can prove your ID *next* time ? I find these multi-factor verifications unsettling because it takes a significant effort to convince myself that the verification does indeed prove what it is supposed to prove and that it is safe from man-in-the-middle. I have lost enough physical keys over the years to worry about what happens if I lose my phone (which does not have a finger print reader) .. I get the feeling this convoluted mechanism with no safe-guards or way-out is less about verification and much more about tracking. Now I just wish there is a mechanism to just delete the account that I can no longer get into. Now it is lost to la-la land. I am who I am, and my email and authentication codes prove it. Why the continuing demand for further verification which no longer exist? Hidden in the recovery mechanism is a statement saying is that someone 'may' look into it, given an email address. Does that actually happen? Or is that just another add-on to their tracking toolings? Frustrated with the inhuman machine, Raymond. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..
On 2020-01-23 11:17 a.m., Cal Frye via mailop wrote: Once a gentleman on the west coast used my gmail address as his iTunes account email. Not sure what was in his head, but he insisted that would work just fine, and wouldn't fix it (for a couple of weeks). So I changed his iTunes password and locked his phone. Problem got resolved very quickly after that. On an almost related tangent, I wish I could figure out how to deal with Google/Youtube. I had not logged into Youtube in a long while (using this email address). I moved, changed phone numbers, changed computers. I went to log into Youtube, and Google says my device is unknown, and wants to send a confirming text to a telephone number I no longer have. The email confirmation methods all work, and validate my account. Yet Google persists in requiring a confirmation of a no-longer owned phone number. As remediation, Google suggests that I might create a new account. Of what value is that, when all the content I uploaded is in my already existing account? Is that a remnant of their 'tracking' or is that a plausible mechanism of protection? There doesn't appear to be any alternate mechanism for accessing that account. Cal Frye John Levine via mailop wrote on 1/22/20 11:31 PM: In article you write: This type of thing is depressingly common for addresses that are common names and such at the major providers. ... No kidding. You would not believe (well, you, Brandom sure would) how many people with names similar to mine believe that my address john.lev...@gmail.com is their address. I get all sorts of rather personal stuff, offers of work for a psychiatrist in Boston, wedding invitations and tax documents for a druggist in Paris, car repair appointments for a guy in Phoenix. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop