mail from terminal

This is a continuation of:


It seems there are few mail programs for the command line. And for
today's chaotic use of mail (html mail, attachments, etc), much less.
In my taste, only alpine is usable in a comfortable way. I find
it strange.

mutt is a nice small program, much smaller than alpine, and it seems to be
the preferered tool by experienced UNIX users. It is in my opinion
not usable for one reason: it seems to be not possible to read an email with imap without
downloading all its attachments. That is not IMAP support.

How many people here read email regularly in the command line? What they use?
Is their mail client so good, that they only in very exceptional cases need to use a
GUI program/Webmail?

UPDATE: google & Co seems also to be making more difficult to read Email with normal programs.
That will reduce the number of usable MUA. But Alpine is also caring on this:

 
I am a mutt user since years. A strength of this kind of readers is that they do not follow each link automagically in a html mail.
 
How many people here read email regularly in the command line? What they use?
Is their mail client so good, that they only in very exceptional cases need to use a
GUI program/Webmail?
Until I sold my businesses, I used text messaging with sendmail and mutt multiple times a day communicating with co-workers and hosting providers. It's faster, needs nothing else and contains the information we need. Text trumps everything.

And I was in the entertainment business where graphics rule. So the only time I needed GMail or such was when communicating with outsiders--artists, video content providers, and so on. Of course, most non-professional IT people use graphical interfaces by default cause that's all they know. Nowadays, most IT people use graphical interfaces cause that's all they try to know.
 
It is in my opinion
not usable for one reason: it seems to be not possible to read an email with imap without
downloading all its attachments. That is not IMAP support.
It seems there were several attempts in Neomutt to support this, see for example https://github.com/neomutt/neomutt/issues/2004

The reason I don't really care is that my IMAP is on my LAN anyways. But obviously some would consider it a valuable feature, so maybe it'll be implemented some day.
 
A considerable number of companies are not supporting IMAP or SMTP or the secure variants of it. Instead favoring this web-style oauth stuff that is basically a mess.

There are a few proxies you could consider such as davmail: http://davmail.sourceforge.net/

Or swap to a provider that is standards compliant. My main casual email is gmx.com which I am very happy with and supports imaps/smtps.

However I have also noticed that web-hosting companies (like Awardspace) usually provide a single free (imap/smtp) mail hosting account providing that you supply the domain name and add a few DNS settings to validate the email. I am generally starting to use this for future email accounts I need. I like the idea that the domain name can stay with me rather than if, i.e hotmail.com ever shuts down.

Hosting your own email server (with imap/smtp) is really easy. The difficulty is getting companies like gmail and Microsoft to accept your emails. They have basically blanket blocked a lot of IPs, in the "name of spam protection" when really it is for monopoly and control. They don't even allow you to run email servers on their own Azure platform (they block the ports).
 
Instead favoring this web-style oauth stuff that is basically a mess.
Hmm, you typically have oidc on top of oauth for the web and I don't think that's a mess, but probably the "sanest" authentication for web applications. What IS a mess is the idea to make web access the default for email. A specialized MUA is still much better, so breaking this is really insane.

Hosting your own email server (with imap/smtp) is really easy. The difficulty is getting companies like gmail and Microsoft to accept your emails. They have basically blanket blocked a lot of IPs, in the "name of spam protection" when really it is for monopoly and control. They don't even allow you to run email servers on their own Azure platform (they block the ports).
This might be a bit exaggerated. Given the amount of spambots running on private boxes without the user ever noticing (yes, it's a real plague, just look into any mailserver log), it probably makes sense to completely block emails originating from address pools used for dynamic assignment to customers.

Right now, all you need is static addresses (which you get e.g. with any cheap VPS) and a "sane" configuration including SPF and DKIM and your emails will typically be accepted anywhere.
 
What IS a mess is the idea to make web access the default for email. A specialized MUA is still much better, so breaking this is really insane.
Agreed. I believe some of those proxies actually end up working by scraping web output which makes me shudder a bit.

Right now, all you need is static addresses (which you get e.g. with any cheap VPS)

Well this is kind of the issue preventing us from hosting our own on our own physical servers (from home anyway). I personally am not entirely satisfied by this. I suppose we could tunnel some connections but the reliance on a VPS is a weak link.

Just to clarify, I do have a static IP address at home. But it is in the SpamHaus blocklist as a "residential IP". And thus blocked by all services using these lists.
 
Well this is kind of the issue preventing us from hosting our own on our own physical servers (from home anyway). I personally am not entirely satisfied by this. I suppose we could tunnel some connections but the reliance on a VPS is a weak link.
My IMHO simple solution for this is to have both SMTP and IMAP twice.

For SMTP, outgoing mail is routed over the SMTP on the VPS, and for incoming mail, the SMTP on the VPS delegates to my internal one (also to check whether a mailbox exists) and in the unlikely case that the internal SMTP is down, will answer with a temporary error code.

For IMAP, the instance on the VPS only acts as a proxy for the internal one.

The connection is done with a VPN.

Just to clarify, I do have a static IP address at home. But it is in the SpamHaus blocklist as a "residential IP". And thus blocked by all services using these lists.
This of course is "interesting". Arguing with blocklists can be cumbersome. I wonder whether this is an issue with your typical "business DSL" connection, too?
 
My IMHO simple solution for this is to have both SMTP and IMAP twice.

To be fair, that isn't a bad solution. Though I would still like to free up the VPS for more important things than email passing. Such as torrents ;)

For a while I ran an incoming-only SMTP/IMAP server on my internal home server, and then just used an external SMTP/sendmail server for outgoing messages. It was OK, but I was still relying a small amount on the external server which meant I decided to throw out all of my toys and go entirely with external.
 
For a while I ran an incoming-only SMTP/IMAP server on my internal home server, and then just used an external SMTP/sendmail server for outgoing messages. It was OK, but I was still relying a small amount on the external server which meant I decided to throw out all of my toys and go entirely with external.
The reason I prefer my solution is that I have all the mail storage internal. My cheap VPS doesn't even offer a simple backup solution, and I also want to easily delete it, maybe rent a different one, without losing anything.
 
I am a mutt user since years. A strength of this kind of readers is that they do not follow each link automagically in a html mail.
I never used a GUI mail client, except for testing out of curiosity. And yes, from time to time do I use Web-Mail,
some mails are so corrupted with html-tagging, that there is no alternative.

What you call a strength is no strength, but normal behaviour. An Email is, what it is send with smtp. It is not
the task of a mail client to interpret what is there and take actions according to it, like connecting over
the Internet to somewhere.

Alpine is perhaps better with imap, because it is developed from where imap originated. In the source code
of alpine is still UW imap server. But as far as I know, alpine has only one developer.

My original concern is, the few alternatives and support for cli mail client. There is a mass of people demanding
a "FreeBSD Desktop Edition", perhaps we must soon demand a "FreeBSD CLI Edition".
 
Just to clarify, I do have a static IP address at home. But it is in the SpamHaus blocklist as a "residential IP". And thus blocked by all services using these lists.
Perhaps you can ask to unblock it? I noted that dynamic given IPs often are blocked, so that not even a mail
client can access a server that use the black list. I use zen.spamhaus.org in my server and this is really
a problem. For sending mail I must either use an own web mailer or login into the server.
 
Perhaps you can ask to unblock it? I noted that dynamic given IPs often are blocked, so that not even a mail
client can access a server that use the black list. I use zen.spamhaus.org in my server and this is really
a problem. For sending mail I must either use an own web mailer or login into the server.
The specific issue is here: https://www.spamhaus.org/pbl/query/PBL882403

It is the policy of Sky Broadband that email sent from this IP address should be sent out only via the officially supported Sky Email outbound SMTP service, or via any authenticated third party outbound SMTP service of which a Sky Broadband user is a customer.
Again, I am fairly concerned this is an attempt by Sky for control rather than actually to benefit anyone or prevent spammers. Even SpamHaus suggests that this should not really be done:

Sky Broadband users using third party outbound SMTP services who experience mail blocking issues due to this listing should take this up with the support department for the third party outbound SMTP service concerned. The Spamhaus Project recommend that mail service operators should not use the Spamhaus PBL list to block outbound mail that their own users are sending however unfortunately, some do

Suffice to say that their "SMTP service" is basically just a web page with hundreds of adverts and not actually a standard ;)

The problem is that ISPs these days hold all the cards and are quite happy to not receive my ~£12 a month rather than actually provide a proper service to their customers. I believe the laws are such here that it is not allowed to start your own ISP meaning that competition is a no-go and it is basically an oligopoly.
 
I've been running my on mail exchanger for years. What I do is ssh out to one of my virtual servers from my firewall, and forward a local port on the firewall to the mail exchanger out on the Internet. My ISP is none the wiser.

I got 90% of the way done on an Ansible script to automate this setup on Digital Ocean. I need to get back to it and finish it.

This path is not always roses, though. One of my motivations to modernize my setup was that one of my kids' passwords got compromised, and some spammer used me to send tens of thousands of messages. This landed me in a lot of block lists, and I still have poor reputation with Gmail (it was more than a year ago).

The solution I came up with is to implement outbound send limits using Policyd. No real user is ever going to send more than 1000 emails a day, and that is a pittance for most spammers. I'm not super happy with Policyd. I think I could write something better, but I suspect that's another one of those projects that's never going to amount to more than half a page of scribbled lines.
 
It seems, there is other usable program: GNUS,


It seems it does not download the whole mail including attachments when one wants to read only the
message. It shows all imaps folders. And with Gnupg works good.

I do not find a way to configure many mail accounts, perhaps there is necessary to write code in the horrible
emacs-lisp. It is not so intuitive. You know, EmacsOS. And in the console I get horrible colours.

I would say, it is not so comfortable as alpine if one checks frequently his email in many accounts,
and the footprint is big.
 
Back
Top