The M68k/Buildd account needs to be able to send and receive email. This page has some configuration ideas if the stock email solution does not work for your situation.

uucp over ssh

Sometimes the solution to a problem such as routing email is to go old school. You can deliver email using uucp over ssh. Hopefully someone will document something a little newer, but for now, this works.

Install uucp on both the client and server apt-get install uucp. You can setup both the client and the server to transfer mail on demand or by polling. This faq is going to cover push/push (both machines act as clients and servers). This works pretty well for buildds because they usually already have a working ssh client and server.


You will need to generate a password-less ssh key for uucp.

sudo -u uucp ssh-keygen

Replace $server with the hostname of the mail server (server=$(hostname)). $client needs to be distinguishable from $server, so I use the client hostname plus "in" (e.g., client=$(hostname)in). Replace $password with some password (i.e., makepasswd).

Think of this as what username ($client) and $password to use when contacting $server.

$server $client $password

Tell uucp to use ssh.

port sshport
type pipe
command /usr/bin/ssh -x -o batchmode=yes $server

system $server
call-login *
call-password *
time any
address $server
port sshport
protocol t
remote-send /var/spool/uucppublic
remote-receive /var/spool/uucppublic

Optionally map the common name you are using for the server to the fully qualified domain name.

Host $server
    Hostname $


$server, $client, and $password should match as appropriate from the client.

$client $password

Allow the client to use the system.

system $client
time any
port tcp
protocol t
remote-send /var/spool/uucppublic
remote-receive /var/spool/uucppublic
commands        rmail rnews rbsmtp rsmtp cbsmtp rcsmtp rgsmtp

You will need /var/spool/uucp/.ssh/ from the client.

command="/usr/lib/uucp/uucico -l" ssh-rsa uucp_public_key uucp@client

Preparation and Testing

Note that you have to run through the above configuration twice (each host is both client and server) if you're going to pass mail both directions on demand (i.e., immediately when available).

To make sure everything is now working.

sudo -u uucp ssh $server

You should get a uucp Login prompt, which you can then Control-C out of.


You may want a cronjob that calls "/usr/lib/uucp/uucico -C -S$server" periodically. I use this method of machines that are only occasionally connected to the internet.

You can also setup your mta to make that call whenever mail is pending. uux is your friend here. If you're using postfix you do that with the following. Note that the only change between the following and the Debian default is removing '-r' from the uux command. If you want to transfer mail outside of mta control (say, under cron or whatever), leave the uux -r.

uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -n -z -a$sender - $nexthop!rmail ($recipient)

I also use postfix transport_maps.

transport_maps = hash:/etc/postfix/transport

The following asterisk may be replaced with just a servername if you only want to route some mail over uucp.

* uucp:$server

Do not forget to postmap /etc/postfix/transport after you are done.

Buildd Procmail Recipe

The buildd account really only care about certain formatted messages. Everything else is spam to it. Since many of my buildds are hidden behind a mail gateway, I map an account on the mail server and use a procmail recipe to filter out invalid mail before it ever goes to the buildd. Substitute $BUILDDMAIL with the real delivery address for the buildd account.

.procmailrc:# Set to yes when debugging

# Remove ## when debugging; set to no if you want minimal logging

# Directory for storing procmail-related files

# Put ## before LOGFILE if you want no logging (not recommended)




# excerpted from buildd-mail
* ^Subject: Re: Log for .* build of |\
  ^Subject: Re: Should I build |\
  ^Subject: Processing of |\
  ^Subject: .*changes INSTALL|\
  ^Subject: .*changes ACCEPTED|\
  ^Subject: new version of

# maybe you want a copy of all spam sent to the admin
#:0 c

If you are using a log file like the above, you may wish to periodically roll it with savelog -p $HOME/.procmail.d/log >/dev/null or logrotate.