it is an usual practice on BSDs and make the synopsis and usage
more robust when operands are added or removed; synchronize the
usage with the synopsis on the manual page; while here, remove
superfluous information from the usage.
ok jmc@
queue at startup: catches left overs from interrupted sessions,
reset F_MESSAGE_INPROCESS so that messages which were in MTA or
MDA gets scheduled again.
- temporarily comment chl@'s O_EXLOCK -> fcntl change until we figure
why it locks my mailbox under load
F_MESSAGE_COMPLETE
- submit recipients to the queue as we read them from RCPT instead of
submiting them all at once when DATA is over. this prevents us
from having to keep a potentially large number of recipients in
memory during the whole session.
- remove all code that dealt with the recipients queue of a message as
it is no longer used.
- several small changes to make sure the server is always in a recoverable
state in case of an unexpected shutdown.
waiting for the DATA command. this currently has no impact on the
session but is needed for another change that will make submission
of recipients safer with regard to "unexpected shutdowns at bad
timings"
a client. it must be set to the highest value we have from all of
the extensions which are/will be implemented.
- replace all occurences of STRLEN define with MAX_LINE_SIZE, kill STRLEN
change based on a comment from deraadt@
- in queue_register_submission(), if an envelope cannot be fully written
because of some error (ie: disk full), not only return error but
also remove the partial envelope from file system. this prevents
the queue process from trying (failing) to reload it over and
over.
I expected. They object if there are no bits set in the option
value. So just use DHO_PAD in the reserved space unless at least
one of the bits is set.
Various versions tested by Tobias Ulmer on OpenSolaris, matthieu@
on busybox's DHCP client, and Uwe Dippel on Solaris. All of which
failed before.
will probably miss this change when working on more important matters,
so it is probably better to sort them now. there is a risk of losing
the tags if a change needs to be reverted too.
written with excellent advice from jmc@
ok gilles@
which still lacks many features. bringing it in tree will help working on it
more easily.
"at this stage it should go in" henning@, "move ahead" deraadt@
