Yesterday I received a new thermometer for my aquarium to replace an old broken one. Both were bluetooth, but different models. I just told claude "I'm going to set up up my new bluetooth thermometer for my fish tank in a few minutes, keep an eye out for it and replace the old broken one with it in Home Assistant" and then walked away and put a battery in it and put it in my aquarium.

When I came back it had found it, replaced all my existing entities for the broken one with the new one, and verified it was all working with my existing graphs and automations.

  @ IN MX 0 .

They don't seem to know or care what is going on with their own email systems.

Comments URL: https://news.ycombinator.com/item?id=48634958

Points: 1

# Comments: 0

https://gitlab.com/grepular/foxcage - Runs Firefox inside podman to isolate it from the host. Has some interesting features that I wanted and nothing else gave me.

https://gitlab.com/grepular/claude-sandbox - Yet another Claude sandbox. Runs it inside podman again. Has a pretty powerful proxy system for securing your credentials.

Currently working on a tool for sanitising email. Will be blogging it up at https://www.grepular.com/blog/ when it's ready for others to use. Does things like applying policies to html/svg/calendar/vcard parts to whitelist or blacklist tags/attributes/css/url schemas, clean URLs, fetch remote content at delivery time and attaching to the email to prevent tracking, pgp and smime auto encryption/decryption and a million other features.

RFC 2142 mailbox names (the core list):

postmaster@ — required by RFC 5321; mail systems expect it to always work abuse@ — for reporting spam/misuse hostmaster@ — DNS issues webmaster@ — website issues noc@ — network operations security@ — security/vulnerability reports info@, marketing@, sales@, support@ — business functions

TLS/certificate validation addresses (RFC 8552 / CA-Browser Forum):

admin@, administrator@ ssladmin@, ssladministrator@, sysadmin@ These can be used to validate domain control and issue certificates, so handing them to a random user is a real security risk.

Common automated/system senders people impersonate or that cause confusion:

noreply@, no-reply@, donotreply@ mailer-daemon@ — bounce messages (RFC 5321 sender) root@, daemon@, bin@, sys@ — Unix-style system accounts null@, devnull@

Brand/trust-sensitive ones worth blocking too:

billing@, accounts@, payments@ help@, contact@, service@ legal@, privacy@, dmca@ register@, registration@, signup@ The service's own name (e.g. [brand]@, team@, staff@, official@)

[edit] Re the TLS issue. You should set up a CAA DNS record and also check on crt.sh later to see if anybody managed to get a cert for rootshell.is if you didn't lock down the validation addresses

Your MX TLS configuration supports various anon ciphers. These should be disabled.

Your DANE is broken. Try any of a number of freely available online validators.