assimilating a new (to us) imac: SMTP mail

So the mac mini is almost a teenager so we got a new box. According to "About this Mac" it's "iMac (retina 5K..., 2019)" running macOS Monterey 12.0.1. I need to get dovecot on it, among other things.

<…time passes…>

OK that was... October maybe? I moved "all" the files with either scp or rsync, upgraded to Ventura, installed crashplan for small business and told it to back up Carol's files (and to stop backing up the old mac mini). Carol's been using the new machine to good effect for a few months now, but I'm still using the mini to fetch SMTP mail from my ISP. The setup is byzantine, and in case I'm still using that email when we replace the 2019 iMac, I'll record how it handles smtp mail for my future self.

Fetching the mail here

The mini runs a "service"... I thought we could "fetchmail -d 60" but how to send password encrypted? It would certainly be bad medicine authenticating in cleartext!

The solution involves an ssh tunnel and a macos "service." Apparently if you put an XML file named somethign.plist in /System/Library/LaunchDaemons/ then macos will run it as root on startup. Mine looked like this:

unknownc42c0321f10e:~ admin$ cat /System/Library/LaunchDaemons/collin.admin.tunnel.plist         
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
		<string>collin.admin.tunnel</string>
	<key>Program</key>
		<string>/Users/admin/tunnel.sh</string>
	<key>RunAtLoad</key> 
		<true/>
</dict>
</plist>
unknownc42c0321f10e:~ admin$ 

OK actually on the mini the username was "postman"; on the imac it'll be "admin" so I'm changing it here.

OOPS... on the iMac, running Ventura, we can't touch /System/Library/LaunchDaemons; instead I had to add the above as /Library/LaunchDaemons/collin.admin.tunnel.plist; I hope it works.

What does /Users/admin/tunnel.sh do? It establishes a tunnel to my ISP, making localhost port 60110 tunnel to the POP server's port 110 for about a minute or two. Then it runs fetchmail. Like this:

#!/bin/bash
ID=$(id -u)
if [[ $ID == 0 ]] ; then
    echo /Users/admin/tunnel.sh | su - admin
    exit 0
fi
PATH=$PATH:/usr/sbin:/opt/local/bin:/usr/bin:/bin
while :; do
        if netstat -an -finet|grep LISTEN | grep 60110 > /dev/null; then
                : be happy
        else
                ssh -f sonic -L 60110:pop.sonic.net:110 sleep 120 & >/dev/null
        fi
        sleep 30                # That should be long enough to open socket
        fetchmail --sslproto "" >> tmp/fetchmail.log 2>&1 &
        FPID=$!
        sleep 120
        kill $FPID
        sleep 10
done

I had a little surprise with the .fetchmailrc: I can't say

poll localhost proto pop3 port 60110 user ISP-username pass ISP-password is admin here fetchall mda "/usr/bin/sendmail -i -f %F %T"

because procmail won't let me fetch from localhost. So I have a hack in /etc/hosts:

127.0.0.1       localhost see.admin.fetchmailrc.invalid

and now fetchmail can, well, fetch the mail.

AND ANOTHER THING... I never used to have to say “--sslproto ""” but it now seems necessary lest I get some SSL error.

Once the mail gets here

… sendmail (or maybe postfix) will try to deliver it, probably to /var/spool/mail/WHATEVER. But we don't want that, so we have to supply a .forward file:

admin@Admins-iMac-2 ~ % cat .forward                                                           
"|/opt/local/bin/procmail"
admin@Admins-iMac-2 ~ %                                                                        

And a .procmailrc, which tries to figure out who the email is addressed to. If there's a header that says
To: collin@<ourdomain>
then that's easy; it's addressed to me.

But what if there's no header like that? What if I'm bcc:-ed? Basically we look for a useful Received:  header. Anyway, the point is, admin's .procmailrc file tries to figure out who the email is for, and then it sends the email to Carol or to me, or to the bit-bucket. It sends the email to us by running /usr/sbin/sendmail, so if I want email processed by procmail, I again have to have a $HOME/.forward, just like "admin" did. And my own $HOME/.procmailrc.

Other stuff

I have to run dovecot on the iMac, but only for Carol's email. She hasn't looked at it for months now, so when she decides to have a look, I'll probably have to figure out how to run dovecot on it.

As for me, I'll nfs-mount $HOME/Maildir from the iMac onto my linux box, which is where I read non-web email. The iMac wasn't exporting any filesystems when we brought it home, so I just did what came naturally: copy /etc/exports from the teen-aged mac mini:

admin@Admins-iMac-2 ~ % cat /etc/exports                                                       
/Users  -network 192.168.1.0 -mask 255.255.255.0

I'll mount that and symlink Maildir there to $HOME/Maildir on the Linux box.

Then I think I should remove /System/Library/LaunchDaemons/collin.postman.tunnel.plist from the mac mini... oh, wait, no, I don't have to do that; I can just make the script do nothing I think.

Then rsync to make the iMac's copy of $HOME/Maildir match the mac mini's copy... for both Carol and me

Admins-iMac-2:~ carol$ time rsync -av 192.168.1.131:Maildir ./
receiving file list ... done
Maildir/
Maildir/log
Maildir/msgid.cache
Maildir/new/
Maildir/new/1673726769.51227_2.unknownc42c0321f10e.attlocal.net
Maildir/new/1673737810.52745_2.unknownc42c0321f10e.attlocal.net
Maildir/new/1673746452.53955_2.unknownc42c0321f10e.attlocal.net
Maildir/tmp/

sent 66405 bytes  received 520272 bytes  7287.91 bytes/sec
total size is 675278927  speedup is 1151.02

real	1m20.414s
user	0m0.292s
sys	0m0.200s
Admins-iMac-2:~ carol$ 

Mine will take rather longer I think...

Then install