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.