Spammers who just blast stuff out won't do it, I'm sure.
But as a counterpoint it literally happened to me to me years ago when I used to use name+<service>@exmaple.com. I got cold emails to 'name+paypal' despite never, ever having used that localpart. I've no doubt it was absolutely targetted and not a hit-and-hope spamblast but it was enough of a wake-up call for me to realise it couldn't really be relied on.
I’ve been doing this for years and have never had any problems with it. It is more likely that generic emails will be generated if you have a domain that is also present as a public website on the internet.
Why would they want to spend effort trying to brute-force addresses to show me emails that they already have the ability to sent to me and I didn't generate them any revenue from?
No idea, just pointing out it is such an obvious alg it doesn't really show provenance.
I used similar (well, plus addressing with localpart=name+<service>) a long time ago and once got emails to name+paypal@example.com even though that was a suffix I'd never used. Some enterprising person out there had obviously obtained one or more of my service-specific addresses and was trying to game my attention by changing the identifier to something 'important'. That's when I personally ditched the approach.
"Provenance" might be have been a bit too strong; maybe I should have said "strong signal". It's an additional piece of info that will almost always identify the source, but in the rare exceptions it's not any worse than if I just used a single address for anything.
Needs your API key as it needs to access the email forwarding service which you want to use with it.
It's not just making up a bullshit address, it's generating a random localpart then going to the email forwarding service you've integrated and having that service create an email forward to your real address per whatever settings you have there.
Any email sent to the address it generates (signup confirmations, password resets etc) need to get to you, after all.
This design is completely different to using <business>@example.com. The latter is kind of useful for your use of 'who has sold my address' but has privacy drawbacks this design doesn't. e.g. if a spammer gets bestbuy@exmaple.com they know you prob also have twitter@exmaple.com, facebook@exmaple.com or whatever else and it's all just the same guy with the same inbox.
Truly 'random' addresses at generic forwarding services means that if Ashley Maddison gets breached again then your secret remains safe. sj4h3bd@forwarder.net could be anyone.
> It's not just making up a bullshit address, it's generating a random localpart then going to the email forwarding service you've integrated and having that service create an email forward to your real address per whatever settings you have there.
Fair enough - the one I use automatically creates an alias whenever it receives an email at the relevant domain so there's no need to manually create one, I assumed the other services were the same.
Can someone with more knowledge on this subject explain if there's a technical reason Cloudflare can't 'properly' MITM the inbound email.
That is you have your MX records pointing to `mx.example.com` in your example.com zone config, and enable the Cloudflare proxying of it (usual orange cloud in the UI).
Now, once it's proxied, Cloudflare returns the IP of their mailserver instead of yours on public lookup, just as they do when returing the IP of a proxied webserver.
So this Cloudflare MX server gets your mail, and then as it knows your 'real' MX server it connects to that server and delivers it to you, maybe adding some header or other on the way.
I don't like the fact they use bog-standard forwarding as it necessitates messing with your SPF records, getting crazy forwarding headers and having to navigate ARC etc.
There just seems to be a cleverer way to do this than just do what everyone else does, and they're generally ahead of the curve technically. Must be something I'm missing.
> Cloudflare can't 'properly' MITM the inbound email.
Define 'properly'.
It's a bog-standard forwarding specifically because this is the only way to have to separate systems to operate.
Gmail doesn't know what `yourdomain.tld`[0] is yours and what if it receives anyhting to *@yourdomain.tld it should route it to yourmailboxname@gmail.com.
If you don't point yourdomain.tld MX records to Cloudflare then Cloudflare would never receive anything to @yourdomain.tld, because MX doesn't point at them.
[0] the only way to for it know that is to run some Google Business or whatever it called now, where you actually ... point yourdomain.tld MX records to Gmail and it would process them... but it would not deliver them to yourmailboxname@gmail.com!
BTW it would be absolutely the same idea if instead of Cloudflare you would use Google Business (again, whatsitsname). You would setup 'Send As' in yourmailboxname@gmail.com as a usual SMTP identity which would allow you to use Gmail interface to send from somename@yourdomain.tld, and similar you need some way to explain to Google/Gmail what all mails at *@yourdomain.tld should be forwarded to yourmailboxname@gmail.com.
Yeah, sorry I meant as a soln for when your backend MX actually is *your* backend MX. That is, it knows it hosts the mailbox for localpart@example.com and the mail recipient address matches on the envelope.
I understand the vagaries wrt forwarding to an acount of a different name and you're spot on there.
> That is you have your MX records pointing to `mx.example.com` in your example.com zone config, and enable the Cloudflare proxying of it (usual orange cloud in the UI).
Interesting. I have a few bits and pieces on my Workspace domains to automate mail processing using Google Apps Script so will have to see if I can move that over to Cloudflare. Be nice to extend the functionality to non-GMail inboxes. Thanks for the heads up.
For that to work the destination server, in this case Gmail, would have to know to deliver mail addressed to me@domain.com into your Gmail mailbox. In this example it's a limitation on the Gmail side.
Domains and subdomains are handled by DNS which is why Cloudflare can E2E proxy them. Email mailboxes are handled by an application running on a server.
Sorry - just had to clarify elsewhere too so I obviously wasn't clear... I meant in situations where the backend MX has a mailbox which matches to mail recipient as in the case where you're running your own mail server and would like Cloudflare sat in fonrt of it just like they sit in front of your own webserver.
Obviously if there's any recipient address trranslation in play forwarding becomes necessary.
Pi-hole is a bloated mess compared to this IMO. At the end of the day pi-hole is still just a fork of dnsmasq with a load of scripts and a bootstrap gui whacked on top. You need to add on extra bits and pieces to get anything like modern tech whereas AGH has https gui, multi-user support, DoH/DoT/dnscrypt/etc, toggles for quick blocks, access to a 'realtime' blocklist for emergent threats all baked in. It's also a single self-updating binary with a single config file instead of spraying bits all over your OS. Runs on pretty much anything you can think of, too.
pi-hole was great back in the day but unless you're just keeping on keeping on with an existing install there's better options available now.. AdGuard Home, Blocky, Technitium DNS etc.
I often compare pi-hole to DD-WRT inasmuch as it was awesome back in the day but times have changed and you probably wouldn't use it as first choice these days given what else is now available to you.
You can be fully protected just using vanilla dnsmasq and downloading fresh blocklists from time to time. It seems all the more ‘marketed’ flavors of adblockers are just web bling on top of dnsmasq. What else do they really offer?
Well 'the alternatives' are many so there's no quick answer to this, but restricting to just AGH as per this post then...
Encrypted upstream lookups.
Responding to encrypted lookups made to themselves.
Realtime threat protection via API.
Quick toggle of blocks instead of rebuilding lists.
Ability to quickly change blocking of individual devices.
Decent Metrics.
Probably more.
But if you just want something with no web bling then there's other alternatives to dnsmasq which would be worth looking at which give some of the above features whilst keeping it commandline and manual blocklist building.
dnscrypt-proxy is wonderful, for example, and can do most of the stuff you can do in dnsmasq.
Anecdotally, I’ve been a sysadmin for 20 years, been around computers since I was a toddler (apparently slept on top of a Data General something-or-other as a baby..). I have the skills to learn how to do dnsmasq-based blocking from scratch, write the scripts to fetch blocklists, init scripts etcetera. However, I run AdGuardHome on my OpenWRT router because I want to spend my time elsewhere. It was a case of install the package, fiddle the DNS routing slightly, pick my blocklists, and pick my up streams.
If I want metrics, I just open a browser and see what clients have been the noisiest, what’s being blocked a lot and so on. Generally I don’t even think about it.
I can easily see what domains are blocked in the web ui and see that Adobe products are trying to phone home so often and which clients are trying to resolve what domains.
But it looks like a lot (all?) of the work here was just to get pi-hole functioning well - and that now needs him to deploy pi-hole, cloudflared, caddy plus all the surrounding tools of Docker, Docker Compose, Ansible etc.
You're spot on that if he'd have applied some thought outside of simply 'fixing pihole' he might have seen there are more modern and elegant solutions to configure network-wide adblocking.
e.g. AdGuard Home is an opensource single-binary precompiled for most architectures and OSes. Self-updating with an HTTPS multi-user GUI; supports DoH, DoT, dnscrypt out-of-the-box. Has a single yml config file to backup/sync; supports adblock lists based on regex as well as hosts file format.
Downloading and running that one little binary gives him the endgame he wants a lot more elegantly.
