Sendmail+Dovecot carry over

L

lucas1

Good day.

Now Sendmail+Dovecot working for Fedora33.
For certain reasons, I would like to transfer to FreeBSD.

The question concerns, of course, the transfer of accounts (adding) to passwd FreeBSD.
And transferring the contents of mailboxes.
But on the source server, the mailboxes are not in /var/mail
And not in the form of a single file.

Mailboxes in /home/%user% and in the form, each message is a separate file.
To sendmail added use procmail.
Used IMAP and in each mailbox besides the main set directories /cur /new /tmp
there are users folders IMAP with /cur /new /tmp .

Is it possible to convert a mailbox to a view /var/mail?
 
I don't have full knowledge, but with imap the data get stored in the users directory.
So if they all sync. ALL the data is in /usr/home/ ...xxx... /Mail/
Then you must just make the sendmail users. That is outside my knowledge domain. virtusertable ?
 
leave the mailboxes in Maildir format
use mutt to read mail locally (instead of mail(1) which sucks anyway)
after installing dovecot change sendmail.cf to use local delivery agent provided by dovecot
Code: 
Mlocal,        P=/usr/local/libexec/dovecot/deliver, F=lsDFMAw5:/|@qSPhn9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL,
        T=DNS/RFC822/X-Unix,
        A=/usr/local/libexec/dovecot/deliver -d $u
its best not to hack sendmail.cf directly but use sendmail.mc
i believe dovecot docs provide the modifications you need do make to sendmail.mc (from which sendmail.cf is build)

LE
this works if users are real system users (in /etc/passwd) not virtual account held in ldap/sql/etc
 
1. There are several hundred accounts on Fedora. Do not transfer them manually. This is a last resort.
I wanted to somehow automate the process.

2. I have a mail server on FreeBSD with a non-primary mail domain.
On him mailboxes in /var/mail.
In /home/%user%/mail/.imap - folders imap here.
In each there are only two files in each of them - dovecot.index.cache and dovecot.index.log.
There is no mailbox content here.

It turns out how to collect individual mail messages from all folders /cur to /var/mail/"single file"?
 
Code: 
cd ~/Maildir/cur;for i in *;do d=$(date -j -r ${i%%.*});echo "From a@a $d" && cat "$i";done >/tmp/mboxtest
this creates a usable mbox from the "cur" part of Maildir
the envelope sender is BS but it looks like mutt ignores that infoa anyway
 
that should be easy to script
if you care for just username and password and ignore all other fields you can just use the shadow file from fedora

Code: 
cut -d: -f1,2 /etc/shadow|while read a;do u=${a%:*};p="${a##*:}";[ ${#p} -le 2 ] && continue;echo echo "'$p' |" pw useradd "$u" -s /sbin/nologin -d /home/$u -m -H0;done

this will create a script to run on fbsd
 
For IMAP there's also mail/imapsync or mail/imaptools. If you sync via IMAP the underlying mailbox structure is completely irrelevant. Just set up the new mailserver and user accounts, then sync every account over from the old server. If you scripted the user migration, you already have a list of all users/accounts, so you can feed those to imapsync.
Theres one caveat though: you need the login credentials for all accounts; but you could simply replace them with a temporary password for the synchronisation process and restore the original /etc/passwd afterwards. This way users never have to give away their credentials and nobody else (you) has to handle them in plaintext.

On the receiving (new server) side you could either do the same by copying over the /etc/passwd contents, or do The Right Thing™for a mailserver and migrate all users to virtual users in a database (IMHO no user should _ever_ have ssh access to a mailserver anyways) and force them to set a new password. Then you could possibly also take this chance to enforce a proper password policy....

To ease future migrations/expansion - apart from migrating local to virtual users - I'd highly suggest changing to a proper maildir-structure under /var/mail, preferably on a separate zfs dataset (or even per-maildomain or per-user datasets).
FTR: Yes, You *could* mix local and virtual users (at least with postfix this is possible, e.g. by optionally using PAM for login and reading the transport method from the user database or a file in the users home), but this usually gets very messy and error-prone.
 
Additionally you should really consider moving your hundreds of accounts over to another authentication solution, like LDAP or SQL RDBMS. Having hundreds of accounts lingering around just for mail access is really a bad practice.

Also all these users should just share the same UID and GID, like vmail.
 
hardworkingnewbie said:
Additionally you should really consider moving your hundreds of accounts over to another authentication solution, like LDAP or SQL RDBMS. Having hundreds of accounts lingering around just for mail access is really a bad practice.

Also all these users should just share the same UID and GID, like vmail.
Click to expand...
+1

Although I'd like to add the suggestion to handle athentication through a single mechanism like SASL. You could let your MTA and MDA both directly query the user DB (whether it be LDAP or some SQL DB), but its much easier and cleaner to maintain only a single single service that queries the DB and tightly lock down the server/jail that holds the user-DB (which has to be considered the most high-profile target of your whole setup!).
Dovecot has its own SASL-implementation that is supported by a lot of other software - this way you can authenticate the users via one centralized mechanism and database (i.e. we use dovecot-SASL also for horde groupware, nextcloud and the web-conferencing of our phone system) and only have to grant dovecot access to the user-DB, ideally over a loopback interface that is inaccessible from the outside world.
 
Dovecot is even able to use Sqlite as storage engine for SASL. As long as there's not much going in terms of many concurent logins happening on the same time, this should be more than enough for that use case. No need to run MySQL/Postgres then, if it's not already being used for some other stuff and up and running.
 
You must log in or register to reply here.
Back
Top