>>>>> "ds" == Dave Sherohman <esper at sherohman.org> writes:

ds> My preferred software for online mail is the combination of mutt
ds> and exim.

Since you asked about sendmail.... :-) Well, I'll just spread the
knowledge around a bit, since not everything below is
sendmail-related.  YMMV.

I faced this situation a few weeks ago while I was out at USENIX.  The
conference had several 802.11b APs around the convention center and
hotels, but I wanted to be able to deal with email offline: in my
hotel room, stretching battery when within range of an AP, at the
bocce ball courts, etc.

Mail -> laptop:

I'm a curmudgeon: I use Emacs + MH.  I'd SSH to my box at home, move
$MAIL to /tmp/mail, then use 'scp' to copy the spool file to my
laptop.  Then locally run 'inc -file newly-scp-ed-file'.  Low tech, I
know, but I don't normally have my emailbox available via my IMAP
server.

laptop -> the world

MH is typically configured to speak SMTP to somebody to deliver
outgoing mail ... if there's a way to have it feed the message via a
pipe to an MTA, I dunno about it.  Anyhoo, that meant I had to run an
SMTP daemon on my laptop.  No big deal, though I had to do a few
things first:

1. Add "FEATURE(accept_unresolvable_domains)dnl" to my sendmail master
config file.  That allows sendmail to accept messages when it can't
talk to DNS servers ... very handy when off-line.

2. Add an IP filtering rule to allow access to TCP port 25 only from
localhost.

If you're ever on a public or semi-public wireless network, there are
probably other things you'll want to filter, too!  Even at USENIX,
ostensibly a "white hat" crowd, there were a lot of vulnerability
probes and actual exploit-hackery attempted on the wireless conference
network.  Do not forget that you're not at home (or at work) where the
network is relatively trustable.

3. For messages that aren't immediately deliverable, I didn't want
them sitting on my laptop: it may be a while before it's on-line
again.  So I used "define(`SMART_HOST', `mx.snookles.com')dnl" so that
all messages, regardless of recipient, would be sent to my home mail
exchanger unconditionally.  If a message is not immediately
deliverable, it's mx.snookles.com's problem, not my laptop's.

4. mx.snookles.com does not, by default, allow relaying of mail to
arbitrary recipients.  How can it tell the difference between me
sending messages from my laptop and a vile spammer?  (Who's probably
harvesting my email address from the very message, the bastard!)
I had a few options:

	1. Set up SSL identity certificates so that mx.snookles.com
	could automagically identify my laptop and thus allow relay.

	2. Use my POP-before-SMTP mechanism to permit relaying for a
	limited period of time.

	3. Permit relaying from a static set of IP addresses (the
	external NAT interfaces from the show network), trusting that
	conference attendees wouldn't use mx.snookles.com for spam
	relay.

	4. Use a VPN tunnel to talk to mx.snookles.com, so that mx
	would think it were talking to an "inside" machine and thus
	permit relaying.

#2 is problematic because the password for regular POP and IMAP
sessions is unencrypted.  There were posters at the conference that
said:

    If your password is on this list, you need to: a). change it
    immediately, and b). start using encryption, stupid.

            paSSword, default, abc123, MyPass, .....

Ah, the joys of sniffing 802.11b traffic!  Well, I could've created a
dummy POP) account that would _only_ be used for permitting mail
relaying.  {shrug}

I should be doing #4: there isn't much excuse these days not to be
using IPSec or VTun or any other capable IP tunnelling regime.  But I
was lazy, so I didn't do it this time.

I opted for #3.  It worked.  And since both my laptop and
mx.snookles.com are using sendmail 8.12.x and I've already done the
basic configuration of server crypto certificates, the actual SMTP
dialog between them was encrypted automatically via TLS.  Those
network sniffing jokers may have been able to use mx.snookles.com as
an SMTP relay, but they couldn't see my messages in plain text!

If anyone is interested in the POP-before-SMTP doodad I wrote, I'll be
happy to share: contact me for the source.  It's several
shell-scripts, but they are: a). MTA, POP, and IMAP
server-independent, and b). require no source code modifications to
the MTA, POP, or IMAP servers.  In my searching of Freshmeat,
Sourceforge, and other places, I didn't find any existing s/w that
fulfilled both requirements.

All that's required is:

1. The POP & IMAP servers spit out a syslog log message upon a
successful authentication that contains the client's IP address.
Cyrus's servers do that already.

2. The MTA's relay checking mechanism has some external way of
checking for permitted IP addresses.  In sendmail's case,
"FEATURE(access_db)dnl" works quite well.

The shell scripts are easily modified to take care of the specifics of
the POP/IMAP/SMTP servers' requirements.

Hope you have fun where ever you'll be going.  Remember to practice
safe networking!  :-)

-Scott