mjl-

i develop on linux, on various projects. i'm mostly concerned with all the tools, build scripts and tests that may read sensitive data, or accidentally destroy data. so i'm limiting access to files when working on a project with linux namespaces, using bubblewrap.

i've got a simple per-project dot file that describes the file system binds. while i'm working on a project, new terminals i open are automatically isolated to that project based on that dot file. it has very low (cognitive) overhead and integrates pretty much seamlessly. i suspect many developers have similar scripts. i looked for projects that did this some time ago, but couldn't find it. either because it's too simple to make a project about, or because i don't know how others would describe it. if anyone has pointers...

i don't limit network access (though i did experiment with logging all traffic, and automatically setting up a mitm proxy for all traffic; it wasn't convenient enough to use as regular user). there is still a whole kernel attack surface of course. though i'm mostly concerned about files being read/destroyed.

Yes, so you use multiple strings (in a single record) if you need longer values:

"first 255 bytes" "second 255 bytes" "etc"

DNS clients combine the 255-byte strings back into a single string.

DKIM records are just DNS TXT records. Do they have a limit on the size of TXT records? Or are they going out of their way to try to parse the TXT records you're adding that look like DKIM records, failing on them, and then refusing to add them?

As more mail servers use domain reputation to classify (accept/reject) incoming deliveries (helped with dmarc-like policies), messages from gmail.com will get a harder time getting delivered to mail servers they also try to deliver spam to.

This provides natural pressure for gmail to reduce their outgoing spam rate. I'm sure they do try to get outgoing spam down. Spammers are just a resourceful bunch...

Any large free email provider will have these problems. It's a reason to use your own domain for email, with your own reputation, instead of sharing your reputation with the whole world, including spammers.

Indeed it's not a great idea to rely on 3rd party services for allow/block-listing. You're giving power to those 3rd parties, and it centralizes email. Ironically, quite some people running their own mail servers use blocklists, pushing deliverability problems due to being blocklisted onto fellow self-hosters.

Another reason why it's not great to use allow/block-lists: You're passing the IP's of everyone you're communicating with to those 3rd parties.

In mox (a mail server, I'm the author), junk filtering is first done based on known good/bad reputation of the (verified) domain of the address of the sender, based on classifications made by the user (and mox helps with those classifications). That means everyone you've seen good/bad mail from before, can quickly be classified without the need to contact any allow/blocklist. For first-time senders, a bayesian content-based classification is used. That is almost always is good enough. But you can also configure blocklists. They will only be consulted as long as there isn't enough reputation for the sender. Once you've corresponded with someone a few times, the blocklist isn't used for their messages anymore.

Wondering what prompted the blog post. The recent publication of RFC 9539?

It would be interesting to hear how often the google dns servers see attempts to poison their cache. The mitigations probably prevent folks from even trying, but he numbers would be interesting.

The OARC 40 presentation PDF mentions cookies deployment is low for large operators but open source software has compliant implementations. Are large operators writing their own dns servers, but badly? I would think there wouldn't be many custom implementations, and that you would be able to detect which software nameservers are running, each with known capabilities. But from the way the numbers are presented it seems they only look at behaviour without considering software (versions).

this is a long standing problem with mailing lists. they are often configured to add a "[...]" prefix to the subject or add a footer, breaking the dkim signature. this leads some more recently updated mailing lists to always rewrite to their own "message from" header, so they control dmarc alignment for their messages.

for incoming email on mailing lists i'm subscribed to, i don't enforce the dmarc policy. i think this is what the parent post hints at. i'm not sure how easy this is to configure with the various mail server software out there. i'm also not aware how you would configure this with sieve scripts (i looked, didn't find it, but it seems like a basic case).

if you're running a mailing list, hoping for all subscribers to not enforce dmarc policy enforcement doesn't seem like a great strategy.

the forwarding case should be easier to keep working.

indeed very annoying. my understanding is they don't want to give spammers any signal whether their messages was recognized as ham or spam.

i would love some insights in how smart spammers are in actually leveraging such information. most spam seems to be hammering attempts that don't take failure feedback into account.

in my mail server, messages classified as junk keep getting temporarily rejected with a generic error message. at least the (legitimate misclassified) sender gets a delayed dsn, and finally feedback that a message wasn't received.

it seems many mail servers/services think it's more important to not give a signal to spammers than it is to give a useful signal to legitimate but misclassified users. perhaps they think their classification is really great and doesn't misclassify...

yes, this is a pain. the blocklist operators either seem to be not so good at vetting abuse reports, or cause collateral damage to get network operators to take action (while i don't like getting on a blocklist, perhaps it is having a net positive effect for the wider internet?).

i do think mail servers/services are using ip-based blocklists wrong. yes, you can use it as one of many signals. give it some more weight for first-time senders. but if you've been mailing (with spf/dkim/dmarc-authenticated messages/transactions), from an ip that suddenly gets on a blocklist, the previous positive reputation should be stronger than that blocklisting, and you should be able to keep communicating with your known correspondents (until they mark your message as spam after which future deliveries can be rejected/junked). it seems those mail servers/services cheap out and apply ip blocklists early in the smtp process. good for their system load, bad for their analysis performance.

in general, it seems even bigfreemail services are bad at using existing reputation in their ham/spam decisions. i recently switched an online webservice i made (that is about sending certain notification by email) to signups via email (like how you can signup to mailing lists: by sending an email to an address). the idea: if you send my service an email, i'm in your list of known correspondents. so the confirmation reply from my mail server (spf/dkim/dmarc-aligned) should certainly be accepted by yours (you much more opt-in do you want?). i tested with some bigfreemails, and yahoo put my reply with confirmation (that even references the original message) in the junk folder. to people who think you can't compete with bigmail: the bar isn't as high as you may think.

at least gmail.com has a dmarc policy p=none, so a failing dmarc check is not a reason to reject email. i don't think it's that common for small-scale installs to enforce dmarc policies. there are other signals to use though.

plenty of bigfreemail spam is actually sent from their network, they're an interesting target for spammers, and at least some of them put a lot of effort in preventing abuse.

> The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.

fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is.

i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled.

i used to dislike the unhelpful generic error messages for dnssec-related problems (servfail). perhaps that was holding adoption back. but extended dns errors (ede) seem to solve that, though i don't know how commonly the detailed errors make it up the stack in old software.

> providers managing and custodying keys for their customers, which is security theater

isn't that similar to providers managing/having access to the tls keys? well, dns is a bit more essential. but plain dns isn't more secure. ideally we can all only access our own keys, but that doesn't seem to be the standard.

i have been wondering how common it is for dns operators to just serve (the signed) zones that get sent in by domain owners. and if that has technical hurdles for the operators (i'm sure the reason for many domain owners is they want to outsource responsibility).

> DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed

seems like it for browsers. it seems dane for mail has a future. the alternative to dane, pki-based mta-sts, has downsides like tofu for policies and needing long-lived cachable policies, especially not great given the decentralized nature. currently, many domains have no protection for deliveries (unverified mx records & tls certs).

found this just now, interesting: https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.p... mentions tls with dane records inside. but not necessarily hopeful for dnssec, it is hard to change infrastructure. i always wonder to what extent new protocols are lobbied and their rollout preplanned vs hoping for the best.

> you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure.

i often wonder why not more "signals" about how to connect are in dns. perhaps lack of dnssec. with dnssec that becomes an option, preventing a downgrade. probably bad middleboxes that don't let certain dns requests through (a reason to encrypt). the trend seems to be https on a subdomain that serves a policy.

> Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT.

i should update my knowledge exactly on the good/bad about the dnssec trust roots. if there are good docs out there, i'm interested.

> Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.

true, it doesn't seem like we're in bad position with LE. and they keep getting better (shorter-lived certs). though perhaps we're getting a little bit reliant on this one CA.

fwiw, i live in a country where rolling out dnssec apparently had some financial incentives for providers, which apparently helped adoption: https://stats.sidnlabs.nl/en/dnssec.html adoption still growing, more than 60% of .nl domains currently dnssec-signed, and around 60% of queries are from validation resolvers.

i looked up global stats. world map + tables about current validating resolver queries: https://stats.labs.apnic.net/dnssec. and this is the graph over time of for the world: https://stats.labs.apnic.net/dnssec/XA (30% validating, don't know what the additional 10% mixed means). i did a quick search, but didn't find global stats about domains being dnssec-signed.

dnssec is not easy/simple (especially when getting into the details), but i think the contemporary dns servers make it relatively easy to enable dnssec on a zone, managing the signing themselves.

i do like the idea of being able to set up secure connections without relying on CAs.

You are correct that it is not needed for security. It is also not required for plain DANE. But it is for DANE for SMTP. The reason is interoperability.

Apparently, some DNS servers would not respond at all to requests for TLSA records (probably fixed in the software by now, but some infra may still run old software). If a sending mail server would request TLSA records, not receive a response, it would have to assume DANE _may_ be required, and abort the delivery attempt. This would lead to mail being undeliverable due to those old DNS servers. Such old DNS servers probably wouldn't be set up for DNSSEC, and with this workaround, the TLSA records wouldn't be requested, so there would be no lookup failure that blocks delivery.

See the paragraphs after the enumeration in https://datatracker.ietf.org/doc/html/rfc7672#section-2.2.2

I would also suggest https://www.email-security-scans.org/ for testing outgoing emails.

First, DANE requires that your DNS is protected with DNSSEC. Your MX records need to be DNSSEC-protected because otherwise any attacker that can give a sender fake MX records can cause an email message to be delivered to a mail server of their choice. The IP lookups to connect to your MX host needs to be DNSSEC-protected, and your TLSA records need to be DNSSEC-protected. For self-hosters, this is usually all the same domain.

Second, your MX host needs DNS records of type TLSA that specify the public keys that are in your TLS certificates that your MX host (mail server) offers during STARTTLS. This is the most common mode for DANE, called DANE-EE (EE = end entity). In this mode, only the public key of the certificate matters. Expiration, hostname match, issuing party of certificates: all ignored. If your MX target is mx.example.com, the TLSA record(s) must be under: _25._tcp.mx.example.com. They will look like this:

3 1 1 5c046ff012891b5f0d6176024c5c25ff486a7c12b8000fdf8b418ab3ecf6d309

3 1 1 cec87fb33d2a7499ca78e824e59b77531ac1fdec7378fc81fce7e5d213a364ab

In these records, "3 1 1" means:

Usage "dane-ee" (3), Selector "spki" (1), Matchtype "sha2-256" (1)

Where spki means "subject public key info", i.e. only the public key matters. So, the last component is the sha2-256 hash of the public key. A mail server can have multiple certificates (e.g. RSA and ECDSA). Each must have a TLSA record.

Keep in mind that when you renew your certificate, you could be reusing your private key or be generating a new private key. A new private key brings a new public key. A new public key requires an updated TLSA record. Keep in mind DNS TTLs in that case. You would have to keep both the old and new TLSA records during the TTL period. I would recommend you don't generate a new private key for each new certificate. If the private key stays the same, the TLSA records don't need to be changed.

MTA-STS requires that the MX host TLS certificate can be verified against the common pool of certificate authorities, i.e. PKIX/WebPKI. DANE and MTA-STS can cooexist. I would recommend setting up both DANE and MTA-STS, using ACME with Let's Encrypt with fixed private keys (not newly generated when fetching a new certificate, I know certbot has an option for this mode), and publishing TLSA records (with the hashes of the public keys of those fixed private keys).

Keep in mind some sending mail servers only implement DANE, and others only MTA-STS. Implementing both gets most protection. Some mail servers implement neither, and are sending email without protection.

To protect my email with DANE, I ended up running DNS myself. I used to be at AWS Route53. It supports DNSSEC (but quite user-unfriendly). But it does not support TLSA records (!). I'm still curious why, though Route53 is giving off a vibe of being frozen in time (a long time ago).

Anyway, modern bind or knot take care of the keying part pretty much automatically (this made DNSSEC harder in the past). Just add records to the zone file, reload zone. DNSSEC signing is automatic and changes propagated to secondaries.

I agree with you that DANE is a better solution. MTA-STS adding a webserver and HTTP libraries to email as requirement is a bit much. Also, where DANE is per MX host, MTA-STS is per recipient domain, requiring a TLS certificate for each (operationally not great when you're hosting many domains). MTA-STS also relies on mail servers keeping track of historically retrieved policies, which must be refreshed in the background. And if a first connection attempt is intercepted (falsely getting told no _mta-sts DNS record exists), there is no protection. This isn't possible with DANE.

Interesting thanks. I can imagine that an email sending service wants to be in control of message-id's (would still be interesting to hear the actual rationale).

Perhaps SMTP could use an extension with a new (pipelined) command after DATA, so a client can retrieve the assigned message-id.

I wonder how common it is for message-id's to be overwritten. I must have run into this SES behaviour (along with other problems) when trying to use it as backup for outgoing mail for my mail server: My DKIM signatures include the message-id header, overwriting the header will invalidate them.

Why would the Message-ID (that you assign) not work for this purpose? Perhaps the SNS notification doesn't include the message-id?

Pitching my own: https://github.com/mjl-/mox has a "mox localserve" subcommand that runs a mail server on localhost for testing, including a pedantic mode and special addresses that cause failure conditions you may want to test for. This is actually a full mail server (SMTP, IMAP and much more) and it comes with a webmail client. The "localserve" mode was just so easy to implement that I couldn't resist.

good point. had me looking for a transparency log for dnssec, arriving at https://www.huque.com/2014/07/30/dnssec-key-trans.html. it seems there hasn't been activity on that topic in years.

an attack would involve a tld operator being compelled to cooperate, or their signing keys being compromised (and then probably adding a DS record for your domain). if that were found out, it would be bad news for trust in dnssec. have there been any known case of this happening? it would be hard (impossible?) to fully detect without transparency log (like for ca certificates).

no, scram is all about not exchanging and not storing plain text passwords. the plus variants add tls channel binding.

you could run your own dnssec servers (not too hard). and monitor the DS records for your domain at the TLD. have there been any reported cases of law enforcement changing DNSSEC (e.g. adding a DS record)?

i agree there's probably no way to keep a machine hosted at a company secure from law enforcement. also why i suggested storage and anything in ram on the machine can be considered compromised. this attack (swapping out network connection for a while to get a certificate through let's encrypt) was probably easiest/least intrusive. if it wasn't an option, the next easiest option would be taken. perhaps the options that are harder to execute are more likely to be detected, or less likely to be worthwhile.

DANE (with DNSSEC) may be an option to look at too, with public keys in DNS. though probably client support isn't universal (i have no (recent) experience using jabber). the CA was one weak point here.

checking for new public keys in certificates when keeping private keys between renewals would also help.

i suppose any storage and possibly ram should also be considered compromised? e.g. private keys stored on disk without encryption, but also by being read into memory. especially on the vm.

i'm "underdotting" anything that has a tooltip (simple css style). most buttons have a tooltip with a sentence explaining what it does/how it works. but this is in webapps that people use relatively intensively, so they can get used to this. it's better than desktop apps that often have no indication that hovering will show a tooltip.

why? screen space. "37h" is much short than the date and time of 37 hours ago. of course, if you write out the age like "37 hours ago", that isn't as useful. software doesn't _have_ to do it badly. the most recent version of this that i wrote will say it is Xmins old, but switch to the next unit after reaching 2*next-unit worth of time, so >120mins starts at 2h. then you get to 2d, 2mo (months), 2 years. you can get the full datetime on hover. all this is only in an object listing. when you open an object, you'll see the full date.

Does anyone know of a tool that guides you with making DNS changes? Before starting it would analyze the current settings (SOA, parent/child NS, DS, DNSKEY, RRSIG, etc and their TTLs), possibly suggest reducing some TTLs, show the when you need to make which changes. Then checking along the way for each step if the changes have propagated and letting you continue with the next step when it is safe. Could be useful for DNSSEC changes, but also just changing name servers.

I moved domains to new name servers last week. I took the poor-man's approach of disabling DNSSEC during the migration. I made a step-by-step plan, verifying propagation along the way with dig. Still made one mistake, where I thought I had reduced the NS TTL in a child zone before migrating, but hadn't (it was still 2 days instead of 1 hour). An automated check would have caught it.

I think such a tool could also have shown this KSK rollover required a longer wait than the procedure had.

Does anyone know if DNSSEC-validating recursive resolvers will retry (fetch new records) if their cached DNSSEC-related records (e.g. DS) are a certain age and they are seeing a validating error?

If they would, problems could autocorrect faster (than waiting out a TTL of 1 day). It could cause higher load on name servers, but at first glance it seems like a reasonable trade off.

Interesting indeed. What kind of classification would you have in mind? Separate out different types of senders, e.g. friend groups, or professional clients? Or more the personal email, transactional email, newsletter?

For bayesian junk filtering to work, you train with messages marked either as junk or nonjunk. I suppose you could train based on positive tag, and assume the message has the opposite signal if it didn't get that tag. My historic email is only classified for (non)junk. If I would start more classifications, I would have to ignore the existing messages.

Fyi, I'm working on https://github.com/mjl-/mox, which also includes a bayesian filter. This sounds implementable.

Sieve seems not powerful enough. I had this though experiment a few days ago: What if you could run code in a sandbox on the server (javascript, webassembly?) with api's (provided by the server) to access mailboxes/messages and to take actions (move to folder, change message flags), and perhaps some networking (e.g. dns blocklist)?