Was this some sort of lease to own scheme? Municipalities tend to pay very little for cash less than a leasing company. Are we surrounded by idiots with no impulse control or long term thinking to think leasing is cheaper?
To easy to be gamed, just put a flat fee to process a DMCA claim to the web site owner. That will stop the robotic spam and general harassment.
It would be bad form to reset the password when anyone clicked 'reset this accounts password' anyway. So until the link is followed, no action should be taken with regard to the account password anyway. This way a malicious person can't just denial of service a valid account by clicking 'reset my password'.
This means if an attacker is able to intercept your SMTP, they could still hijack your account through requesting a password reset at will, so it's not perfect, and yes some 2 factor authentication would be nice *if* it were an important site. Account creation needn't have this particular hole, just password reset.
If you didn't want to SMS, you could use TOTP (e.g. google authenticator is one implementation, but not the only one). Though either way that's something to potentially lose so it would be a suggestion option for those increasing security.
The UUID is discarded on first login. Additionally, the UUID is useless without the password/credentials.
The idea is that the user set his password via (presumably) secure https. The purpose of the random hash is so that you provide the legitimate email user a transient secret that must be used *in conjunction* with the password they had chosen (or some session cookie sent via https to avoid making them log in twice when clicking on the email).
So here the password is to authenticate that the original person that accesses the site, the hash authenticates a valid email account. Both together are required to verify the account is valid. This way someone intercepting SMTP doesn't get access to hijack account and someone without a valid email can't get an account activated.
If I have the option I always pick 2 actual providers and stipulate the divergent fiber paths in the contracts.
Mind you if I have my druthers I'm getting dark fiber so I can run my own C/DWDM over it in a metro setting.
L1 Protected circuits are nice and all but the CPE box that binds them make it no longer fully redundant. So you still need two of them to let you L2/L3 redundant gear work properly.
No that broke the internet 20 years ago, lets not go back. Major firewalls have no ability to NAT ipv6.
You realize that those old legacy spaces do not fall under that agreement?
Because ARIN/ICANN has about 0 authority over these old blocks, they were assigned well before all this you do not own they we can take them back to companies with enough lawyers to litigate them into oblivion (well into having to up the ICANN fee's so much people will look for an alternative like hey GE want to leave me a block).
Operating or not you still have a radioactive pile, you still have things that have been exposed to a lot of radioactive steam.
That costs money, A basic requirement of N+1 redundancy where N is any shared hardware or physical path or capacity. It's pretty trivial to technically to route around this sort of thing it's a significant cost to install diverse routes, buy redundant gear etc etc.
I just turned up a pair of divergent 10ge metro e links. The vendor terminated both of them on the same CPE gear. So with divergent entrances etc etc etc they literally hopped the fiber from entrance A telco room to entrance B telco room to reuse the CPE switch. Telcos are great at trying to save a buck (the CPE gear is probably a month maybe two MRC) while failing to make things reliable.
Or you could just fsking engineer them so you do not need to shutdown the plant to do normal maintenance.
eth0 being renamed to biosdevname and then 'consistent' device naming happened outside of systemd per se. It's one of the various questionable things that came along at about the same time as systemd, and systemd gets the blame for *all* of them, when it only brought some of it. E.g. complaining about binary logs, you can aim that square at systemd. Most of the other prominent rants commonly fired at systemd are either dbus, networkmanager, udev, or something else in reality.
The network device naming is one facet where they can't win. The ethX has problems, and so does the current state of consistent device naming (notably that if an adapter veers off into being enumerated by pci, it's probably a lost cause in all but the most extremely homogenous environment and doing those names is just causing more trouble than helping)
I agree that Torvalds isn't the authoritative god of all that makes up a distribution and as such his opinion is one to be considered, but no the only one.
Also he speaks to the biggest fundamental controversy, the log strategy/format. I agree with Torvalds, that the capabilities of systemd are interesting, but I personally find the bathwater that comes with it troublesome enough to not want it. That and how they engage with the community at times. A lot of the other gripes about systemd are more implementation mistakes that are unintended and often addresed, but this part is very explicitly intentional and counter arguments have been dismissed out of hand.
Sometimes you don't have a choice in an interoperable piece of software. In an aggresive world that tosses away backwards compat in the name of security, you'd either have to toss out a bunch of perfectly ok equipment because you *can't* talk to it anymore, or stick to outdated software to protect the investment, which may have unfixed vulnerabilities because the versions that fix things also dropped support for your needs.