simont | (no subject)

I've recently had my PC replaced at work, and they've given me a Linux box. Owing to trust issues, I'm not currently able to NFS-mount my mail spool on this machine, so I'm investigating POP-3 alternatives.

Clearly typing my password into my mailer every time I want to check my mail is ludicrous; and yet, equally clearly, storing it in a file is just as bad. So I've written a POP agent, a bit like an SSH agent: it's started from my .xsession and its lifetime is that of my session, and it listens on a Unix domain socket and forwards connections from that socket to the local POP server. The trick is that it never requires authentication within the POP connection (you can provide it if you like and it'll be cheerfully ignored); instead, the first time it forwards a connection, it puts up an X window asking for my POP password, and then it caches that in memory for the rest of my session.

So far, so good. Where things start getting annoying is that xbiff-type programs don't generally seem to be able to deal with this. The GNOME standard mailcheck applet comes closest - it speaks POP3 and has a place you can type a username and password - but it doesn't look easy to convince it to connect to a Unix socket instead of a TCP one (and who can blame it?), and even working round that with LD_PRELOAD looks tricky because as far as I can tell it's an integral part of a big GNOME binary and not a standalone executable.

xbiff looks like the next best bet: it allows you to specify a command which is run to poll a mailbox. Unfortunately the command has to be stateful! It has to return 0, 1 or 2 depending on whether the mailbox contains more, the same, or less mail than last time it was called. Arrrgh.

Implementing a small POP client which calls STAT and saves the last result in a file seems like a horribly grotty solution - I mean, a file to save this sort of state? Ick. So as I've got a persistent POP-related program running already, I instead chose to pile yet more state into the POP agent: I've invented new POP commands MC_NSTAT ("call STAT and save the result"), and MC_OSTAT ("tell me what the last saved STAT result was"). So my mailcheck program calls MC_OSTAT and then MC_NSTAT, compares the results, and then has exactly the information it needs to tell xbiff. And even as I type this, xbiff is sitting in my GNOME control panel and working beautifully.

The thing is: while every individual decision in the above story made sense to me at the time, I look back on the result now and can't help wondering whether it was really the sensible way to do any of this. Ersatz extended versions of POP3 running over Unix domain sockets? A stateful server process running throughout my session which keeps track of when I last had new mail? For goodness' sake. You couldn't make that sort of thing up.

Anyone want to suggest how I could have done all this more simply? I'm sure I can't be the only person who wants to use POP for this sort of purpose...

Flat | Top-Level Comments Only

The fact that you're already doing Xish stuff in your server makes me wonder if it wouldn't be more sensible to build the whole xbiff functionality into it.

Alternatively can you run the xbiff on a machine which is allowed to see the mail spool directly?

pop-agent isn't doing X intrinsically; it's spawning an xterm to ask for the password. (At some point I hope to switch this to ssh-askpass, but when I originally wrote pop-agent it was running on a machine that didn't have that installed.)

If it were doing X internally it would be ten times as ghastly a program as it already is! :-)

Remote xbiff would be a solution, I suppose, but somehow I don't like the idea of having remote programs started automatically when my X session comes up. Local programs that attempt to make network connections, fine; actual remote programs make me nervous.

A POP3-aware xbiff wouldn't be a bad thing. Obviously it'd need some sensible way of storing the password. (I believe we're encountering, etc.)

Almost entirely unrelated, but do you know anything about pop daemons? Sarah's trying to use pop to access her mailbox on ming, and ming's popd just keeps deciding she has no mail (even when there's clearly mail in /var/spool/mail/sarah)...

Sorry, no idea. All my POP hackery has been from the client side (unless you count the half of my pop-agent that listens on the Unix socket).

If it were me I'd try stracing the popd to see which mailbox it's really checking, but you've probably tried that already...