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.
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 [email protected] 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.
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 [email protected] they know you prob also have [email protected], [email protected] 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. [email protected] could be anyone.
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.
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.
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 [email protected] 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.
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.
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.
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.
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.
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.