response 126 of 467:

Oct 1 19:47 UTC 2004

What happens when a message comes in for two people, and puts one
of them over the quota, but not the other?  When Grex accepts a
message, can it do so for just some of the recipients?

Ignoring that for the moment, I agree with Mark.  The thing to do
is:

  - Wait for sender to send size of message.
  - Check the current size of user's mailbox.  If this message puts
    it over the quota, reject it.
  - Otherwise accept the message and process it without further regard
    for the quota.

Note this does allow the mailbox to grow above the quota, if two
messages come in in parallel, but this is rare and the maximum overage
is less than the size of one message.

This ought to be as simple as adding a CheckMailboxSize(user) function
to the delivery part of the system, which the accepting part calls.

response 128 of 467:

Oct 1 21:49 UTC 2004

And, if the sender lies about the message size?

response 130 of 467:

Oct 2 01:20 UTC 2004

Jan is wrong on one major point here: MTA's don't *have* to send you
the size of a message before they transmit the message.  They can,
but there's nothing that says they have to.

The way Marcus's mailbox quota code worked, it did a stat() of the user's
mailbox file, and compared it against some kind of constant (I think he
added an option to sendmail.cf to initialize that).  If the size returned
by stat was greater than the constant, an error was returned in the SMTP
transaction sending the mail.  If not, then the mail was accepted and
appended to the user's mailbox.  If the user was subsequently over mail
quota, this would be detected the next time he or she got a message.

It wasn't that fancy.  The only major `optimization' was to stat the
user's mailbox during the SMTP transaction (once the recipient was known,
but before the data was sent).  I don't remember what it did in the case
of multiple recipients; probably deliver to those it could and reject
the rest.

I say put up exim with the existing quota code and work from there.
Since we've never measured the network link in any way, any guesses as
to where a bottleneck might exist are pure speculation, and not based
on any observations based on empirical evidence.

Or, since Kip's not doing it, put up postfix instead.

response 132 of 467:

Oct 2 16:27 UTC 2004

You might want to take a brief look at the documentation for
postfix.  If it is even better than exim, that would support
switching.  Then again, if the exim documentation is as good
as it sounds, it might not be worth bothering.

response 134 of 467:

Oct 2 17:58 UTC 2004

I have no idea how many exim sites there are.

Let's get this straight.  Three years ago we decided to switch Grex to
openBSD.  It's been a year and a half since the Grex users invested in
the new computer.  It's time they got someething for their money.  I
want to get Grex moved to nextGrex as soon as possible.  Within the next
few weeks if possible.

I seem to be the only person doing things.  I have limited time.  I have
limited enthusiasm.  I don't want to spend my time fooling with MTAs.  I
don't care about MTAs.  I want to be writting my own software, not
futzing around with other people's.  I am attempting to stay on a
straight line aimed at getting NextGrex up.  I am not taking any detours
or diversions. At some point when I wasn't in the room some set of staff
members decided on exim for reasons I either never knew or have
forgotten.  Good enough for me.  Exim will work.  I'll go with exim.  I
will not engage in any re-examination of that decision, because that
would be a diversion from my straight line.

If postfix is better, you are welcome to install postfix, either today
or at any time in the future.  If you can promise me absolutely that you
will have it up within a week, then I'll stop working on exim.  If not
then your plan is not part of my straight line.  I am not interested in
holding up progress on NextGrex so that we can have a better MTA.  No
user of Grex cares about exim vs. postfix vs. sendmail.  All they want
is for their mail to go through.  Exim will get their mail through,
perform well enough, and be secure enough.

After I got exim built, it took five minutes to switch from sendmail to
exim - just edit three files and restart one process.  We can switch
from MTA to MTA twice a day for the rest of eternity for all I care.
I'd be sorely disappointed if nobody ever improves on what I'm doing now.

In case anyone has any delusions, nextGrex will not be in perfect shape
on the day we come up on it.  I want it to be reasonably stable and
secure.  I want all basic services to be basically working.  I
anticipate months of bug fixing and fine tuning.  I'm hoping that the
new platform will provide an environment for innovation and development
of new and better services for Grex.  I've spent years of my life
pushing Grex out of ditches.  You'll not find me blocking you if you
want to change MTAs.  Though I'd hope you could find more interesting
things to change on Grex.

response 136 of 467:

Oct 3 22:24 UTC 2004

I also support Jan's approach.  As he says, if another staff member wants
to improve on his work (but not delay the live public release of
NextGrex), you are welcome - but action speaks real volumes.

response 138 of 467:

Oct 4 17:43 UTC 2004

Drift:  Does mdw do grex any more?

response 140 of 467:

Oct 4 21:06 UTC 2004

OK.  I have mail quota working under exim, I think.

The whole thing was done from the exim config file.  I like the degree to
which exim can be configured.  The syntax isn't super great, but at least
it is well documented and exim gives good error messages when there are
problems.  I suspect parsing the whole config file on every start up is rather
slow, but on the new system slow is a relative term.

So I started with a couple macro definitions.

MBOX_QUOTA = 1M
STAFF_GID = 20
MBOX_FILE = /var/mail/$local_part

Pretty clear.  We need the staff group id because staff is exempted from
mailbox quotas.  I think that makes some sense, since many system error
messages might be mailed to staff.  However most Grex staff forward their
mail off Grex.

We use a macro to construct the user's mailbox partly to facilitate a
switch to hierarchical mail directories someday.  I think all you now have
to do to make exim do hierarchical mail is change the MBOX_FILE macro to
something like:

MBOX_FILE = /var/mail/${length_1:$local_part}/\
      ${if == ${strlen:$local_part}{1} {z}{${substr_1_1:$local_part}}/\
      $local_part

The real meat of the quota check is done in the route definitions.  Routes
decide what is to be done with an incoming mail, but they are also called
to verify each recipient as they are fed to SMTP.  The routes definitions are
checked sequentially.  First one takes mail addressed to non-grex domains
and delivers them to the appropriate system via SMTP.  Next one checks
grex addresses against the system aliases file.  Next one checks them
against a .forward file.  The last one, run only if all previous ones
weren't appropriate, delivers to the local mailbox file.  I replaced that
with three new routes.

First, we do delivery to staff:

localuser_noquota:
  driver = accept
  check_local_user
  condition = ${if == {$local_user_gid}{STAFF_GID} {yes}{no}}
  transport = local_delivery_noquota

That says that if the recipient has the staff GID, use the
"local_deliver_noquota" transport.

Next we generate a failure for mail to full mailboxes:

mbox_full:
   driver = redirect
   verify_only
   no_verify_sender
   allow_fail
   condition = ${if \
        and { {exists {MBOX_FILE}} \
              { >= {${extract{size}{${stat:MBOX_FILE}}{$value}{0}}} \
                   {MBOX_QUOTA} } } \
        {yes}{no} }
   data = :fail:Mailbox for $local_part is full

This rule is used only when verifying a recipient after an SMTP-client
issues a comand like RCPT TO:<mailhog@grex.org>.  It stat's their mail
file, if it exists.  If it is full, it forces a failure with the error
message "Mailbox for mailhog is full".  Note that the message will still
be delivered to any other recipients.  We do a hard fail here because
previous experience says that if we just "defer" then many mail hosts
will retry seconds later and keep hammering us with repeated attempts
to deliver the message.

If that route fails to apply, we can go ahead and deliver the mail normally:

localuser:
  driver = accept
  check_local_user
  transport = local_delivery_quota
  cannot_route_message = Unknown user

Now each of the two mail delivery routes referenced a transport to use.
The config file defines those too. Here's the noquota one:

local_delivery_noquota:
  driver = appendfile
  file = MBOX_FILE
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  mode = 0660

The quota one just defines a quota:

local_delivery_quota:
  driver = appendfile
  file = MBOX_FILE
  quota_is_inclusive
  quota = MBOX_QUOTA
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  mode = 0660

Note that for mail coming in through SMTP, this does the quota check for the
second time.  We did a check at RCPT time, and now we are doing the same check
again as we are deliving the mail.  Doing it twice isn't really necessary,
but it is nice, because the second check is being done with a lock on the
mailfile, so it avoids race conditions.  The second check is more important
for mail that didn't come in via SMTP - that is mail that was sent by another
user on Grex, because there is no RCPT time check done for such mail.

There is another difference between the SMTP RCPT time check and the
append-time check.  If the latter fails, then we defer instead of doing a hard
fail.  The system will retry delivery for a few days before bouncing back the
mail, and the mail will be bounced back to the "From" address.  Since this
mostly effects only mail sent from Grex, this is fine.

There are probably some other things I should do with the configuration, like
setting up logging through syslog instead of to exim's own private log files.

response 142 of 467:

Oct 5 10:01 UTC 2004

Is that meant as a compliment?

response 144 of 467:

Oct 5 20:37 UTC 2004

Yeah.  Some people are brilliant at finding ways to make software fail.
 Combine that with the ability produce useful bug reports and you have a
person highly valued by any programmer interested in getting things solid.

Though it must be very annoying for Mike.  I'm sure he'd prefer if
things just worked for him.

response 146 of 467:

Oct 6 03:38 UTC 2004

I read some postfix documentation when I configured the postfix MTA on my
desktop system, but I've forgotten everything about it.  I can say that I'm
impressed with how easy it finally turned out to be to do everything that I
wanted to do with exim, once I slogged through the documentation and thought
it out.  I had really expected that I would need to hack the source code, but
everything I needed to do could be done from the config file.

My one concern with exim is performance.  I worry that all that
configurability was purchased at the price of mediocre performance, though
I have no experience to base this on yet.  We'll see.

I don't think you are in my way.  Actually, my way is pretty hard to get into.

I think if I made a list of the 100 most interesting projects to work on on
Grex, replacing a working MTA with another working MTA wouldn't be on it. 
But different people have different tastes.  Hey, and we don't really know
how well my exim configuration will work till we start feeding a lot more mail
through it than just my few test messages.

response 148 of 467:

Oct 6 04:59 UTC 2004

OK, here's a puzzle.

While wandering through the source code of 'sshd' I discovered that there is
a "UseLogin yes" option that can be put into the config file.  When this is
set, sshd uses the 'login' program to start the user's shell after he has been
authenticated.  This would be very nice for me because I wouldn't have to
do all the same hacks to 'sshd' that I already have done to 'login'.  We could
keep running a generic OpenBSD version of sshd without local patches.

However, I noticed that the manual page says nothing of "UseLogin".  Web
searching shows that historically there have been two major 'ssh' security
holes with UseLogin.  Both of these, however, were fixed years ago.  I found
many references suggesting that "UseLogin" was once described in the manual,
but it seems to have been removed.  However I couldn't find any information
on why it was removed from the manual, but left in the code.  Is it
depreciated?  I don't know.  I did find a message in which one of the OpenBSD
developers said he regretted ever having accepted the UserLogin patch to
OpenBSD.

So, do I go ahead and use UseLogin, or do I ignore it and patch sshd?