Email server software

[CNK]

I want to set up a system to receive emails via POP from a number of different servers and make them available on my LAN via IMAP, mainly so that I've got one central archive instead of stuff spread over different PCs and remote email servers.

I'm looking at fdm for getting the emails via POP. For the IMAP server I'm not decided on anything in particular (they all look a bit hard).

As far as I can see there's no email server software at all available for TC, but then there are a lot of different programs out there so I could be missing some. So are there any existing programs with extensions for TC12 (preferably 64 bit, but the build instructions for 32 bit extensions would be useful too, as would extensions for earlier TC releases) that would serve my purpose?

I know I can compile them from source and make my own extensions, but it might be wasting my time if an equivalent already exists which I'd be just as happy with.

[Rich]

Hi CNK
I use  claws-mail  to retrieve emails via POP:
http://tinycorelinux.net/10.x/x86/tcz/claws-mail.tcz.info
It is also in the TC11 and TC12 repos, but I don't see it in any of the x86_64 repos.

[CNK]

It turns out that GNU mailutils includes an IMAP server, as well as lots of other useful programs such as movemail which can do the same thing that I was going to use fdm for.

There was a mailutils extension for TC 5 up to TC 10 by Juanito, but not for x86_64. I'll build a TC 12 x86_64 extension with similar features based on the compiling notes.

@Rich: I made the Sylpheed extension which is in the x86_64 repo, and it can fetch mail using the --receive-all option. However it won't run "headless", without starting up the user interface, which won't do for my use where I want to regularly get new mail automatically with a Cron job so I don't have to wait for it to download over my slow internet connection. CLAWS-Mail is based on Sylpheed, so I'm guessing it works much the same.

[Rich]

Hi CNK
I just checked  claws-mail  and it does not appear to be able to run commands without launching the GUI.

I did read where someone used some trickery to run it headless:
https://www.raspberrypi.org/forums/viewtopic.php?t=38685#p1374941

But if you have tools designed to run from a command line you are better off using them.

[CNK]

I eventually got around to this and there is now a mailutils.tcz extension for TC 13 on x86_64.

It pretty much includes every type of mail tool you could want except for an SMTP server. Besides the mentioned movemail and imap4d, there's also pop3d, and putmail provides the functionality of the common sendmail command, plus lots more as described in the documentation.

To run the IMAP server I had to add the "mail" group, with the users able to log in added as members of that group. Then after configuring it in /etc/mailutils.conf, I added imap4d to /opt/inetd.conf with this line (it can also run without inetd, in daemon mode with the "-d" option):

Code: [Select]

imap  stream tcp nowait  root  /usr/local/sbin/imap4d imap4d


[Leee]

Hi CNK,

Thanks for putting up mailutils.tcz.  While Tiny Core is not my primary target for this project, it -is- my day-to-day driver for everything else:  I've been fooling around lately with a project that I started and set aside several years ago to create a simple script-driven (and hence portable) email client for POP3 and SMTP. 

My current interest is driven by the sad fact that there's no decent POP3 client for the pinephone.  Sure, you can -run- claws-mail or thunderbird on it, but those translate poorly to the tiny screen of a phone - so poorly as to be unusable.  And -all- of the phone-friendly mail apps (that I've looked into so far) are IMAP capable but not POP3-capable.

The past week or so, I've been fooling around with the -sending- side of the project and that's easy as I just call out to Brandon Zehm's sendEmail (which, eventually, I'll look into converting to straight shell script to remove the perl5 dependency, though that's low priority since perl5 is fairly ubiquitous).

I've been putting off revisiting my work on the receiving (POP3) side of it, even though that's really the important part, because I remember it being a bit of a PITA... But it looks like mailutil pop ... will be the key to that little issue.

So it looks like you've just made my project significantly more realistic by packaging up mailutils.  Thank you!

[CNK]

The past week or so, I've been fooling around with the -sending- side of the project and that's easy as I just call out to Brandon Zehm's sendEmail (which, eventually, I'll look into converting to straight shell script to remove the perl5 dependency, though that's low priority since perl5 is fairly ubiquitous).

I've been putting off revisiting my work on the receiving (POP3) side of it, even though that's really the important part, because I remember it being a bit of a PITA... But it looks like mailutil pop ... will be the key to that little issue.

So it looks like you've just made my project significantly more realistic by packaging up mailutils.  Thank you!

Glad to hear. You'll want to use movemail to receive over POP3 though (it supports POP3 and IMAP4), "mailutils pop" and the other "mailutils" commands are just debugging tools. They're actually just a thin layer of convenience equivalent to connecting via telnet and issuing the protocol's commands directly, so you don't have to get the syntax exactly right like you would when talking directly with the server.

Movemail and many of the other tools can read passwords from a "~/.mu-tickets" file. The documentation for that is a bit confusing, but a very basic usage is adding this line so that you can log in as "user" to the server "pop.example.com" with "[password]", on any supported protocol:

Code: [Select]

*://user:[password]@pop.example.com

Then you can just use "user@pop.example.com" in commands and it will fill in the password without prompting for it ("movemail pop://user@pop.example.com [mailbox]", for example). Handy for scripts.

Sending email with putmail is also easy, it just reads the email from stdin and sends to the provided address, but you need to generate all the headers yourself.

There's also a command-line email client in the form of the ye olde POSIX "mail" command, though it isn't so easy using that with modern emails. It's scriptable apparantly though.

[Leee]

They're actually just a thin layer of convenience equivalent to connecting via telnet and issuing the protocol's commands directly...

Which was exactly what I had been working on back in 2014!  I've just got into the documentation for mailutils - I'll be moving forward a bit more slowly now, with much to learn and many wheels to not re-invent.

Thanks for the tip on movemail vs "mailutils pop...".  It was in the hope of just that sort of hint that I came back to the forums this evening!     

[Leee]

@CNK

Though cumbersome, piping these inputs into mailutils pop:

Code: [Select]

connect pop.my_hosting_provider.net
user name@my_hosted_domain.net
pass mypassword
disconnect

completes successfully, using movemail with the same user, password and server fails, apparently due to the '@' in the user name.

I'm probably overlooking something simple but I can't seem to come up with an effective way to quote or escape that symbol such that it doesn't break movemail and still provides the correct user name to the remote pop server.

Any ideas on how to make that work?

[CNK]

It's a URL, so you have to character encode '@' as "%40". No that wasn't obvious to me either, I found it by searching the mailing list and finding this message. Apparantly the info was added to the docs back then, but it seems to have been removed again since. I guess it's one of those things that seems obvious to a developer, but easily confuses users.

[Leee]

It's a URL, so you have to character encode '@' as "%40". No that wasn't obvious to me either, I found it by searching the mailing list and finding this message. Apparantly the info was added to the docs back then, but it seems to have been removed again since. I guess it's one of those things that seems obvious to a developer, but easily confuses users.

Thanks.  %40 did the trick.  I've been dealing with some real life issues and haven't done anything useful with it but I did verify movemail works that way.  That's going to be a huge step forward in my project.

The whole thing becomes a little more important to me as I've become somewhat disenchanted with thunderbird lately.  Seems in my attempts to get it to never check for updates (or at least to have such checks always fail) I've got it into a mode where it regularly uses up enough resources to make the host unusable.  That's not even worth the effort of debugging as I've simply  switched to sylpheed,  but eventually mx ("mail experiment") will be useful on core 13.1/x86_64 even if it never does make it to the pinephone.

[Rich]

Hi Leee

... disenchanted with thunderbird lately.  Seems in my attempts to get it to never check for updates ...

To disable updates, create  /etc/thunderbird/policies/policies.json  containing the following:

Code: [Select]

{
  "policies": {
        "DisableAppUpdate": true
        }
}


[gadget42]

re: thunderbird

left thunderbird for evolution when the family switched from ubuntu to debian to get away from snap packaging.
left evolution for claws when we switched from debian to devuan to get away from systemd.

also, for those interested in rabbitholes:
http://forum.tinycorelinux.net/index.php/topic,25651.msg165730.html#msg165730

[Leee]

Hi Leee

... disenchanted with thunderbird lately.  Seems in my attempts to get it to never check for updates ...

To disable updates, create  /etc/thunderbird/policies/policies.json  containing the following:

Code: [Select]

{
  "policies": {
        "DisableAppUpdate": true
        }
}


Thanks Rich.  I feel like I should have already known that, buy I didn't.         I had been trying to do it through the config editor (about:config), which doesn't give any option for just disabling updates.  I'll give this a try, though it may be a few days before I can get to it.

[Leee]

left thunderbird for evolution when the family switched from ubuntu to debian to get away from snap packaging.
left evolution for claws when we switched from debian to devuan to get away from systemd.

Your trek from distro to distro and the reasons for it seem very much like something I would have done. 

Fortunately, I got involved with Tiny Core back in the days when the bigger distros didn't seem like "a good match" for my hardware so I never really got invested in the likes of Ubuntu and its many clones and ancestors.  I'm spoiled now - every time I fool around with another distro I think, "Why am I doing this?"