Hacker News new | past | comments | ask | show | jobs | submit login
Tmpmail: Temporary email right from your terminal written in POSIX sh (github.com/sdushantha)
157 points by thunderbong 79 days ago | hide | past | favorite | 53 comments



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.

[0]:https://github.com/leahneukirchen/mblaze

[1]:https://www.nongnu.org/nmh/

[2]:https://github.com/nicm/fdm


Shameless plug because tpis is also my approach: combine with fzf and a few shell scripts and the sky is yours

https://sr.ht/~rakoo/omail/


Nice use of Unix philosophy and some well said things about why. Thanks for sharing these.


Thanks !


I want to express just pure love towards your idea that software should be simple.


I wish there was a CLI imap client with a conversation view as seamless as Fastmail or Gmail. I found mutt to be very clunky.


Try sup: https://github.com/sup-heliotrope/sup

or its spiritual successors based on notmuch


Have you tried using threads in mutt? Having them collapse by default seems to reproduce what I remember the gmail experience being.


aerc is pretty good.

https://aerc-mail.org/


gnus was pretty good for conversation chains


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.


Thanks! It makes sense, but I'm too lazy to bother.

I haven't seen my email get filtered, even after more than a decade, but I suppose it could happen.

If I do run into something like that, I can always fall back on pwgen. Thanks again!


"I have also heard of people getting filtered as potential spam accounts when the email address matches the service name or whatnot."

I have heard of that as well but many years in I have not experienced it.

I do the same thing the person you are responding to does:

nameofservice@domain.com

... and they all just go to my inbox with a descriptive tag in the subject that I insert with procmail.


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 :)


>I heard facebook doesn't allow emails with "facebook" in them.

Where, exactly, did you hear that?. I can confirm that's not the case.

My FB email address is a bare 'facebook@myemaildoman' and hasn't been a problem. Ever.

That said, I set that as my FB email address more than a decade ago, so I guess things may have changed since then.


I would guess just speed of creating the addresses/not having to worry about using same address twice accidentally


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.


I use self hosted anonaddy instance for such purpose and have dedicated alias for each registration.

It forwards received emails to my main mailbox with added header telling me source email with note about where I used that address.

that way I discovered few sites that were bought by some entity and that sold my email to some crypto 3rd party


1. does anonaddy support ARC?

2. are you able to reply to the email?


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.

Could you elaborate how you'd address that?


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.


That’s very helpful. Thank you.

Who do you recommend as a very secure registrar?


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.


Definitely and I assume learning all of those will provide enhanced security layers also.

I’m looking into MarkMonitor as a registrar with advanced security systems.


Sorry for the late reply.

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.

Have fun!

[0] https://mailinabox.email/

[1] https://mailinabox.email/guide.html

[2] Annoyingly, the setup guide wants to you 'curl setup.sh | bash'. You might want to check it out first at https://github.com/mail-in-a-box/mailinabox


It definitely seems doable. Another one is iredmail that has been mentioned.

https://github.com/iredmail/iRedMail


I've lost several Google accounts through excessive authentication requirements with no viable alternatives.

Fortunately I'd anticipated such issues and largely abandoned the platform.

I have one account which I care about somewhat. I have to remember to log into that at least once per year to retain it or it will also be lost.



So what is your secure email approach? Any thoughts on this problem would be interesting.


Personally, protonmail.

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’m looking into MarkMonitor as a possible registrar with extreme security features.

I think gmail is very dangerous they can delete your existence by accident and they don’t even have a human to contact.


I do the same, and the only leak was target giving my email to a pork-related class action lawsuit.


Hah, that is much fewer than I would have expected.

Too bad you can't do the same with phone numbers.


Love this. Nota bene, it uses 1secmail.org’s API on the backend. Still love it.


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.


Just wanted to say I really appreciated the readability of your code. It was very easy to dive in, understand how it works and how to modify it.


Imagine a threaded mail reader with this feature from say, 1987? I would pay for a threaded HN news reader.


Gnus is not too far from that if someone maps HN to NNTP.

I think there are some HN to NNTP bridges available.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: