Solved Simple IMAP/POP3 server

Greetings all,
I would like to convert my old e-mail stored in Eudora MBOX format to maildir. It appears that there is not such a converter, most offer conversion to PST, then I would need to again convert PST to maildir.

Instead of going through the two-step process, and trusting that the converters work properly, I though that I would install my old copy of Eudora on Windows 7 machine, establish an account supporting IMAP/POP3, point Eudora to it, synchronize the account with the Eudora mail and then download the mail onto a local FreeBSD machine.

There are two potential issues with that approach. One, the e-mail might contain some sensitive information and two, it might have to be done in batches since when I was downloading e-mail form Google, there were some restrictions of number of e-mails/unit of time.

Hence, I was wondering if there is some easily configured a server supporting IMAP/POP3, that I could install on the FreeBSD machine and transfer the files over local network. I do not need anything elaborate, with bells and whistles, spam protection, etc., as the server will never connect to Internet.

Any help, pointing me to the right direction, or even an alternative that I did not consider, would be appreciated.

Kindest regards,

M
 
I was wondering if there is some easily configured IMAP/POP3 server, that I could install on the FreeBSD machine and transfer the files over local network.
IMAP and POP3 are protocols for reading mail, you cannot send mail to it. Mail clients actually use SMTP for sending mail.
 
Hi SirDIce,

I know. But the terms "IMAP server", "POP3 server" are used instead of the correct "server supporting the XXX protocol" . Nevertheless, I corrected the language in my post.

Kindest regards,

M
 
But the terms "IMAP server", "POP3 server" are used instead of the correct "server supporting the XXX protocol" .
They're client protocols, so it still doesn't make sense. But have a look at mail/fetchmail, I think that might be the tool you're looking for.
 
Mdaemon is commercial software under Windows. hMailServer under Windows is opensource instead, and can be used for the same task mostly. It will not safe to Maildir though, but it's a local IMAP server regardless. So putting from Eudora on it is possible, and later downloading to another thing.

BTW there are command line tools around, which can convert MBOX files to Maildir directly, like that one:
 
Hi SirDice,

apart of the semantics difficulties, I believe that based on your and other people's responses, it is clear what I am trying to accomplish.

Hi hardworkingnewbie,

thank you for the suggestion. I am a little wary regarding the conversion tools, I used one in the past and it made a great mess. Fortunately, my paranoia, having saved about four copies saved the day. As I understand it, the Eudora MBOX is different form the UINX MBOX.

Hi Alain De Vos,

thank you for the suggestions.

Hi 6502,

hardworkingnewbie is correct, it is a paid server.

Kindest regards,

M
 
I would suggest dovecot, it's pretty easy to configure. As already has been mentioned, IMAP is able to store messages on the server, Idk if this a dovecot specific feature or part of the IMAP protocol, but it definitely works. After you got your Eudora and your dovecot working, just setup two imap accounts using Thunderbird and drag&drop your mails from the Eudora account to the dovecot account. From my experience (did that a few times my self back in the day) there is not really a limit of how many messages you can move, attachments are also fine. I assume you would be using a LAN for that "data transfer" so it will be quick as well.
 
The solely purpose of IMAP is to store your mails on a remote machine which you can access from everywhere you want to. That's the reason why we have IMAP, because before there was only POP3 which is simply "store and forward", but no remote access. So every IMAP server has email storage implemented one way or the other.
 
Hi tanis,

thank you for another dovecot recommendation. I have started looking into it, but since I have been only an e-mail client/web front end user, the setup appears rather difficult.

Why should I set up two accounts? My thinking was that I will synchronize the mailboxes in my Eudora client with the server via the IMAP protocol, and then download the messages from the server onto a local FreeBSD machine. Actually, I might not to do so if the server is running on the FreeBSD machine.

And, yes, I would like to use local network for the reasons mentioned in the fist message.

Kindest regards,

M
 
thank you for another dovecot recommendation. I have started looking into it, but since I have been only an e-mail client/web front end user, the setup appears rather difficult.

I configured dovecot for IMAP (but not POP) recently, so this might help some. If you're working on the local LAN and are willing to use plain text authentication, here are my notes for that part of the configuration. I need to go back and secure it, but it seems to work so far. I'd appreciate any corrections/advice.

Code:
# pkg search dovecot
dovecot-2.3.18                 Secure, fast and powerful IMAP and POP3 server
# pkg install -y dovecot
[...]
# pw useradd -n <USER> -m
# passwd <USER>
[...]
# cp -R /usr/local/etc/dovecot/example-config/* /usr/local/etc/dovecot
# sysrc dovecot_enable=YES
# cat /etc/rc.conf
dovecot_enable="YES"
# doveconf -a | more
# 2.3.18 (9dd8408c18): /usr/local/etc/dovecot/dovecot.conf
[...]
# doveconf -a | grep mail_location
mail_location =
# grep mail_location /usr/local/etc/dovecot/conf.d/*
/usr/local/etc/dovecot/conf.d/10-mail.conf:#mail_location =
# ee /usr/local/etc/dovecot/conf.d/10-mail.conf
[...]
# grep mail_location /usr/local/etc/dovecot/conf.d/*
/usr/local/etc/dovecot/conf.d/10-mail.conf:mail_location = maildir:~/Maildir
# doveconf -a | grep mail_location
mail_location = maildir:~/Maildir
# doveconf -a | grep protocols
protocols = imap pop3 lmtp
# doveconf -a | grep -A7 "inet_listener imap"
  inet_listener imap {
    address =
    haproxy = no
    port = 143
    reuse_port = no
    ssl = no
  }
[...]
# sed -n '12,13'p /usr/local/etc/dovecot/conf.d/10-ssl.conf
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
# ee /usr/local/etc/dovecot/conf.d/10-ssl.conf
[...]
# sed -n '12,13'p /usr/local/etc/dovecot/conf.d/10-ssl.conf
#ssl_cert = </etc/ssl/certs/dovecot.pem
#ssl_key = </etc/ssl/private/dovecot.pem
# doveconf -a | grep auth_mechanisms
auth_mechanisms = plain
# doveconf -a | grep disable_plaintext_auth
disable_plaintext_auth = yes
# grep disable_plaintext_auth /usr/local/etc/dovecot/conf.d/*
/usr/local/etc/dovecot/conf.d/10-auth.conf:#disable_plaintext_auth = yes
# ee /usr/local/etc/dovecot/conf.d/10-auth.conf
[...]
# grep disable_plaintext_auth /usr/local/etc/dovecot/conf.d/*
/usr/local/etc/dovecot/conf.d/10-auth.conf:disable_plaintext_auth = no
# doveconf -a | grep disable_plaintext_auth
disable_plaintext_auth = no
# service dovecot start
Starting dovecot.
[...]
# curl -v --url "imap://<IPADDR>/" --user "<USER>"
Enter host password for user '<USER>':
[...]
# tail /var/log/maillog
[...]

If the curl command works, create a new email account in your email client using these settings and you should be able to use the client to move emails from other accounts to the IMAP server. I'm planning to just use my local IMAP server as a permanent email archive rather than relying on additional software.

Type: IMAP
Server: <IPADDR>
Port: 143
Requires SSL?: No
Authenticate: Clear text
User: <USER>
 
Hi mefizto,

Just reread your posting, seems I caused some confusion. 😅

What I meant was, it takes just an additional IMAP account in your Eudora Mail Client and then drag&drop all your messages from the former account to the later. Dovecot will do the "heavy lifting" in terms of creating a file for each mail (aka maildir format). This is all based on the assumption that Eudora supports "Drag&Drop" or "Move/Copy" messages around and therefor across different accounts. My experience is based on the client side on Thunderbird, Alpine and IMAP accounts.

Configuration wise:
You can almost use the sample configuration, reading the sample commets should be enough to get this up and running in an hour or two. :-/

Regards,

tanis :)
 
Hi tanis,

as much as I appreciate your answer, it made me even more confused. It is nothing new, as my middle name has always been "Confused". ;)

I still do not understand the two accounts. In the past, when I wanted to archive my Gmail account I did the following. Synchronized the account running on a client with the Gmail server. Set up mail/fetchmail to connect to the Gmail server and target a drive on a different machine.

Taking the above to the current situation, the client is equivalent to Eudora which keeps all the messages and attachments. The equivalent to the Gmail server is dovecot. So, why cannot I again set up mail/fetchmail, connect to the dovecot server and target a drive on the FreeBSD machine or another client supporting maildir?

Or, am I misunderstanding and you are proposing a different way of doing the transfer?

You seem very optimistic about my abilities. I spent the day yesterday reading dovecot documentation: https://doc.dovecot.org/, and got even more confused, see above. Admittedly, I am rather paranoid and would like to understand what I am doing instead of just blindly accept the defaults.

Kindest regards,

M
 
Let me take a crack at explaining this in simple terms.

There are (mainly) two kinds of software for handling Internet email. One kind transfers messages from a sender to a recipient. These are called "Mail Transfer Agents" or MTAs for short. Examples are Sendmail and Postfix. The other kind is used for reading received messages, and is called a "Mail User Agent" or MUA. Examples are Eudora and Thunderbird.

Back in the old days, the message store the MUAs used was very simple. It was just a text file in the user's home directory with all the emails in it in a plain text format. This is the mbox format many MUAs use to this day. The MTA in those days was almost always Sendmail. It would examine messages it received to decide if they belonged in the same host as Sendmail, or if they needed to be passed on to a different MTA for further handling. The first case is called "local delivery" and it was as simple as appending the message to the user's mbox file. The second case is mail forwarding, which can get complicated so I won't discuss it further.

This was fine and good as long as everyone read their email using Mutt in their shell account on some large university Unix server. Along came PCs and the first complications arose. PCs were simply too dumb to run a MTA. You needed a way of getting the user's mbox file from the Unix server running Sendmail to the user's PC running Windows or OS/2 or something. This is led to the birth of the POP protocol. A POP server runs on the Unix machine and serves up the user's mbox file. MTAs like Eudora and Pegasus started to support network connection to POP servers. What they did was after connecting was very simple. They'd download the message to the local system and append it to an mbox file. The mail store didn't change.

The first iteration of the POP service would delete the messages on the Unix server after they were downloaded to the client. This was all fine and good as long as people had a single computer. Along came laptops and folks realized they could not read the email on their desktop from their laptop (yes, having two machines was common back in those days.) Worse, if you ran a POP client on your laptop, it would download the latest messages and delete them. These messages would be subsequently inaccessible from the desktop.

The POP protocol gained the ability to leave messages on the server to work around this problem. IMAP, which leaves the messages on the server by default, also arose around this time. Things were good until people's email inboxes started to get huge 'cause no one ever reads all their email. Disk storage was expensive back then, and exponentially more expensive on server systems than on cheap PC desktops or laptops. MUAs gained the ability to have "local folders" which were simply mbox files on the local system that were not copies of what was on the POP/IMAP server. You could move email from your server account to your local folders to free up space on the server, but not have to delete any messages.

If I understand your situation correctly, you have a local message store in mbox format, and you want to change it into another local store in maildir format?

Attention pedants! I wrote this from memory. The chronology is likely incorrect. The motivations for the development of features and protocols are probably also incorrect. I'd spend a couple of days researching if I was going to submit this to a journal or something.
 
Hi Jose,

first, thank you for the history lesson, it filled some gaps in my yesterday's mad reading on the topic of e-mail.

And yes, you understand correctly. I had backed up all my e-mail as well as had kept executable of the MUA - Eudora I had used. I re-installed Eudora together with its MBOXes - per your description - the "local folders", to keep access to the e-mails and associated adresses. However, since Eudora is no longer developed/supported and I am moving away from Windows 7, I am concerned that I might lose access to the e-mails.

Unfortunately, Eudora's MBOX format is different form the standard MBOX format; furthermore, the messages' attachment are stored apart from the messages themselves in a common "Attach" folder. Consequently, none of the conversion utilities I had tried in the past worked. Hence my idea of using an intermediary IMAP server, which will do the "conversion" automatically. I settled on the maildir format mainly because of the excellent mail/notmuch tagging and search engine.

Kindest regards,

M
 
And yes, you understand correctly. I had backed up all my e-mail as well as had kept executable of the MUA - Eudora I had used. I re-installed Eudora together with its MBOXes - per your description - the "local folders", to keep access to the e-mails and associated adresses. However, since Eudora is no longer developed/supported and I am moving away from Windows 7, I am concerned that I might lose access to the e-mails.
Can you connect to a POP/IMAP server using this old version of Eudora?

Unfortunately, Eudora's MBOX format is different form the standard MBOX format; furthermore, the messages' attachment are stored apart from the messages themselves in a common "Attach" folder. Consequently, none of the conversion utilities I had tried in the past worked. Hence my idea of using an intermediary IMAP server, which will do the "conversion" automatically. I settled on the maildir format mainly because of the excellent mail/notmuch tagging and search engine.
That's a cool project. They point at an mbox mailbox converter, BTW. I'm going to guess it's not going to work for you because of the funky Eudora extensions to the format. It looks like your only option is to connect Eudora to an IMAP account and manually drag and drop the emails to it. Sounds like a real bummer, but all the converters I can find are proprietary and convert to hideous things like Outlook format.

Some pages I found interesting that you've potentially already found as well:
 
Let me take a crack at explaining this in simple terms.

There are (mainly) two kinds of software for handling Internet email. One kind transfers messages from a sender to a recipient. These are called "Mail Transfer Agents" or MTAs for short. Examples are Sendmail and Postfix. The other kind is used for reading received messages, and is called a "Mail User Agent" or MUA. Examples are Eudora and Thunderbird.
Don't forget about the MDA, Mail Delivery Agent. This is the piece of software which stores the email in the required format by IMAP/POP server.
 
Hi Jose,
Can you connect to a POP/IMAP server using this old version of Eudora?
I believe so, since the IMAP was used. I am actually trying with my e-mail provider now, just to check, whether it will work as I am still not comfortable to use such a provider.

I'm going to guess it's not going to work for you because of the funky Eudora extensions to the format.
Nope.

Some pages I found interesting that you've potentially already found as well:
I actually met Steve Dorner, as we worked for the same company.

Kindest regards,

M
 
Hi mefizto,

I took from your post the following:

Eudora - mail client which has been used to locally backup mails in an Eudora specific mbox format. The backup can be accessed through Eudora mail client.

The objective is to convert these Eudora backups to the mail dir format.

My proposed solution is :

1) Setup an IMAP server ( e.g. dovecote) for this purpose only.

2) Add that IMAP account to your Eudora mail client which can access your backups.

3) Transfer your messages from your backup to IMAP account using Eudora mail client. Usually “Drag&Drop”.

Clarification about the “second account”: I refer to the backup as the “second account”, because that’s how the mail client had let me access my backup back in the day. I have never used Eudora, as my experience is based on Thunderbird and alpine.

Sorry for the confusion.

Regards,

tanis 😊
 
Hi tanis,

thank you for the clarification, all is understood now.

Hi chrbr,

thank you for the recommendation. However, as I noted not only is the Eudora's MBOX format non-standard, but so are also the headers, which appears to contribute to the failure of most of the available MBOX to maildir converters. As per my summary below, I am pursuing the dovecot path because (i) it seems that using a server to do the "conversion" is the cleanest manner and (ii) there seems to be several people on the forum, who are using dovecot, so perhaps they will be willing to help.

Greetings all,

I made some progress yesterday. First, based on Jose's concern, I set up Eudora to use IMAP to connect to one of the commercial providers. I then "dragged and dropped" a folder that has no private information and its attachment to the server and saw it on the server. I then e-mailed the server from my other account and was able to see the e-mail arriving.

Encouraged by the result, I re-read about hundreds of times ccammack's instructions, but instead of just blindly following them, I did locate the variables to be set in the relevant files (there are many of them) and set them. Of course, I made some mistakes, but with his generous help via p.m., I was able to correct the configuration errors preventing the dovecot to start.

I leaned form searching that people use telnet to test the server and I received a response:
Code:
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ START TLS AUTH=PLAIN] Dovecot ready."
which appears to indicate a working server. However trying to log in: a login username password resulted in:
Code:
NO [AUTHENTICATION FAILED] Authentication failed.
just like about million people are reporting.

I searched a little, it was really late, but so far have not found a solution. So, I was wondering if someone, especially the people of the "dovecot is not difficult to set up" persuasion, could look at my doveconf -n to spot any problem:

Code:
disable_plaintext_auth = no
first-valid_uid = 1000
listen = *
mail_location = maildir:~/Maildir
mbox_write_locks = fcntl
nmap_diable = yes
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    special_use = \Trash
  }
  prefix =
}
passdb {
  driver = bsdauth
}
protocols = imap pop3 lmtp submission
service imap login {
    inet _listener = imaps {
    ssl = no
    }
}
userdb {
  driver = passwd
}

Interestingly, although I have set
Code:
auth_mechanisms = plain
in 10-auth.conf it does not show in the configuration. May that be a problem?

Kindest regards,

M
 
I'm not a fan of these multifarious teeny config files scattered across subdirectories. I configure my Dovecot with a single /usr/local/etc/dovecot.conf, reproduced here with some light edits:
Code:
ssl = yes
ssl_dh = </usr/local/etc/dovecot/dh.pem
ssl_cert = </usr/local/etc/ssl/my.domain.cert
ssl_key = </usr/local/etc/ssl/private/my.domain.key
mail_location = sdbox:~/.mail
userdb {
  driver = passwd
}
passdb {
  driver = pam
}
auth_mechanisms = plain login
service auth {
  unix_listener /var/spool/postfix/private/auth {
    user = postfix
    group = postfix
    mode = 0660
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    user = postfix
    group = postfix
    mode = 0600
  }
}
protocol imap {
  mail_max_userip_connections = 100
}
protocol lmtp {
  postmaster_address = postmaster@my.domain  # required
  auth_username_format = %Ln
}

I use plaintext auth over a TLS connection. Note that you'll have to change the mailbox configuration. I use the dbox format. You want maildir, so preserve your mail_location = maildir:~/Maildir config line.

Edit a wild stab at an untested config that may work for you:

Code:
maildir:~/Maildir
auth_mechanisms = plain login

userdb {
  driver = passwd
}

passdb {
  driver = pam
}
 
protocol imap {
  mail_max_userip_connections = 100
}
 
Hi Jose,

thank you for your attempt to help going as far as posting your dovecot.conf file.

The problem that I have is that I have looked at literally tens of configurations, each of them different. That, of course, makes sense since different posters have different requirements/goals. However, doing so, I have not found a single one, where the reasons for the configuration was explained in logical and understandable fashion, e.g., how do all the myriads of configuration files work together, how they can be replaced by a single configuration file, etc. Compare this this with e.g., the following article about mail/opensmtp: https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/, even I can understand it.

Furthermore, most are combining dovecot with an outgoing server, different manner of authentication, and the like. If I do not install an outgoing server, will the configuration work? The authentication is another layer, where a mis-configuration can happen.

So, to conclude, I am afraid that the project is way above my abilities. As such, my only recourse is to keep the Windows 7 hardwae running as long s possible and the lose the access to the e-mail. C'est la vie.

Again, thank you everybody for your attempt to help.

Kindest regards,

M
 
Back
Top