[NOT SUBMITTED YET!!!] INTERNET-DRAFT Grant Neufeld draft-neufeld-listprobe-00.txt Nisto Expires: February, 1999 August, 1998 The List-Probe Message Header Field for Identifying Mail List Probe Messages Status of this Memo 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). Copyright Notice Copyright (C) The Internet Society 1998. All Rights Reserved. Abstract This document defines the message header field "List-Probe" to be used in consistently identifying mail list probe messages. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Neufeld [Page 1] INTERNET-DRAFT draft-neufeld-listprobe-00.txt August, 1998 1. Introduction Many MTAs (mail transfer agents - mail servers) in use today do not provide adequate details when failing to transfer mail messages. In particular, when email is automatically forwarded from a recipient address to a second address that is 'bouncing' incoming mail, the error response messages may not properly including the original (forwarding) recipient address. To help deal with this problem, many mailing list managers have taken to sending out individualized "probe" messages. The probes include enough identifying information - even if the original recipient address is not included in the error response - that the forwarding address can be properly identified. The drawback to this approach is that valid recipients will receive the probe messages in their mail - an unfortunate waste of time and resources. This document defines a message header field, List-Probe, which will allow MUAs (mail user agents - email clients) to identify and automatically discard probe messages so the user does not have to be involved in the process. If a probe message is received by a MUA, the recipient address is valid, so the probe does not need to be responded to (and can safely be discarded) since probes are only seeking error responses. 2. The List-Probe Header Field The List-Probe message header field MUST contain a single RFC822 format recipient address. The field MAY also contain round-bracket enclosed comments. For example, a probe message for the address user@some.host might look like: List-Probe: user@some.host To: user@some.host From: admin@server.host Errors-To: probe@server.host Subject: Probe message - Please ignore We are checking for invalid email addresses. Since you have received this message, your email is valid. Please discard this message - DO NOT REPLY. Our appologies for the interruption. Neufeld [Page 2] INTERNET-DRAFT draft-neufeld-listprobe-00.txt August, 1998 3. Security Considerations Since the originating system is responsible for introducing the List-Probe field into the message, with the expectation that valid recipients will discard the message, it is expected that no unwanted message discarding will occur. There is a danger that senders of unwanted bulk email could make use of the List-Probe field in validating recipient addresses. To provide users with the option to avoid this, MTAs MUST provide an option to ignore the List-Probe field (not deleting the messages), allowing the user to see the probe messages. In the case of ignoring the List-Probe field, the MTA MAY hilite the message in some manner to alert the user that it is a probe message. Mail list processors SHOULD NOT allow user-originated List-Probe fields to pass through to their lists, lest they confuse the user and have the potential to create security problems. References [RFC822] David H. Crocker, "Standard for the Format of ARPA Internet Text Messages" RFC 822, August 1982. Editors' addresses Grant Neufeld Calgary, Alberta Canada Email: grant@acm.org Web: http://www.nisto.com/ Neufeld [Page 3]