Annotation of 43BSDReno/share/doc/ucs/mmdf/p5, revision 1.1

1.1     ! root        1: .SH
        !             2: Deliver
        !             3: .PP
        !             4: The \fBdeliver\fR process changed little until late 1984,
        !             5: when a dead-host caching facility and advanced retry mechanisms
        !             6: were added to \fBdeliver\fR.
        !             7: Until then, the major changes to \fBdeliver\fR were
        !             8: bug fixes and changes to enhance error recovery.
        !             9: Most notably, the mechanism to return mail was made much more persistent.
        !            10: In MMDFI, if a message could not be returned to the sender, it
        !            11: was ``dropped on the floor''.  This is not acceptable.
        !            12: The new mechanism first tries to return to the sender; if that fails,
        !            13: an attempt is made to send the message to the local ``Postmaster''
        !            14: address.  If this too fails, then \fBdeliver\fR tries to write the message
        !            15: into a ``dead letter'' file
        !            16: (usually /usr/mmdf/lock/home/DeadLetters).
        !            17: The last resort is to scream loudly into the log files.
        !            18: .PP
        !            19: The recent changes to \fBdeliver\fR are
        !            20: designed to reduce \fBdeliver\fR's load
        !            21: on a system that handles a large amount of mail.
        !            22: The first change is to move the dead-host caching function out
        !            23: of the channels (currently only SMTP) and into \fBdeliver\fR.  This has
        !            24: two advantages.
        !            25: First, \fBdeliver\fR no longer has to hand every address to
        !            26: the channel to find out that the host is dead.  This was expensive, since
        !            27: communications between \fBdeliver\fR and the channel
        !            28: are interactive using pipes
        !            29: and thus involved a great deal of context-switching and pipe I/O.
        !            30: Second, the dead-host caching is now a generally available facility that
        !            31: can be used by any channel without duplication of code.
        !            32: .PP
        !            33: The second change is to add a mechanism for storing the retry history
        !            34: for each dead host on each channel including retry count and last retry
        !            35: time.
        !            36: From this information it is possible to implement intelligent
        !            37: retry strategies using exponential backoff and maximal retry times.
        !            38: This greatly reduces the overhead caused by recalcitrant hosts
        !            39: that are unavailable over a long period of time.
        !            40: The retry history change is conditionally compiled
        !            41: into deliver since it can,
        !            42: by design, use quite a bit of memory if there are a lot of dead
        !            43: hosts or pending messages (or both!).
        !            44: Machines with a relatively limited address space may not
        !            45: be able to use this feature.

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.