Return to p7 CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf

Annotation of 43BSDReno/share/doc/ucs/mmdf/p7, revision 1.1.1.1

1.1       root        1: .SH
                      2: The List Channel
                      3: .PP
                      4: The list channel was developed as the result of BRL's experience
                      5: in managing \fBlarge\fR Internet mailing lists.
                      6: Two major problems were discovered with dealing with mailing lists
                      7: in MMDFI.  First, since \fBsubmit\fR always verifies all known addresses
                      8: for a message at submission time, if you were on the machine with
                      9: a large list and submitted mail to the list you would have to wait
                     10: for every address on that list to be verified.
                     11: On a busy machine
                     12: with a list of hundreds of addresses, this could take
                     13: five or ten minutes.
                     14: Annoying as this may be for people,
                     15: the situation was worse for mail submitted over communications
                     16: channels like TCP/IP.  The remote end would continually time out
                     17: before the message had been completely verified so the message
                     18: could never be sent.
                     19: .PP
                     20: The second problem with large lists was that there were always
                     21: rejected mail notices going back to those
                     22: least able to do anything about the mail problem, the original
                     23: sender of the message.  What was really desired was a method to
                     24: try to have returned mail go to the list maintainer instead
                     25: of the message's original sender.
                     26: .PP
                     27: The solution to both of the problems is embodied in the list channel.
                     28: This is a channel with an incestuous relationship
                     29: to \fBsubmit\fR, \fBdeliver\fR,
                     30: and the alias file.
                     31: Use of the list channel is best described in parallel with the
                     32: special entries for the list channel in the alias file.
                     33: If we were maintaining a large list called ``biglist'', the following
                     34: entries would be in the alias file:
                     35: .nf
                     36: .ta 2.6i
                     37: .sp .5
                     38: .in +.6i
                     39: biglist:       biglist-outbound@list-processor
                     40: .br
                     41: biglist-outbound:      </usr/mmdf/lists/biglist-file
                     42: .br
                     43: biglist-request:       maintainer
                     44: .in -.6i
                     45: .fi
                     46: .sp .5
                     47: The pseudo-host ``list-processor'' has its own domain table and its
                     48: own host table but represents no actual host.  If someone submits
                     49: mail to biglist, \fBsubmit\fR will find the alias entry and
                     50: upon finding that it's
                     51: not a local address, will queue it to the host ``list-processor'',
                     52: so verification is complete after only one lookup.
                     53: Unknown to
                     54: \fBdeliver\fR, the list channel simply calls \fBsubmit\fR and feeds it the
                     55: aliased addresses, ``biglist-outbound''.
                     56: This time the actual verification is done on the contents of
                     57: the address list ``biglist-file''.  Since the list channel is processed
                     58: by a background daemon, no one is forced to wait through the
                     59: verification process except the background daemon itself, which doesn't care
                     60: how long it takes so long as it completes.
                     61: .PP
                     62: The list channel also performs another function to try to
                     63: eliminate the problem of failed mail messages.
                     64: For each address given to it, (normally just one), the list channel
                     65: sees if there is a matching ``\fIlistname\fR-request'' entry in the alias
                     66: table.  It knows enough to try stripping any ``\-outbound''s from
                     67: the name first though.  If a ``\-request'' entry is found, then
                     68: that address is substituted instead of the original return
                     69: address.  The message text is \fInot\fR altered, but the new return address
                     70: is recorded for use when resending the message.
                     71: The new return address
                     72: is supplied in SMTP ``MAIL FROM:<\fIaddress\fR>'' commands and any other
                     73: situations where the return address is directly specifiable.
                     74: .PP
                     75: The changing of the return address is useful only if mail is rejected
                     76: when submitted to the foreign host or if that host is smart enough to keep
                     77: the return address information around.  Many hosts do not maintain this
                     78: information,
                     79: and many of the same hosts are also problematic in that they
                     80: will completely accept a message containing total garbage and
                     81: decide to tell you about it later.  This is precisely what MMDF tries
                     82: to avoid by submission-time verification.

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