Pasky’s Log

I don’t send email from my notebook often, dealing with my correspondence on my server machine via ssh. When I need to do it, it’s usually when I’m sending Git patches or something like that. I didn’t meet much trouble with sending it directly, but SMTP servers of Debian-involved people are some of the most picky one can meet and I decided it’ll be best if I switch the exim4 on my notebook to smarthost mode where all mail is relayed via my main server.

So that should be trivial to do, right? Wrong, apparently. I figured I’d use SMTP auth, but it just seems mind-bogglingly complicated to configure if you don’t want to spend an evening on it. The client part is fairly easy (probably both on exim4 and postfix), but setting up postfix server to do SMTP auth (for just a single person) is really silly stuff. Maybe not so crazy if you use PAM / shadow for authentication, but that means that on my notebook, I’d have to store (in plaintext) my server password anyone could use to log in – no way. It seems I could switch to Dovecot and somehow pass it a simple password to use, but at that point my patience ran out and I just backed off a litle.

Why not just use ssh for smarthost SMTP transport? Authentication via ssh is something everyone understands nowadays, it does the best job there, no silly passwords involved and you can just pipe SMTP through it. You wouldn’t do that at in a company setting with Windows notebooks, but for a single geek, it seems ideal.

Someone already did set up ssh as exim transport, but that’s for exim3. So here follows a super-quick HOWTO to do this with exim4:

• Set up ssh key on client:

  sudo -u Debian-exim /bin/bash
  ssh-keygen # go with the default, and empty password, this will be used in an automated way
  ssh me@server.example.org # to fill up known_hosts; it will fail yet
  cat ~/.ssh/id_rsa.pub # this is my public key
  exit # ..the sudo
  

• Set up ssh key on server – paste the public key printed by the cat above to ~me/.ssh/authorized_keys and prepend command="nc -w1 localhost smtp",no-agent-forwarding,no-port-forwarding,no-X11-forwarding to the key line. This key can now be used only for mail relaying.
• Do dpkg-reconfigure exim4-config and configure smarthost mode. Also use it to find out whether you are using split or big configuration. You will also probably want to enable “mailname hiding”, otherwise your return-path will contain an unroutable address.
• Set up ssh transport in exim4 – add the following to the config file:

  ssh_pipe:
    debug_print = "T: ssh_pipe for smarthost delivery"
    driver = pipe
    path = "/bin:/usr/bin:/usr/local/bin"
    command = "ssh me@server.example.org nc -w1 localhost smtp"
    use_bsmtp
    message_prefix = "HELO mynotebook.example.org\r\n"
    delivery_date_add
    envelope_to_add
  

  (it would be nicer if we used the actual smarthost configuration option value and our notebook’s hostname instead of hardcoded strings, I guess).

• In the smarthost: section of the configuration file, replace transport = remote_smtp_smarthost with transport = ssh_pipe.
• /etc/init.d/exim4 reload and voilá, sending mail from anywhere should work now!

I *wish* setting up roaming SMTP nodes would be way easier nowadays and I wouldn’t have to eventually spend about 90 minutes on this stuff…

screenenv is a gadget that should make your applications within GNU Screen use the right display and ssh agent information based on which attached screen client you call them from.

The motivation is simple – I have screen session that I create on my desktop, but when on the go (or in the next room ;) with my notebook, I want to ssh -X in and be able to still open image attachments in my mutt properly.

Several approaches are possible, I chose a fairly invasive one – I hijack getenv() calls by applications and substitute few chosen environment variables (mainly $DISPLAY and $SSH_* – e.g. $SSH_AUTH_SOCK) based on their settings in the most recently active screen client attached to the current session.

Thus, you can just keep going back’n’forth between two sessions, keep working seamlessly, no explicit action is required on your part and all your applications will Do The Right Thing.

Of course, the v0.1 release has many rough edges – if a long-term application saves the getenv’d variable, then keeps checking other volatile ones, it will probably crash (that’s fixable, though; and I think this should be very rare situation in practice, most or all of the volatile variables are for one-shot use within a single process). Also, we should cache the client lookup (which involves walking all processes) at least for few seconds…