vgb2k18

Block-resistant and censorship-resistant are terminology I've seen used in other projects. I agree that ublockable and uncensorable are hard phrases to sell here, they kind of immediately beg to be challenged.

Rhinoplasty / the cosmetic surgery industry depends on cartilage from cadavers in some countries. In other countries cadaver cartilage is avoided due to the potential for reabsorbing and degrading in the patient's body, and therefore cartilage can be taken from the patient's own ribs. I'm not sure if this specific breakthrough in the article would be suitable for shaping the nose permanently. But last time I checked (10 years ago), there was a specific need for synthetic cartilage to improve patient outcomes.

YouTube Rewind <--- an annual video event with some of the highest dislike counts in the history of the platform. I feel like the timing on YouTube's decision here is suspiciously convenient.

> they still feel usable after 6 months of use. By this time, most of the context that I learned to develop the project has faded away and I have to rely on the documentation that I left myself.

This was a much-needed reminder that the target audience for my documentation is my future-self.

Adding: [-] whitelist allowed ip's for port 22. Requires static ip's client-side obviously [-] fail2ban if static ip's are not available.

> Gemini is designed to be difficult to extend without breaking backwards compatibility, and almost all proposals for expansion on the mailing list are ultimately shot down.

This could lead to some interesting adaptations. I'm thinking like the way usenet, news-groups were adapted to store and transmit binary files in the form of NZB's. So while the underlying protocol remains pure and simplistic (relatively), the overlays and adaptations build upon it may bring unweildly levels of complexity. Not inherently good or bad, but interesting to think about.

> I may be getting over my head here)

It may be so, however my own need for clarification was the same as yours. If ISP xyz operates a /16 ip block, and only forwards source packets from its /16... Then, I guess, my question: how do spoofed packers usually travel past their first hops on their route to the target?

[edit] after-thought: I imagine attackers might easily spoof their source as any of their ISPs /16 or /8. Feels like that's not entire story here though.

> The vulnerability was fixed [...] by adding size checks for the name and value lengths.

Would it make sense in this case to review the entire codebase for valid size checks? Genuinely curious. Not interested in debating one language VS another this time, merely, the best practices for the language specific to this codebase.

I'll agree and add one example: from a repeated sequence of played notes, and a repeated sequence of flashing colors - I can readily identify a modified note, however not a modified color. For context imagagine 10 seconds of a song VS 10 seconds of flashing lights... If on the 3rd repetition of the pattern, one random note was changed and one random color was changed, which change would be most immediately obvious?

>Another tip for domains that don't send email: set a null mx record. This explicitly tells sending servers that your domain does not receive mail...

Most of my domains don't send mail, however I do prefer to receive mail to the standard aliases (webmaster@, abuse@, etc) and often a catchall. Even for domains I've got parked and awaiting deployment.

Am I thinking too much, not enough, or is the opening phrase of the advice meant to be "Another tip for domains that don't intend to receive email"?

Oh boy, thanks for the detail, love it. You've probably been more fortunate than you can appreciate for now. I mean, I've not yet had a DO IP which wasn't listed blocked by SNDS (Outlook private block-lists): https://sendersupport.olc.protection.outlook.com/snds/ipStat...

Would be interested to hear from others who've acquired new DO IPs that weren't blocked on that list though. Change my view of the whole scenario.

> I’m setting up new domains routinely and Outlook works fine. Even with cheap / free domains.

You say domains

To ensure we're speaking to, not past, each other it will be essential to clarify one thing: what do you mean precisely by "setting up new domains", "cheap/ free domains"?

Domains, I'm not interested in chatting about those, but IP address space, then yes I'm all ears. If you can reliably setup new, fully self-hosted mail servers (i.e., not using SendGrid, MailGun etc), with port 25 open for both send and receive, on cheap, accessible VPS servers...

And...

Send email messages from those new servers directly to your Outlook's inbox.

Then you Good Sir, have the secret sauce.

*Caveat: AWS does have a lot of un-blacklisted IP address space, however, port 25 remains blocked for new customers without a "valid use-case" and an unspecified amount of payment history. Similar for Azure. So if your methodology is built around AWS/Azure then kudos, but for new-comers, it would be unrealistic from my experience to suggest the path forward will be without major hurdles and/or delays.

The lack of verbose feedback in the rejection reason from Outlook was, as I see it, a feature not a bug. A bit of friction to turn away the undetermined ones. I followed the trail of clues from the top search results of the error message and eventually got my new IP unblocked through the proper channel. So... I have made it from bottom tier (outright rejection of emails), to 2nd-bottom tier (directly to spam/junk folder). Next: build domain/ip reputation ever so slowly.

Not a full answer but a partial from the other side of the fence: setting up my website and domain-name to send emails fully self-hosted - I finished setting up DKIM, DMARC and SFP on my brand-new, not-publicly-blacklisted IP address, and finally... Time to send some test emails out. Results:

[-] Outlook rejected my emails: vague reason given, but the fact is, Outlook rejects entire IP address allocations (for example, DigialOcean's entire VPS network), even individual DigitalOcean IPs which aren't publicly blacklisted. There is a proper process in-place for small upstarts like myself to get de-listed, but its not a given right that the process will favor the applicant.

[-] Gmail. Email received. No problem, no spam label. And I'm quite thankful to Google/Gmail for accepting my mail based on metrics other than IP addresses alone.

So while I can't answer why they're allowing obvious spam through their filter, I can say that at the present moment they are not as ruthless in blocking /16 networks (or whatever size) as some providers based on IP addresses alone (e.g., Outlook, E365).

> That's it. Now your mailer should work.

Work... technically... yes. If the definition of 'works' is: "I press send and sometimes my email reaches it's destination".

The spirit of the article IMO implies a definition akin to "I press send and my email reaches it's destination. And... my emails have some protection against spoofing attacks".

So in the spirit of the article, I would recommend your 1-liner takes a small yet significant change:

v=spf1 include:example.com -all

Now... let's talk about biggest barrier to entry for n00bs (myself included) in the self-hosted email game: non-blacklisted ip-address space. And blacklist here refers not just to public lists (SPAMHAUS etc) but private ones too (e.g., outlook).

> Months later, he noticed something strange. “It was just blowing up,” he said. “I don’t know why. The views just kept climbing and climbing and climbing.” Soon there were spin-offs.

Other than "It went viral" or "because the YouTube algorithm", was there a specific reason ever noted for this? I found this part of the article was the hook that got me interested in reading more, however I didn't find the answer further down.

Visually the first 4 letters do look like rape, r@pe x.com. Rat x would be uncommon since there is no ‘t’ to be seen there, and phoentically its a long R, sounds like “are at pecks dot com”. From a marketing perspective I’d consider changing it just because of the negative connotations the word r@pe elicits in the mind. But if it’s personal email address then not much reason to consider my opinion at all.

P.s., if it is a personal email, please do disregard my message, and feel free to in return critique my own username: vgb2k18, it’s an acronym for very good boy 2018.

Dynadot.com, they've been around a long time, for me it's been the provider I always come back to.

Only one I found was the owner's website which has some examples... https://24a2.routley.io/

I read further up [1] that Pi-Hole auth is http not https, so if you cracked the WiFi aready, sniffing the webadmin password might yield a quicker return than brute-forcing (depending on strength of password, and owner's login frequency). Assuming the maximum password length of PiHoles is not < 20 chars.

[1] https://news.ycombinator.com/item?id=22717938

Meizu phone, Flyme UI. Equally as Chinese as the Huawei you mentioned, so your point stands. Whether or not a tranlation error though, the GP had never heard of anyone using 'password' in the context of a numeric pincode, but it does happen. Who knows, I could be biased through my repeated exposures to the Meizu lock-screen, but as a native English speaker I don't have a hard time imagining a numeric-only pin being referred to as a password.

> I've never heard a person refer to a short series of numbers used to protect something as a password and not a pin.

Until today... Screenshot from Android phone - https://ibb.co/KD27YGL