After trying a few different CLI mail clients---mutt/neomutt, s-nail, etc.---I've come to love the approach of mblaze[0], _i.e._ just a collection of commands to interact with maildirs, which can be separately managed by OfflineIMAP or whatever.
I'm curious how mblaze+offlineimap compares to other similar setups: nmh[1], fdm[2], and getmail.
Started running my own email server about 10 years ago for essentially this use case. Every entity I need to give an address to gets a unique, randomly-generated one. I figured this would let me spot the leaks.
After roughly 1000 addresses handed out, surpisingly only two sources end up receiving spam: 1) addresses that I've posted on public forums, and 2) the address I use for patches to GNU software.
>Every entity I need to give an address to gets a unique, randomly-generated one. I figured this would let me spot the leaks.
I do the same, except I don't use a randomly generated address. Rather, I use something that identifies who it is. e.g., if I had a relationship with Tesla, the email address would be 'tesla@myemaildomain'.
What (if anything) is the advantage of using a randomly generated email address over the scheme I use?
N.B., I'm not dissing your strategy at all. I do exactly the same. I'm just curious about the "randomly generated" bit.
When I started, I wanted the addresses to look as innocuous as possible in order to avoid unnecessary explanations. Filling out paperwork that people hand inspect is one case where that can cause issues. I have also heard of people getting filtered as potential spam accounts when the email address matches the service name or whatnot.
Anyway, I just use pwgen to generate plausible-looking addresses: pwgen -A0 10 1. They often look like realistic abbreviations of names.
Not the parent commenter, but I've encountered “people from the counterparty organization get confused and wonder whether you're part of it too / pretending to be part of it too”. This can be mitigated with some obscuring transformation.
>Not the parent commenter, but I've encountered “people from the counterparty organization get confused and wonder whether you're part of it too / pretending to be part of it too”. This can be mitigated with some obscuring transformation.
A fair point. Thanks!
Personally, I can't be bothered and when (not if -- the scenario you've outlined has happened with me) folks get confused, I just explain that I do it to fight spam and they generally just nod agreeably. Whether they get it or not isn't my concern -- knowing whose user database has been pwned is.
> I do the same, except I don't use a randomly generated address. Rather, I use something that identifies who it is. e.g., if I had a relationship with Tesla, the email address would be 'tesla@myemaildomain'.
>
I almost use the methodology except I add ramdom characters at the end. Tesla.ahcdk@domain.com
Reasoning is that its most likely if you have tesla@ you will have facebook@ tesco@. When adding characters you can filter on the . + 4 characters
>Reasoning is that its most likely if you have tesla@ you will have facebook@ tesco@. When adding characters you can filter on the . + 4 characters
I get you, and it's a good idea if you're using someone else's domain (e.g., gmail.com, protonmail.com, etc.) to make sure you have a unique email address.
Since I own -- and host my own domain for my emails (as does the OP, IIRC), that's not necessary, as the domain name itself makes the email address unique -- since I'm the only one who uses it. As such, I can (and do) just filter on 'facebook', 'tesla' and 'tesco' directly.
I heard facebook doesn't allow emails with "facebook" in them. Alternatively you can give facebook.te@ address to tesla and tesla.fb@ address to facebook, nobody will figure it out :)
The real value of this, IMHO, is that it makes it much harder to match you against services and in ad platforms. Hashing email addresses is the primary way user data is exchanged.
I cannot thank you enough for your contributions to GNU.
I always use the dingleberry subdomain that goes nowhere, except when an actual human interviense. Goes straight to the bitbucket, and 1 out of 10 gets a pervue to see if I need to add the source to my reject list which my ISP keeps peeking into for changes to their reject list.
1. In case dmarc is not passed you get extra red banner with warning to forwarded email
2. Yes you get special email to reply-to field that allows sending from alias, but you have to make sure you remove included banner containing alias deactivation URL from quoted part of reply. You can disable this header but in my case I needed to reply only few times
> surpisingly only two sources end up receiving spam
Quite a few of mine get junk:
* A couple that have been subject to leeks or hacks, that I haven't got around to changing yet (linked-in for example)
* A fair few were given to businesses that are no longer in operation (hosting providers, online stores) who presumably sold their contacts databases to make a few pennies before finally closing up
* Also some junk senders seem to have worked out that the sub-domain I use for the per-entity addresses is a catch-all, I need to address that at some point.
> Also some junk senders seem to have worked out that the sub-domain I use for the per-entity addresses is a catch-all, I need to address that at some point.
There are a few options I've thought of, including these ones off the top of my head:
1. Just enable each on first use, instead of using a catch-all at all, though there is a danger there of bounces due to mistakes on my part.
2. Keep the catch-all but send to a junk folder unless the destination address is on a white-list, this has the advantage that if I forget to add the new address (or do it incorrectly) no mail is lost as I can move it out of junk after the fact (as long as I notice within 30 days).
3. Generate the addresses either fully or as <picked-portion>.<truncated-salted-hash-of-that>@sub.domain.tld, so ea588e3be96e89.8177be49@sub.here.com or SomeShop.499ec679@sub.there.com, and use programmatic filtering to decide where the messages go (junk unless the hash matches). The disadvantages of that are needing to have access to the generator at any time I need an address, difficulty giving addresses verbally (there would be transcription errors), and it does nothing for existing addresses.
Option 2 is probably the winner there.
Every now and then I think of another option then dismiss it as overcomplicated or otherwise not workable.
I think the idea of having a token in the address could work!
Unless you’re being specifically targeted, it doesn’t need to be anything particularly long or secure though—just needs to not fit the same pattern as everyone else.
It could be as simple as “the letter before the first letter and the letter after the last letter” or something easy enough to generate in your head when filling out a paper form. (E.g., “hackernews@“ becomes “hackernews.gt@“; “google@“ becomes “google.ff@“)
Or “numbers of vowels mod 10” (“facebook@“ becomes “facebook.4@“; “medium@“ becomes “medium.3@“).
You could always combine this with option 2 as well. Anything that has a valid token goes through the regular filters, everything without goes straight to junk.
… In fact, I think I’m going to do this for my own domain.
You're right, that is a good simplification of that option to make it less tech dependent:
* Generate addresses with that process (that can be done in the head)
* Programmatically verify the incoming addresses to filter junk/not (hopefully not difficult with postfix, just use the “standard” config-in-db setup with a stored procedure to do the mapping instead of a simple SELECT so you can check the checksum (in fact, it should be possible with a SELECT but I expect the syntax will be more messy that way))
* Still have a whitelist for addresses previously used, unless using a new sub-domain for this setup
* Still send mismatches to a junk folder not /dev/null in case of mistakes
I might go that way when I finally get around to rebuilding & migrating my mail server(s)…
I’ve recently been the target of many attempts to hijack my gmail account, including even phone calls with live agents impersonating google “security team”. Successfully hijacking my gmail address could be catastrophic for me and others I assume.
Anyway I was wondering if self hosting an email server might allow for a security layer for those of us sophisticated enough. Especially if we own our own domain. Ideally my email address with access to financial services would have 2FA to both read and send emails for example. Don’t even think there are clients or protocols but perhaps with self hosting this can be rigged up with various tricks like port security opening only with a 2FA message.
I’d be curious what other perspective on this issue is.
It's a decent amount of upkeep and cost, but I get paid do it for a bunch of clients who desire this for their companies and have my own which is humming along great. If you go the route of a script to set everything up I found iredmail to be the most mature and reliable solution, even if the upgrade path is super manual at least it gives you a chance to know at what point things went wrong rather than having to pour over logs to fix something broken that is running in production. It also pairs nicely with open source failover solutions and if you need enterprise support they're extremely responsive. Bonus points for getting it working with your phone for backups of contacts, calendar and notes with CalDAV or whatever to really decouple yourself from cloud services with shady terms (I had to pay for an app on my phone for this to really work, but it works great). Setting your whole mailserver up manually is also an option , but be prepared to sink like a month of time into learning how the hell to do that. This is technology from the 1970s with a ton to get it working in the modern world after all.
Just be wary that you'll have to upgrade kinda often. I keep subscribed to github alerts for iredmail as they're really prompt about notifying their customers when they need to patch security holes.
A perspective I've read on this (Granted, this was at least 5 years ago) was that it was paradoxically much harder to compromise a Google account than it is to hijack a domain from many registrars. I read an account by someone who had a custom domain and the attacker had social-engineered the registrar into allowing him access, then he proceeded to update the MX, directing the email into the attacker's server.
This probably varies from one registrar to the next, and hopefully all have stepped up their game somewhat since that time, but it left an impression on me and caused me to update a lot of my accounts to my Gmail. Obviously, nobody is going to be able to call into a customer service desk and talk them into updating the gmail.com MX record, so for someone to illicitly gain access to mail sent to <me>@gmail.com either I have to be pwned myself (leaked a credential somehow) or there has to be a global 0-day exploit affecting it. In the latter case I am personally willing to bet that mine would not be the first one (or even in the top 10 million) accounts that the hackers would try, so I sleep pretty well.
I understand. For me this raises the question of who is the most secure and reliable registrar for a US citizen. The security of a self-hosted approach appears to be determined by the security of the
MX records, the self-hosted server security, and the IP security of the server.
With the increasing authoritarian tendencies of governments it seems worth considering since they can clearly pressure the big tech companies to access or hijack your email address.
>The security of a self-hosted approach appears to be determined by the security of the MX records, the self-hosted server security, and the IP security of the server.
Don't forget DMARC/DKIM/SPF. They're necessary these days as well.
I've heard good things about Mail-in-a-Box[0], but haven't used it myself (although I have/do use(d) a bunch of the servers/tools amalgamated into the product).
The setup guide[1][2] also gives a good overview of implementation requirements.
I'd like to run my own infrastructure, that's problematic on several grounds, and regardless not a generalisable solution.
I'm increasingly of the mind that government postal services should offer email directly. That should also come with privacy protections we're not seeing from private-sector providers. I'm not pretending that postal mail is free from government surveillance. However simply by way of the fact that it is universally used there is an exceptionally large contingency with concerns that it have strong privacy protections. Government-provision of email services would no more precluded private and individual provisions than is the case for parcel and courier delivery. What it does do is insure universal access at a defined minimum standard regardless of failings in commercial markets.
(The details on what specifically should be considered is a long one, beginning with whether or not SMTP protocols are really suited to the present age, and including questions of access to multiple email aliases, pseudonymous email, and all that jazz. I'm not going to pretend this is settled or simple.)
I'm also relying increasingly on postal rather than email. The latter is increasingly intractable.
I thought from the headline this was about _sending_ email right from the terminal, and I thought, well that's easy, just telnet to sendmail on port 25 and say HELO.
I'm curious how mblaze+offlineimap compares to other similar setups: nmh[1], fdm[2], and getmail.
[0]:https://github.com/leahneukirchen/mblaze
[1]:https://www.nongnu.org/nmh/
[2]:https://github.com/nicm/fdm