I'm also not trying to stop tracking, so much as I'm trying to have my own semi-permanent equivalent to mailinator that nobody will recognize as such, that I can use to cut back on the amount of spam I get.
In my case, it costed me two offers. One from Google and one from GitHub. Come to think of it, yeah I will begin migrating everything away from FastMail and stop using it completely.
Also I think they are still based in Australia? Would be happy to hear about alternatives.
Isn’t it so bad that it’s overly hard to move away :(
- Only use one email address: [email protected]
- Always add a filter: [email protected]
- Send all emails without a filter to SPAM
Since it's not a common strategy, it is much more likely that spammers remove the +hn before sending an email than add one.
I prefer the system of using a basic abbreviation in the email address to avoid these types of filters but still make the email easily traceable later. Say your name is joe smith and you're buying from Sports Online. Something like [email protected] works well for later confirming whom you gave the address to.
I like this approach because one doesn't have to track all of the catch-all emails made on the fly, since finding out who you originally gave that email to is just a matter of searching your past email and noticing that "spo" looks more like those old Sports Online emails and not the new spam from discounted wholesale fancy rugs.
Apart from seeing who a company has on-sold your information to (or more rarely had a staff member steal their database), it's also an easy way to see who has been hacked.
One other reason not to use something like [email protected] is that some websites exist merely as credential honeypots and those types are usually aware of this approach and will then typically exploit the catch-all for spamming. The shady All on MP3 service was known for doing this. (I'm pretty sure that site existed solely to exploit the fact that most people used the same password for everthing.)
While I never had that issue, I had Foo’s legal service contact me about using their trademarked name in my email (a short explanation cleared it up)
name_nospam@blah
(Disclosure: I work at StartMail.)
not only can you not sign up to many services, customer support can often get confused when you need to email reply to them and you cannot email from your aliased email. they see you as a separate user not in their system, or the wrong person replied to the support ticket, etc.
[0] In their webmail client, of course
Capitalisation could also be used for such a purpose, but may be more likeely to accidentally get stripped.
You can email anyone on the internet as anyone and it will be delivered with NO validation. Clients may/may not validate any DKIM signature and the may/may not validate that it actually came from the domain. It's literally the easiest thing on earth to spoof.
Email is sent over cleartext, it is not encrypted. Anyone can read email if they can inspect packets.
That's obviously false if you bothered to do a bit of searching: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#...
>You can email anyone on the internet as anyone and it will be delivered with NO validation. Clients may/may not validate any DKIM signature and the may/may not validate that it actually came from the domain. It's literally the easiest thing on earth to spoof.
That might be true for some systems, but for most services out there, having missing/invalid anti-spoofing measures will result in your mail ending up in spam or not delivered at all.
You would think so.. but its remarkable how easy it still is to forge email.
My mum was recently the target of such a campaign. She's in the executive team at an international NGO. An attacker found her email address and a bunch of her contacts via the NGO's webpage. Then they forged emails from her email address, with a gmail address set up in the reply-to field. The emails all said it was an emergency, and asked for her colleages to transfer money.
As far as we can tell, most of the emails were delivered and lots of people were fooled - at least for awhile.
Her email address has DKIM and SPF set up, but (like most email providers) it has a lax DMARC policy. It turns out thats all it takes to be vulnerable to this sort of attack.
Outside of a few niche hardcore technologists, nobody knows what PGP is or how to use it. It would be hard enough getting my mum set up to PGP sign her own emails in Outlook, on the desktop and from her phone. (Is that even possible?). Let alone require anyone emailing her PGP sign their email too? Thats never going to happen for so many reasons, both technical and social.
I'm a software engineer and I tried setting up PGP years ago in thunderbird and it only worked for a few weeks, then it somehow broke. And then later I lost my PGP key. Oh, and then I started using webmail and PGP didn't work there at all.
And then later still I realised my public PGP key (signed by my web of trust) leaked details on the identity of my social network; which bothers me a lot more than any problems I've personally ever had with a forged identity.
PGP is dead. Let it go.
Technically correct, best kind of correct.
Sure, it is not plaintext, but anyone with the access to the wire could MITM the connections. Maaaaybe something changed in the last ten years, but I never seen someone not accepting a connection with a self-issued certificate and any warnings (to the end user) if the receiver uses self-issued cert. Which makes the whole point quite moot.
The section on MTA-STS describes how that attack is mitigated.
For this attack to be mitigated everyone should implement it. Gmail and Live.com has MTA-STS records, Fastmail doesn't, one regional provider with millions of accounts doesn't have it too.
And finally your MTA should support it and be configured to deny the delivery if MTA-STS validation fails (and adversary, who is happily MITMing your traffic, shouldn't fiddle with DNS and HTTPS and of course blocking HTTP/S from the MX would be considered cheating!).
All in all, SMTP traffic is encrypted, but it is not secured.
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf,
mysql:/etc/postfix/mysql_virtual_alias_maps_wildcard.cf,
hash:/etc/postfix/virtual
user = mail
password = <password>
hosts = 127.0.0.1
dbname = maildb_postfix
query = SELECT a1.goto FROM alias a1
LEFT JOIN alias a2 on (a2.address = '%s')
WHERE '%s' LIKE a1.address
AND a1.active = '1' AND a2.address IS NULL
Note: with the above code SQL injection could be possible through an alias name, but given that in this setup I am the only one managing the mail accounts, I was willing to take this risk. :-) Postfix Admin might do some cleaning/validation, but I haven't checked on it.
Apple's system is "shiny" because it provides near total anonymity, whereas your setup has all the deliverabilty issues of a self-hosted domain and rather uniquely identifies you...at the domain level?
I'm not sure why you are maintaining a hundreds-of-lines virtual table and a web UI, instead of just using a regex or two to capture phil.*@domain2.com or something along those lines (maybe you want to do one including a year or something to cut down on spam), or blacklisting as needed by having postfix reject during the SMTP session so the email is marked as invalid and is removed from the spammer's database.
Or, I dunno, just use VERP? I don't think I've yet run across anyone smart enough to drop VERP from email addresses.
I still want to use random unique addresses even for important and trusted services, not just for throwaway uses. So third party domain is not an option.
I use self-hosted unique addresses mostly for registering to services, so forwarding those messages in both directions through Apple's service would expose all those services to a silent takeover via password reset by Apple's employees in control of this service. So this service is exactly as useful as those random throwaway email inboxes available on the web. More polished maybe.
All I got was "not a valid email" or something like that.
Otherwise everyone @example.com is the same person.
If a domain only occurs once in a user database, it's likely to be a personal domain. A data broker that sees the same domain in a few different datasets (once in each) can be quite confident that the domain is an individual's.
Thanks to this setup, I've already encountered one instance of a company either leaking or selling their customer information.
Bonus: a ghetto alias generator:
dd if=/dev/urandom bs=1 count=10 | base64
Square also makes this incredibly difficult because if you enter a merchant specific email they permanently tie it to your card. So now any time I ask for an email receipt I get an email to my hairdrstylist’s “unique” email.
Never had it go that far but I definitely had some odd reactions e.g. a support agent thinking I was a colleague.
On the other hand, if you have a relatively common name it avoids people giving your email address then behaving aggressively when you tell them to stop. I’ve had a few friends hit this issue.
I’m sorry, I can’t parse this. Can you try again?
I used <dentistbusinessname>@<mydomain>. My name was never involved in the address.
That's the point, if you don't use your name in your address, you can't be <genericname>@<genericdomain>, which third parties will provide as their email,
Because I use the same scheme you do I've never had that issue, but several friends with common names have hit the issue having registered to more "normal" hosts, often as somewhat early adopters and thus having gotten their pick.
The annoying thing is the number of services these days that don't seem to require you to verify your email. Examples of the above included eBay and Spotify. On both occasions I had to contact support to ask them to delete the account.
I’m still not following. Who is this third party and what does it have to do with a confused receptionist?
[email protected] or [email protected] . Many SMTP servers respect periods as differentiating emails, so services can't delete them. It doesn't help you stop spam, but you can add a gmail filter that [email protected] is put in a separate label. And it's very fast to type, easy for non tech-y people
So far the most spam I’ve gotten has been to the address I used for Amazon (probably leaked by a third‐party seller there).
I mean you can pick any format you want before the "@", but yeah my format is trivial. Nobody has tried to do it automatically yet though, as far as I can tell.
For example, to enable plus addressing in postfix is only a matter of defining:
recipient_delimiter = +
Though I had originally made this because with the "+" approach, you can easily get the original address by simply removing everything after the "+", while with mine you cannot. On top of that, sometimes "+" does not work in services that do "strict email validation".
One never let me change my email or password when I used the +.
OP also could have just used a regex in the virtual file.
It's the easiest Postfix config in the universe, essentially just:
And then /etc/postfix/virtual looks like this: I also made a super simple web UI for myself to edit this file quickly.Gmail seems to be fine with this, emails do not usually end up in spam. Every full moon maybe, but usually it's alright.
It's not as shiny as Apple's thing, but it's 100% selfhosted and I own the domain.