What's the point of this article? The most I got was "email is here to stay," followed by some discussion of an MCP server for their proprietary mail platform.
I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through generations of sysadmins, yet I read so many documents and articles that make it sound like a proprietary trade secret that the authors of such articles are graciously revealing to the world.
Agreed. I had some vague hope that this article made it to the HN hope page because someone was saying what needs to be said: that the future of email should be protocols over platforms, as it was in the past. Mail servers and mail clients.
Yeah, it's the same thing with self-hosting email. The technical side is documented and the tradeoffs are well known. It's the up front effort of migration, maintenance and mails landing in spam that gets people down and so on. Though once you get going it's supposed to become easier with time.
Also there's a spectrum from Gmail to Fastmail to AWS SES to Wireguard on a VPS that's tunneling to a server running at home. And when the people from both extremes of the spectrum interact they look at each other as if they're from other planets.
It's the same for Auth stuff I believe, almost a decade of generic advice like "don't roll your own auth" has lead some people to file it into a tidy corner of their mind labelled "DON'T TOUCH" so most people end up gawking and staring in awe when someone does so and lose all nuance along the way. To be clear I'm advocating for learning how stuff works and playing around with it (time permitting) instead of simply delegating it to the technical equivalent of Higher Powers in perpetuity.
Same - I plugged it into ChatGPT to check if I'd missed something contentful. I hadn't really. Not news, more survey of things that matter a bit. If you know those things already then this is just fluff. Nothing about the future, more just here's some things I like.
I'll tell you right now, I've had multiple cases where I've had to quote parts of the RFCs to large companies because they were handling email authentication incorrectly.
They are wildly misunderstood. The moment I see "add this include: directive to your SPF record" in some marketing platform's integration documentation I know they're going to fuck something up.
To add-on, the really pro move is to not touch the client's SPF record at all. Use your own domain in the SMTP envelope and have SPF be valid for that. Just have the client establish DKIM records and use DKIM, and only DKIM, to pass DMARC.
If you insist on using the client domain in the envelope, make it a subdomain with MX records back to your infrastructure (so you can track bounces). That will pass relaxed alignment - or just use a subdomain in the from and now you're passing strict alignment as well.
Most companies have no idea how the envelope domain impacts bounces and frankly, doesn't care about tracking them.
A shockingly high number of companies have no idea of the concept of the envelope address.
I wouldn't recommend for your own mental stability to look at /r/sysadmin when it comes to any sort of DNS or E-Mail issues. It really shows just how many bad systems administrators there are out there, who do not have a basic understanding of the systems they're using.
Just a few years ago, Atlassian required you to add an unnecessary include: record to your SPF record, and wouldn't use your domain for emails until they scanned your SPF record for that include. https://jira.atlassian.com/browse/AX-1477
You'd think companies generating as much email as Atlassian would know what they're doing.
I was going to say the same thing. I only saw two things that are sort of about the future and not the past:
- BIMI (I hadn't heard of that before) which seems like a very minor thing to be calling "the future of email"
- AI might be easier to trick that humans
On that second point, here's the exact text:
> A person reading a suspicious email might notice that the sender’s domain has an extra character, or that something about the request feels off. An AI assistant scanning your inbox for items that need action may not slow down to check those things.
That seems wrong (AI should be better at this than the average human), but let's assume that assertion is correct. It then says "authentication is the safeguard that should stop it before it ever reaches your mailbox". Except then, a few paragraphs down, it says "A scammer with a convincing look-alike domain and a properly configured DMARC record will still pass sender authentication checks." Ok, so authentication isn't a solution to the stated problem at all (it does solve a different problem). And unless I'm missing something, no solution is proposed. No statement is made about what the future actually looks like.
Lookalike domains are a problem but in my opinion the bigger problem is when attackers figure out how to hijack a real domain.
For example, making a company named "there's a problem with your account call this number" on a site like PayPal and getting it to generate emails. They'll be from actual paypal.com and pass all authentication.
The other issue I'll often see is subdomain takeovers. Company makes a subdomain a CNAME to some other, external domain. Usually with the intention of hosting a webpage externally or whatever.
That other domain expires, but the CNAME doesn't. Somebody buys up the external domain, now they can publish SPF records and pass DMARC relaxed alignment on the organizational domain.
Now you can send all the emails you want with literally anything you'd like and the providers will say "yep, this passed DMARC."
I, too, get so frustrated by + addresses not working that I’ve configured my MDA to rewrite —- (double hyphen) to plus, and use this in spite on sites that dislike the + variant. I’ve made it impossible to /not/ host my own mail delivery infrastructure now if I want every address I’ve ever given out to still work.
Although more recently I’ve moved to a catch all domain for throwaway, which is even better. It confuses agents on the phone though when I give my email address as {their company name}@mydomain.com
Yeah, most people don’t understand how the ownership and control varies before and after the @ symbol.
The best one was when someone said they were going to give me excellent service because “you work for corporate”, confusing the company name before vs. after the @ sign. I forget which company it was now but the agent was convinced I must be someone important.
I was torn between explaining and letting them believe it :-)
Most of the time, folks just don’t understand why their company name is in the address and they think it’s a mistake.
To be honest, I do tend to avoid this for anything other than throwaways because it causes too much confusion when I have to phone up, and I’m not really doing it out of a misguided belief it helps with spam (at least, it doesn’t help any more than security by obscurity is unsuitable as a singular defence, but maybe has a tiny role when layered into a broader strategy…)
I find it's convenient for knowing which companies have immediately - and illegally, in this country - sold my details on to third-party spammers. Makes it easy not to do business with them.
maybe i can write a whatthreewords style "email identity mapper" so you put in "walmart.com" and it spits out "busybee223@example.com" and "autozone rewards" yields "Horserider184@example.com"
then if you start getting spammed, you use the w3w style thing to reverse it and see what site/entity sold your email...
then all of the "this doesn't/won't work because they'll just spam the entire domain" arguments go away, the "no, your email address" style comments go away...
one wouldn't have to remember. if the address you gave out using the w3w-style encoder starts getting spammed, you can reverse it with the w3w-style decoder.
you'd need an app or a mnemonic device of some sort if you wanted to give an email out in public as opposed to sitting at a computer. but ideally on the computer when you notice spam you just reverse the email address back to who you gave it to; "target.com", "kroger.com"
People are still doing that? To prevent spam? To "catch" the company leaking/selling your address? Now the spammers know they can likely use anything@domain, and it'll get to your eyeballs in some capacity. Also, companies have no shame anymore, they don't care if you know.
Rather than whitelisting simply on a given sender, you can rely on both the sender and the recipient address matching a known list. This needn't be a single sender address. If you have multiple contacts at a domain, or a given entity relies on several email services (e.g., direct personal email, vendor-based marketing emails, vendor-based support or notification services), you could add all of these to the "from" match set.
I'm thinking through phone comms presently and am considering a similar concept for mitigating ever-growing phone abuse. Running a VOIP/PBX system, having multiple internal, non-public "extensions", each of which is valid for only a small subset of caller numbers. The "extension" space could be large (6--9 digits, say, millons to billions of values), making exhaustive search / coincidental match infeasible.
(This is only one of a few approaches I'm thinking of, it happens to resemble the specific email practice being discussed.)
I started doing it when so many sites had broken + aliasing stuff, which I use for filing mail to keep my inbox manageable and actionable, as it was easier to type than my double-hyphen hack described above.
I’m not concerned about the leaking as my address is out there anyway and Bayesian spam filtering is still decent enough, but as an aside, I have had two companies this year whose user databases must have been leaked on the basis of spam received at company-specific addresses. I reported it to their privacy people and pointed out it’s highly unlikely this “spam” originated as their (tiny company name) being chosen by chance by a spammer who figured out my catch all domain.
They never replied, and I probably should have followed up with the local information regulatory commission in each case. Hopefully, my note helped them identify they had a leak and to secure their systems.
In practice they don't do that, apart from spamming few addresses like office@ or accounting@. If some address starts getting spam I reject everything sent to it. For addresses that are getting spam but needs to be public (like contact addresses on website) I do more aggressive filtering (eg. I noticed that enforcing that recipient is actually present in To/Cc header cuts down a lot of spam).
I do but mostly for coordination and comms sharing with my spouse by using group aliases. Summer camp registration, school nurse contact info, car insurance, library holds...all super convenient to get joint notifications for things. And yeah, also to remember who we gave contact info to which we can drop if it gets spammy.
Look up email alias service or something similar, if you aren't looking to self host. I can't recommend the service I use, because I'm grandfathered in to my plan, and their current plans for new customers suck, but there's enough providers out there that you should find something competitive.
If you want to 'self host' on a provider, I thing cheap/free options are available from cloudflare, Google, and similar enterprise companies.
If you want to truly self host, I don't have experience, but this guy who does gave a great thorough answer for those who are interested: https://news.ycombinator.com/item?id=48073510
How do you deal with sending emails? When I was self hosting my emails would be flagged by Gmail (or any other email providers) so I effectively only had a self hosted inbox, which sucks
Dont use a random IP to host? I use fastmail, even though they're trying to convince me that I need to pay ~$45 now instead of $5/year.
And they sent me an email explaining how grateful I should be, that I'm grandfathered in to being able to use my own domain on a "plan" they dont even offer., in a plan that didn't offer custom domains.
Well how'd I get all that then? I signed up for fastmail explicitly because $5/yr for custom domains.
Anyhow if you pay a host you're probably fine. Or find someone with an old /24 thats had a /31 or /32 unused for a long while, and no other black marks against the /24. And use that IP, set up demarc and all the other new email DNS stuff.
I migrated from Fastmail to Runbox in 2017, having been a customer with the former for four years, after I filed a ticket and the Fastmail CEO responded with such obnoxious belligerence that I swore off doing business with Bron or his company ever again.
The ticket began with a question about whether they'd be willing to change the way their WebDAV server handles query strings (by just ignoring them—versus returning 404, as it was doing at the time). The CEO subtly reframed the conversation as if I was accusing them of not following the standards. I wasn't. Git utterly screwed up how it does content negotiation. The change on their end would have made it easier to upload content into the file storage/web hosting space included with all plans[1] using git instead of a dedicated, conventional WebDAV client or the flaky support built into nautilus. I explained that I had originally planned to write a blog post about another one of the benefits of a Fastmail account, but the smugness and passive aggression of Bron's subsequent response—"Oh good. We don't want that," and his likening the use of git to push your static site to Fastmail's web hosting as akin to abusing DNS to tunnel arbitrary IPv4 data (wat)—and the general intellectual dishonesty I'd run into over the years seeing them respond to criticism e.g. here on HN, along with the fact that my plan was up for renewal in a month made the choice not to renew (and to try to dissuade others from giving their money to jerks) an easy one.
I switched to a different provider the next month, ended up saving money, and have only ever been met with warmth and kindness in the interactions I've had since switching, which is now going on 10 years ago.
My setup is more complicated than it needs to be for $reasons (I like playing with networking protocols, have my own v6 prefix and ASN etc. and my mail and other important personal services are hosted across multiple sites for redundancy), but any competent VPS host that offers you a static IP - coupled with some DKIM, SPF and DMARC configuration that will take an afternoon - should solve the problem. I rarely touch my home setup and it works fine; mail doesn’t go to reputation black holes and it’s been like this (literally) for decades. I invest in architectural tweaks and improvements perhaps every 5 years.
I do run similar infrastructure professionally for a living, which probably helps with getting it right first time. Competent VPS hosts care about IP reputation for mail; e.g. Hetzner only allows outbound port 25 for “trusted” customers, which somewhat helps with abuse reports. Some hosting providers may even let you relay via their own outbound hosts if you have a VPS with them, which simplifies the operational aspect.
I rarely need to send from the catch all address, but Postfix can easily be configured to allow my user to send from other addresses, and then it’s just a case of adding as an alias in your mail user agent.
I was worried about not being able to send emails, but is seems that as long as you setup properly SPF/DKIM/DMARC you're fine. You may have problems if using a domestic address though.
For the configuration, the best bet is probably to use a product that makes it easy to configure the above three, there are a few alternatives around, like Stalwart [1] or docker-mailserver (which is little more that your postfix/dovecot/rspam combo packaged in a container) [2]
Been wanting to do something similar my only hang up is coming up with a domain they wont butcher. When I got my passport I guess it must be OCR but they butchered my email completely.
Or, even easier, just make the call idempotent. The user doesn’t know anything and doesn’t have extra clicks, and it doesn’t matter much if the mail client actually did the “confirming” given it’s proven the email address is valid at that point.
The token was recently used? No problem! Must be a duplicate click, or a refresh, or the user left the browser tab open and their mobile device refreshed when they reopened the browser app, etc.
> you are by definition moving _away_ from single point-of-failure
Depends on the frame of reference of “single point-of-failure”.
In the context of technical SPOFs, sure. It’s a distributed system across multiple geographies and failure domains to mitigate disaster in the event any one of those failure domains, well, fails.
It doesn’t fix that technology is operated by humans who form part of the sociotechnical system and build their own feedback loops (whose failures may not be, in fact are likely not going to be, independent events).
SPOFs also need to contemplate the resilience and independence of the operators of the system from the managing organisation. There is one company that bears accountability for operating CF infra. The pressures, headwinds, policies and culture of that organisation can still influence a failure in their supposedly fully distributed and immune system.
For most people hosting behind Cloudflare probably makes sense. But you need to understand what you’re giving up in doing so, or what you’re sacrificing in that process. For others, this will lead to a decision _not_ to use them and that’s also okay.
Turns out most of the human population do not understand the difference between the local part and the domain part. I’ve had this too. They ask if I work there because I have store.name@myname.com. No , go and read the RFCs…
I have often wondered why we don’t see more usage of the brand gTLDs, which many of these big firms own. I muse that this is (part of) the reason why – there simply isn’t the understanding or recognition outside tech circles (or even within tech circles) to comprehend that it is possible to use such a gTLD without a conventional .com or similar suffix tacked on the end. I tend to see it localised to use for marketing micro sites that do not ask for credentials so have no need to establish user trust, or occasionally internal technical uses that will never touch the typical customer’s eyeballs.
The other reason I hypothesise is that corporate big brother snooping systems that have whitelists for their trusted services – with entries like mail.google.com or calendar.google.com – are simply too painful at this point for big tech to break for their customers by dropping the .com suffix, so big tech doesn’t bother.
I don't think you can put cookies on a TLD. So if Google used mail.google and calendar.google , the login system would be more complex, because they can't share cookies.
Modern auth systems do not work by exposing multiple services on a single domain with shared cookies.
Instead, they authenticate using a common auth service (say, auth.google), which by virtue of being a single domain can persist shared cookies for all its consumers. This would yield a valid token (possibly a JWT) that the authenticating application can then use however it would like, including as a cookie on the application's own domain.
Whenever you go to a service that temporarily sends you to a different login domain (often just immediately redirection you back), this is why.
I created a separate Chrome profile, and logged in to gmail. Then I disabled javascript, then deleted all my google.com cookies (but left my mail.google.com cookies). Then I reenabled javascript and visited mail.google.com again. I was logged out. So Google is using the google.com cookies.
It's one of the few pieces of software I bought a licence for, rather than tolerate free tiers or simply not use it, because I approve of the licensing model.
Teslas have a large driver base (note, likely doesn't apply to this forum) who don't know good engineering or design when they see it. They confuse "I spent good money on this" with "this is a good product".
Sorry, we all have our opinions and perspective, but money isn't the only value judgement.
I want my speedo in my easy line of vision on any vehicle I drive. I want to be able to demist my windscreen by reaching for a button I can find without taking my eyes off the road.
I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through generations of sysadmins, yet I read so many documents and articles that make it sound like a proprietary trade secret that the authors of such articles are graciously revealing to the world.
reply