boltblog

When configured to send all mail through a smarthost, exim4 on Debian will not respect your /etc/aliases file, nor will it care about your users’ ~/.forward files. This is due to the numbering, and consequently the sorting, of the files in /etc/exim4/conf.d/router/.

If you look at 200_exim4-config_primary, you’ll see it handles smarthost routing in smarthost and satellite mode, and that it ends with “no_more”. This means any routes following it will only apply to the local_domains list. Thus, 400_exim4-config_system_aliases and 600_exim4-config_userforward will not be processed for outgoing mail. Not what I want.

To get around this without moving the default files around, I concatenated both the mentioned files into a file called 175_cathedral-config_system_aliases and modified it to apply to the qualify domain. You can name it whatever you want, as long as it starts with a number in between 150 and 200.

Make sure you’ve got your config (dpkg-reconfigure exim4-config) set to “Split configuration into small files”, add your custom file, then run update-exim4.conf and restart exim4.

This is the resulting file, if you just want to copy and paste it:

.ifdef DCconfig_smarthost DCconfig_satellite

cathedral_aliases:
  debug_print = "R: cathedral_aliases for $local_part@$domain"
  driver = redirect
  domains = $qualify_domain
  allow_fail
  allow_defer
  data = ${lookup{$local_part}lsearch{/etc/aliases}}
  .ifdef SYSTEM_ALIASES_USER
  user = SYSTEM_ALIASES_USER
  .endif
  .ifdef SYSTEM_ALIASES_GROUP
  group = SYSTEM_ALIASES_GROUP
  .endif
  .ifdef SYSTEM_ALIASES_FILE_TRANSPORT
  file_transport = SYSTEM_ALIASES_FILE_TRANSPORT
  .endif
  .ifdef SYSTEM_ALIASES_PIPE_TRANSPORT
  pipe_transport = SYSTEM_ALIASES_PIPE_TRANSPORT
  .endif
  .ifdef SYSTEM_ALIASES_DIRECTORY_TRANSPORT
  directory_transport = SYSTEM_ALIASES_DIRECTORY_TRANSPORT
  .endif

cathedral_userforward:
  debug_print = "R: cathedral_userforward for $local_part@$domain"
  driver = redirect
  domains = $qualify_domain
  check_local_user
  file = $home/.forward
  require_files = $local_part:$home/.forward
  no_verify
  no_expn
  check_ancestor
  allow_filter
  forbid_smtp_code = true
  directory_transport = address_directory
  file_transport = address_file
  pipe_transport = address_pipe
  reply_transport = address_reply
  skip_syntax_errors
  syntax_errors_to = real-$local_part@$domain
  syntax_errors_text = \
    This is an automatically generated message. An error has\n\
    been found in your .forward file. Details of the error are\n\
    reported below. While this error persists, you will receive\n\
    a copy of this message for every message that is addressed\n\
    to you. If your .forward file is a filter file, or if it is\n\
    a non-filter file containing no valid forwarding addresses,\n\
    a copy of each incoming message will be put in your normal\n\
    mailbox. If a non-filter file contains at least one valid\n\
    forwarding address, forwarding to the valid addresses will\n\
    happen, and those will be the only deliveries that occur.

.endif

EDIT:
I thought I’d mention that the “exim -bt” command, or “exim -d -bt” for more details, is great for testing this kind of thing without actually sending emails.
Run exim -d -bt foo@bar.com and see what happens.

EDIT2 (2021-09-18):
Note that on Bullseye and above, the “require_files =” directive uses $local_part_data in place of $local_part, as seen in 600_exim4-config_userforward.

sshfs is a neat way of mounting a file system from one machine to another over an encrypted ssh channel. However, for machine CLIENT to access a file system that resides on machine HOST, CLIENT must generally be able to log in to HOST. In addition, CLIENT must be able to connect to HOST in the first place, though a tunnel from HOST to CLIENT can easily mediate this if a connection can only be initiated in that direction.

However, the login itself may still be an issue. You might not want to type your password for HOST on CLIENT, or set up a keyless login using public/private keys. You might not entirely trust CLIENT, from which you want to access the file system.

dpipe to the rescue.

Using dpipe, available in the “vde2” package on Debian (and, likely, derivatives), you can initiate the connection the other way and use sshfs in “slave mode”, in which it communicates over standard input and output instead of an SSH connection directly.

Consider this is what you’d normally do:

sshfs YOU@HOST:/mnt/host/path /mnt/client/path

.. from CLIENT

Instead, you can do:

dpipe /usr/lib/openssh/sftp-server = ssh CLIENT sshfs :/mnt/host/path /mnt/client/path -o slave

.. from HOST!

Add any options you want as usual, and you’ve got a reverse SSHFS mount.

One cautionary note: While this setup allows you to initiate the connection from HOST, keeping your login details for HOST private, it will likely still allow for clever people to access the entire file structure of HOST as the client initiating the connection, the same as could happen if you initiate the connection from CLIENT. Thus, some trust in CLIENT is still required, though perhaps considerably less trust than you’d need to do the connection as per usual.

Have fun!