Request for user input - remote mail host issues

Dec 4 12:09 UTC 1994

At some point in the next 6 months, we're likely to go to a
configuration where mail is running on a separate machine from grex
proper.  This is an item to start talking about some of the issues that
will surround that change.  This will probably happen sometime after
grex has moved, the pc route box has been upgraded, and news has been
moved onto its own machine.  My hope is that the mail machine will be
separate from either the mail gateway or the usenet machine - perhaps a
sun-3/50, a sun-3/260, a 386 or a 486, depending on equipement
available, how much grex has grown, resource availability, & our
experience with the usenet machine & gateway.

The actual hardware is not really that important; I believe, to most
users, it will be invisible.  This is an item to talk about the issues
that will surround having mail on a separate machine.

The first affects mail browsers directly.  We will almost certainly want
to store mailboxes on the other machine.  With mh and pine that won't be
too big a deal - mh has an "inc" command that can be used to fetch mail,
and pine supports a protocol called "imap" that can also be used to
fetch mail.  So, users using either of those mail browsers might notice
too much difference.  However, /usr/ucb/mail wants to read a mailbox
that's located directly on the local host, and Elm wants to do the same
thing.  Those won't work without some effort.  There are a variety of
solutions that range from not too bad to a lot of work: such as
providing an alternate way to "inc" mail that will make a packed
messages file that will work with mail or elm, or modifying the source
to mail & elm to teach them to use pop.  So, perhaps the first
interesting issue is how important are the different mail browsers to
people?

Mail notification also becomes a bit more complex; to some extent it
becomes impossible.  Programs such as picospan and csh, that look at the
mailbox, just aren't going to be able to detect new mail anymore.
There's a similar problem with "finger" - the current version doesn't
report unread mail, but the old version did, and people have indicated
they'd like to see that work again.  Programs that work with comsat &
biff could probably be made to work without too much effort, but it may
be even nicer to get zephyr running instead.  Zephyr is actually a very
interesting service; it provides a convenient general purpose
customizable real-time messaging service which I'm sure would quickly
become quite popular on grex.  So, here too are some more questions: how
important to people think all these mail notification methods are, and
what kinds of tradeoffs would they be willing to make here?

There are some other lesser issues we'll need to solve along the way.
For instance, straight POP and IMAP use passwords; that means you'd have
to supply your password each time you ran a program that used them.  We
would almost certainly instead implement kerberized versions of these,
that would ensure users on grex wouldn't have that problem.  If we do
our job properly, that won't be visible to the average grex user, but
only to the people who compile and install mail software.

There is one issue that becomes a bit interesting: .forward's.  We will
probably need to come up with an alternate mechamism to do that -
probably a command users run to register a forwarding address with the
mail host; and we'll need to think about how filenames & exec's work as
well.  Perhaps, we might only support a built-in version of !vacation
and no !procmail, or perhaps we'd have to find a way to support the real
things.  It might be handy to know how many people use these facilities
and if they use procmail, vacation, or something else.

There are some additional policy issues that become more acute.  For
instance, people are already using grex as just a mail relay site.  One
user currently has 158 messages queued up on grex; they are all of them
50K, they came from germany and are queued up for some system in
thailand that isn't responding.  That's a pretty impressive amount of
data for someone who can't really be said to be part of the grex
community.  The situation could become much worse with a separate mail
host - already, people have expressed interest in supporting "pop" on
grex, which would in fact allow them to make more use of grex as a mail
host, without actually logging into grex.  So that brings up another
policy issue - how do people feel about these "external" mail users? How
do we want to encourage or discourage this kind of use?

response 2 of 25:

Dec 4 13:55 UTC 1994

What are the advantages to putting mail on a different machine?

We're putting news on a different machine?

I sent e-mail to the user with the bazillion 50K messages queued up.
He apologized and asked us to delete them from the mail queue.

response 4 of 25:

Dec 4 19:55 UTC 1994

I don't do custom mail filtering on Grex currently, but I do elsewhere
and may well want to do it on Grex in the future.  We should think
carefully about doing anything that will break widely used tools for
filtering, such as procmail and the elm filtering mechanism.

response 6 of 25:

Dec 5 01:34 UTC 1994

   At some point, we will *have* switch mail to another machine.  Either
that, or move conferences/other activity.
   Other sites have dealt with elm, I believe, but I'm not sure what
the solution is/was.  We'll need to do that.

response 8 of 25:

Dec 5 02:43 UTC 1994

   Well, I think elm fators in here.  Having us geeks dictate what we
do won't work. ;-)
   NFS is an option *PROVIDED* we firewall Grex from all NFS connections
from the outside world, I think.  Wether NFS is really the way to go
remains to be seen.  Other things like RFS might be usable?  I don't
know, but we need to dig into this.

response 10 of 25:

Dec 5 09:38 UTC 1994

NFS has its own performance overhead; it will almost certainly negate
any of the advantages of moving mail processing onto a different
machine.  At its best, NFS involves a longer code path in the kernel and
a slower I/O device.  At its worse, NFS makes file locking a nightmare,
and introduces all sorts of subtle new ways for things to break, that
cannot be easily dealt with.  The only piece of advice I've ever seen
from people who have made mail work with NFS is "Don't do it"; I've even
seen this buried deep inside of code from programmers who normally have
a very terse commenting style.  That's good enough for me; I see no
reason to stare further down the mine shaft than the first skeleton.

RFS is system V isn't it?  Our chances of getting source or a SunOS and
netbsd implementation don't seem that great.

AFS or DFS would seem more likely.  If we were already running AFS or
DFS that might be a good solution; but as things stand, I don't see us
ready to run either until well after we've grown large enough to want to
distribute mail.

response 12 of 25:

Dec 5 16:04 UTC 1994

Please don't take elm away!

        Pattie

response 14 of 25:

Dec 6 02:32 UTC 1994

Yeah, so that doesn't do us any good, I'm afraid.
I thought I heard someone say that there was a POP version of elm.
Of course we would need a kerberized POP version.

response 16 of 25:

Dec 6 06:34 UTC 1994

Actually, it seems that sunos 4.1 supports rfs too -- but I'd really
want to talk to some place that had successfully used it for mail (with
a large and potentially hostile crowd of users), and I'd want to know a
lot more about how it handles crashes, security, caching, and locking,
before I'd feel comfortable trying it.  Since freebsd/netbsd don't seem
to support rfs and I know of no PD implementation of rfs, it's certainly
the case that rfs would restrict our present & future hardware choices,
and would probably represent an additional and expensive software
component.

kpop & imap *are* used by places that support many many users.  Also the
source to do either is much more readily available.  From what people
have said here, it sounds like those are probably the best solution, but
that it's also reasonable to go slowly on this, and to take our time &
get it right.

response 18 of 25:

Feb 14 18:20 UTC 1995

So, it seems two things can be gleaned from this thread:  ppl want
ELM, and they do NOT want RFS.

mdw -- you started this item, what else do you need to hear from the
users of this system?  (It seems they won't answer questions not asked.)

response 20 of 25:

Feb 16 16:26 UTC 1995

        Well, I'd love to contribute, but this discussion lost me WAY
back!

response 22 of 25:

Feb 21 03:36 UTC 1995

If nobody responds to it, it will not be active.

response 24 of 25:

Feb 22 15:17 UTC 1995

(Tip: you don't need to respond to every item you read.)