
The Owner Hack

INTERNET-DRAFT   draft-bernstein-owner-hack-01.txt   (expires 1 August 1997)

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Status of this memo

   This memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind. Distribution of
   this memo is unlimited.

Abstract

   The fundamental problem in managing a large mailing list is matching
   bounce messages to subscription addresses.

   Often a bounce message refers to a failing address that does not
   appear on the mailing list. One of the mailing list subscribers is
   forwarding messages to that address. Which subscriber? As the list
   grows, this question becomes more and more difficult to answer.

   The owner hack completely eliminates this problem _right now_. It
   automatically and reliably identifies the subscription address
   relevant to each bounce message. It provides the address in a form
   that is trivial for automated bounce handlers to parse. It requires
   support from the local mailer, but it does not require support from
   any other hosts.


The owner hack
D. J. Bernstein
19970201


1. Introduction

   The fundamental problem in managing a large mailing list is matching
   bounce messages to subscription addresses.

   Often a bounce message refers to a failing address that does not
   appear on the mailing list. One of the mailing list subscribers is
   forwarding messages to that address. Which subscriber? As the list
   grows, this question becomes more and more difficult to answer.

   Sometimes a bounce message doesn't identify the address that failed.
   On occasion it doesn't even include a copy of the original message.
   See RFC 1211 for an extensive collection of horror stories.

   In theory, one could solve this problem with the DSN option and DSN
   format described in RFC 1891, RFC 1892, and RFC 1894. Unfortunately,
   the DSN option is useless unless it is supported by every
   intermediate MTA. The complexity of RFC 1891 means that it will be
   many years, perhaps infinitely many, before DSNs are universally
   supported. Furthermore, the complexity of RFC 1894 means that parsing
   the subscriber address is difficult even on the occasions that the
   address is available.

   The owner hack completely eliminates this problem _right now_. It
   automatically and reliably identifies the subscription address
   relevant to each bounce message. It provides the address in a form
   that is trivial for automated bounce handlers to parse. It requires
   support from the local mailer, but it does not require support from
   any other hosts.


2. The owner hack

   Here is the owner hack: each recipient of the message sees a
   different envelope sender address. When a message to the
   djb-sos@silverton.berkeley.edu mailing list is sent to
   God@heaven.af.mil, for example, it has the following envelope sender:

      djb-sos-owner-God=heaven.af.mil@silverton.berkeley.edu

   If the message bounces, the bounce message will be sent back to
   djb-sos-owner-God=heaven.af.mil@silverton.berkeley.edu.

   If God is forwarding His mail, the bounce message will still go to
   djb-sos-owner-God=heaven.af.mil@silverton.berkeley.edu. No matter how
   uninformative the bounce message is, it will display God's
   subscription address in its envelope.

   Another benefit of the owner hack is that God Himself can see what
   address He used to subscribe.

   Making the owner hack work requires two pieces of local software
   support. First: it must be easy to modify the outgoing sender address
   separately for each envelope recipient. For example, with one mailer,
   qmail, a user can simply touch ~/.qmail-list-owner and
   ~/.qmail-list-owner-default to apply the owner hack to user-list.

   Second, and more important: it must be easy to identify a collection
   of addresses, such as djb-sos-owner-*, and send all mail for those
   addresses to one place, while preserving the * information. Under
   qmail, all user-list-owner-* mail will be sent to the user once he
   touches ~/.qmail-list-owner-default. Sending the mail through an
   automated bounce-handling program is just as easy.

   With older mailers, applying the owner hack would require setting up
   a new user-list-owner-recipient alias for each new recipient. This 
   inconvenience has prevented the owner hack from being widely
   exploited, even though the idea is not new.


3. The per-message owner hack

   The owner hack is not restricted to distinguishing mailing list
   subscribers; it can also be used to distinguish messages.

   For example, a user can send one message with an envelope sender
   address of user-dsn-1, the next message with user-dsn-2, and so on.
   As long as the local mailer gives all user-dsn-* back to that user,
   he can reliably match up incoming bounces with outgoing messages.

   The per-message owner hack can be combined with the per-recipient
   owner hack. Every application of RFC 1891's ORCPT and ENVID can be
   handled with the owner hack---easily, reliably, and right now.
