Use anything… Mailcow or otherwise. Just don’t expose the ports on your firewall/router to connect back to you.

I have 4 seed boxes I run on pia. My only issue is that the port changes from time to time. I have to check on them every week or so. It’s also one of the only court tested Vpns, though it did change hands after that

Edit: Turns out the pia client has a bash accessible command to get the active port. And Qbittorrent has a curl-able target to set the value. One bash script and a crontab… and now I don’t ever have to deal with the port changes anymore. You’re welcome leechers!

But they don’t get as much use here

You should clarify “here” a bit more. In AZ tile roofs are EVERYWHERE.

We end up replacing the underlayment more often than the actual tiles… unless the specific type of tile is no longer made and too many cracked for whatever reason.

Why are you all getting your homes inspected?

Required by many mortgage companies when you buy a house, primarily so they know that you care about paying the mortgage. If you buy a house and it turns out the foundation is completely falling apart and a wall falls down… you might just skip your mortgage and now the bank repossess a shitty house they lost money on. Also just a good thing to do overall before you purchase a house.

Edit: It’s used primarily on the buyers side of the transaction prior to the actual purchase to validate the house is in good shape… Or oftentime to identify issues with the house that can be used to negotiate on the price a bit. Eg… someone is asking for 500k on a house and you found that the corner of the roof has some water staining on it (probably needs to be looked at). You can ask the Sellers to fix it, or negotiate the price down 2-3k based on the findings of the third part inspector.

and seeding seems to work for me.

You can only seed to people who have ports open. At least one side of the connection needs to be reachable.

It’s people like me who keep ports available that are able to seed to you.

Divorce and child custody agreements are two separate legal things and child custody agreements are thankfully not a matter of public record.

And yet I was able to pull my parents Divorce from decades ago and in those documents were details about who has rights to me… I think this is likely a state by state thing. Though my name was never directly mentioned.

Each one of these events is easily shown to have good merits for being public record. Even ignoring the obvious case of “we want to track what the police/courts were actually doing”.

Traffic accidents

Occurs in front of your property and cause some amount of damage to your stuff that officers didn’t outline in any reports. You want to be able to figure out who did it so you can send them the bill/sue them. Hiding these records doesn’t make sense. Other obvious uses would be to find out where someone went/is missing, eg if someone died.

traffic citations

You’re attempting to hire someone for a job, part of that job is some amount of driving. Being able to lookup if they have any record of driving poorly would be due diligence you’d expect a company to do. Hell getting into an Uber or Lyft… You might want to lookup your driver. You could be surprised.

bankruptcies

Hire someone to do something related to finances in your company? Or to file your taxes? Might want to actually double check they’re not idiots on their own dime either. Someone asks you for a loan, or any other financial related stuff. Records of them defaulting are important.

buying a house

Your dog ran up to me and bit me, then ran away. Being able to get the property details can be highly important.

getting divorced

Can trigger a number of things. If divorce has any kid related issues… and one parent no longer has rights to the child… Schools/doctors can validate that one parent no longer has those rights without just blindly trusting random documents one parent provides.

But editing code running on your computer should be protected as well… I’m personally pretty torn on this one. Ultimately I think that server-side is the only real answer.

Well… No offense… but duh? It’s not like OP can migrate his spouses “Spouse@gmail.com” address to his mail server.

I was under the assumption (and I could be wrong) that OP owns the domain… And wants to run their mailboxes. If she wants to keep her own mailbox and use it, just forward it to her gmail if that’s what she wants. I’m also not insinuating forcing someone into something.

I own my domain(you guessed correctly) and host my own emails. My spouse does use an inbox on my server(actually a few)… If she didn’t want to anymore she can open a mailbox where-ever she wants… and I’ll even forward whatever I get to her. That’s it. Wouldn’t stop me from running my own inbox on my own server. And I’m not forcing her to do anything at all. She can use it or not.

This is the mentality I have when I made the previous comments. Just forward her stuff off, she can go wherever she wants.

Until the basement floods and the server goes offline for a few days

That’s what backups are for.

or botched upgrade that’s failing quietly;

See above

over zealous spam assassin configuration;

That’s an assumption that you’re using this specific product.

What’s funny is you think that all of this can’t happen to your stuff on Google’s servers either for some reason… Say the wrong thing in a Youtube comment? Boom whole google profile banned. All your emails are gone too.

Or random software that interfaces poorly with each other (https://support.google.com/mail/thread/142335843/all-of-my-emails-have-disappeared-how-can-i-recover-them?hl=en)

SMTP is stupidly forgiving. You’re not going to magically lose singular emails.

But one thing is for sure, my wife won’t have any of it. She’s a total backwards thinking give me windows or I’ll jump kind of Gal.

So… forward her inbox to her personal gmail account? Keep your mail server as it was for you?

Can you provide the ruling?

As far as I understand it was simply an “agreement”. Not a legal decision/ruling. Nothing stops M$ from appealing it regardless with this new information. And pointing to MacOS and Android and asking why they’re not being enforced the same way.

And just because a current ruling OR agreement is in place. Doesn’t mean they don’t want to do it. They can easily just make the process harder for those that want Kernel access which could still have the same effect.

Games - Nah that’ll continue on as it has, some get cracked and some don’t, it is what it is.

with Crowdstrike and other considerations… M$ already wants to close kernel access to their systems. This will make most DRM ineffective. I think games in specific will become significantly easier to crack in the near future.

Especially as linux handhelds continue to catch on and do their thing.

Oftentimes that comes out of department budgets. That’s not necessarily 100% tuition funded.

Edit: meaning printer stuff… my department had our own photocopy machine. It was a department asset.

And I showed you a way that we can make it so it doesn’t matter.

Force local hash -> Hash/salt what you get. Password can be a million characters long. You’ll only ever get like 128 characters.

Nothing I talked about said to not validate inputs. Just that we don’t have to limit a persons password selection.

And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What’s your point.

The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn’t make that any less true.

Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?

Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.

If I choose to make you hash it in browser first… Then I simply don’t care do I? I can hash/salt again when I get your hash. Edit: There are other answers to the “DDOS problem” that don’t require upper bounds.

If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.

That’s not true. If they send hashed password you could salt/hash again on server if you’re trying to keep the salt “secret”. Their hash should always be the same if they’ve submitted the same password. You’d just be hashing a hash in that case… but it’s the same premise.

That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point.

That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we’re using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428…) characters. After that you’re losing data in the hashing process and by that effect it would be negligible… (There’s some wiggle room here in that we can’t type hidden ASCII characters so some passwords over 73 characters would fill those spaces… but detecting collisions is silly and non-trivial… better to just not worry about those at all.)

Extended ASCII would be same premise, just 64 characters instead of 73.

The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords… 64 characters is a good number to max out most of them. Databases don’t need to store much at all regardless of the length of your actual password. If you’re developing an app you can set the database to limit based on the algorithms you’re using. If you have no idea what the web-dev will actually use… then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords… that’s irrelevant and trivial for storage as hashes.