One document matched: draft-ietf-drums-kre-reply-to-00.txt
DRUMS Working Group R. Elz
Internet Draft University of Melbourne
Expiration Date: April 1998
October 1997
Use of Reply-To in Internet E-Mail messages
draft-ietf-drums-kre-reply-to-00.txt
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), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This draft forms part of a discussion on the appropriate use of the
Reply-To header in e-mail messages. This draft argues for one
particular proposed definition of the Reply-To header.
It is not intended that this document ever become anything more than
an Internet-Draft. If adopted, the text here, or a modified version
of some parts of it, would be merged into the proposed replacement
for RFC822.
kre [Expires April 1998] [Page 1]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
Table of Contents
Abstract ................................................ 1
1 Introduction ............................................ 2
2 Document Conventions .................................... 2
3 The Problem ............................................. 3
3.1 Personal Replies ........................................ 3
3.2 Reply to Everyone ....................................... 4
3.3 Mailing Lists ........................................... 5
4 Desired Functionality ................................... 6
5 Possible Solutions ...................................... 7
5.1 Using two headers ....................................... 8
5.2 Many Headers ............................................ 9
5.3 One other option ........................................ 10
5.4 Resolution .............................................. 10
6 Suggested Text .......................................... 11
6.1 Field definitions. ...................................... 11
7 Further Work ............................................ 15
8 Security Considerations ................................. 15
9 References .............................................. 15
Author's Address ........................................ 15
1. Introduction
The DRUMS working group of the IETF is attempting to define the use
of the Reply-To header in Internet e-mail. This is a contribution to
that effort, and represents an argument for one position.
2. Document Conventions
This document makes use of the document conventions defined in BCP14.
That provides the interpretation of some capitalised words like MUST,
SHOULD, etc.
There can be many different people associated in varying ways with
the transmission of an Internet e-mail message. Except where
precision is necessary to separate these various roles, this draft
will use terms like "author", "sender", and "originator"
interchangeably, in order to make the text a little more interesting
to read. It will be clear where a distinction is being made between
the various roles that can be involved in the specification,
creation, approval, and transmission of a message.
kre [Expires April 1998] [Page 2]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
3. The Problem
RFC822 does a particularly poor job of defining the Reply-To header.
It is clear that the intent is that automated replies should be
addressed to the Reply-To header instead of the From header, when a
Reply-To is present, but other than a few examples of how Reply-To
might be used, there is absolutely no indication at all of what it
means.
In particular, no explicit hint is given as to whether, when a reply
is sent, address in the To and Cc headers of the original message
should be included or not. That is true for replies with no Reply-To
header, where the answer no doubt depends upon the desires of the
user replying. However, where a Reply-To header is given, no
indication is given in RFC822 as to whether the addresses in that
header are the only addresses to which replies should be sent, or
simply a replacement for the address(es) in the From header.
Both approaches have been adopted by different mail user agents,
leading to confusion and non-interoperability.
This problem has been exacerbated by two other common use patterns.
The first is the tendency of some mail user agents to have exactly
two reply options - in the matter of selecting the destination
addresses, there can be other options which control things like
populating the reply message template with the text of the subject
message, which are not relevant here. These two options are
typically characterised as being "personal reply" or "reply to
author", and "reply to everyone".
3.1. Personal Replies
In the absence of a Reply-To header, a personal reply (or reply to
the author) is typically sent to the address or addresses in the From
header. Since the From header is defined as carrying the addresses
of the author(s) of the message, this technique generally achieves
the desired results.
However, where a Reply-To header exists, things are not nearly as
clear. For a generic "reply", replying to the address(es) in the
Reply-To header will generally achieve a satisfactory result. But
where it is the user's desire to actually send a personal reply, to
the author of the subject message, replying to the address in the
Reply-To header will sometimes not achieve the result desired. This
is because in RFC822 Reply-To is not defined as being the address of
the authors, but rather "a general mechanism for indicating any
mailbox(es) to which responses are to be sent." RFC822 actually gives
three different cases where Reply-To might be used, as typical cases
kre [Expires April 1998] [Page 3]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
not an exhaustive list, without seeming to realise that the three
cases cannot reasonably be treated identically. Or perhaps, without
realising that not all replies are created equal.
For example, in RFC822 Appendix A, example A.2.4 shows a case where
the message is sent from one person (one address in the From header),
and the Reply-To header lists an entire committee. It would be
contrary to common sense to send a personal reply to the committee,
yet that is what many common mail user agents do today. On the other
hand, example A.2.6 shows a case where the From: address (mailbox) is
that of a secretary, for a user with no mailbox of their own, and
where the Reply-To header gives the mailbox of a friend of the user,
and where personal replies should clearly go to the address in the
Reply-To.
One way to avoid the seeming inconsistency of these examples is to
note that the "use Reply-To instead of From" rule is intended to
apply only to "automatic replies", and that for replies generated by
humans, the address choice should generally be left to the human.
See RFC822 section 4.4.4.
3.2. Reply to Everyone
This kind of reply is typically used where a message has been sent to
several people, and the user replying wishes all of those people to
receive the reply. Where no Reply-To header is present, this kind of
reply is typically sent to all addresses found in the From, To, and
Cc headers of the subject message.
Unlike personal replies, even this simple case is not trouble free
however. It is often the case that one, or more, of the addresses in
the To or Cc headers includes, but not in any transparent way, the
address from the From header. Where this happens, this simple reply
can cause the author(s) of the subject message to receive two copies
of the reply, which, to some users, is quite annoying.
One interpretation of the Reply-To header would easily allow this
problem to be circumvented. That is, if Reply-To were to be defined,
or generally regarded, as specifying all addresses which should
receive replies, then simply listing the set of addresses from the
various headers would cause, as near as practical, exactly one copy
of a reply to be delivered to each end-user mailbox. This would
normally not include the From address(es), as our assumption was that
one of the To or cc addresses includes the From address (but this is
obviously at the discretion of the author of the original message).
An obvious problem with this approach, apart from it not being
implemented that way everywhere, is that it is directly contrary to
kre [Expires April 1998] [Page 4]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
the idea of sending personal replies to the addresses in the Reply-To
header. Doing so with a Reply-To header constructed as suggested
here would certainly not result in any kind of personal reply.
3.3. Mailing Lists
Mailing lists present an obvious example of the situation mentioned
in the previous section. They are, however, somewhat more
specialised, as a mailing list can have a policy, or several, and
where applicable, that policy can be enforced by the list itself.
One example may be that all messages on the list, and all replies to
messages on the list, should be sent to the list, and nowhere else.
It turns out that this is usually easy to accomplish using the
Reply-To header, almost regardless of which interpretation if placed
upon it by user agents. A list that inserts "Reply-To: the-
list@list.site" in every message sent to the list will generally
accomplish this. A initial message to the list will normally be "To:
the-list@list.site", and "From: user@some.where". Then, the list
adds the Reply-To header as above. Now, when a user replies, the
reply address can be generated using only the Reply-To, in which case
the sole destination is the-list, or using Reply-To and To, which
gives the-list twice, which almost always results in just a single
copy being sent to the list (usually with the-list just once in the
headers). Thus it is irrelevant whether the user replying uses a
personal reply, or reply-to everyone, and irrelevant how their MUA
treats the Reply-To header, the same result is accomplished in all
cases. Further, even a chain of such replies (replies to replies to
replies) will retain this property, which is a distinct advantage on
many lists.
Of course, should a user want to ignore the list policy, and send a
reply only to the author of the subject message, using most popular
user agents, that will often be difficult at best. This causes many
people to disapprove of this mailing list behaviour. On the other
hand, many believe strongly in this operating mode, and will not
change it until, at least, an alternative with similar functionality
is developed. That will require that essentially all users,
including those with old MUAs not updated to any new specification,
are able to use the mechanism to reply to messages as the list
itself, and its users, desire - at least as well as it works today.
kre [Expires April 1998] [Page 5]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
4. Desired Functionality
When it comes to replies, there are many desires to be accommodated.
Considering only the addresses constructed for the reply message
there are, or seem to be, three different kinds of reply. First,
there is a reply to the message. Second, there is a reply to the
author of the message. And third, there is a reply to everyone who
received the original message. Obviously, replies can also be sent
to many other combinations of addresses from the original message, or
to addresses not included in the original message at all, however it
is probably safe not to attempt to consider all of those
possibilities. It should also be noted that it may be more correct
to not treat any but the first kind of reply as being a "reply" at
all, with the others being instead a new message sent to the author
of another message, or to all the recipients of another message.
However, it has been common to treat all of these as kinds of
replies, so we will continue that practice here.
To see that there are at least the three kinds of reply, consider a
message about an upcoming conference. It is sent from the organiser,
to a list of potential attendees (perhaps several mailing lists), and
with replies requested to be sent to the people handling
registrations. Most recipients who reply will be seeking
registration information, those are replies to the message. However,
some may desire to send a comment to the author of the message,
perhaps to point out an error in the text of the message that was
sent. Those are personal replies. Others may want to reply to
everyone, to point out that last year the conference was a waste of
time. They would be replies to everyone. And of course, some may
want to reply to some of the recipients only, perhaps to complain
about sending this announcement on one particular mailing list, and
to make sure that everyone who wasn't (apparently) supposed to see
the original message does get to see the complaint about the message.
Those replies we will ignore.
The Reply-To header is intended, must be intended, to allow the
sender to control, in some manner, the addresses used for these
replies. The header is inserted by the author of the original
message (cases where the header is added en route not being
considered here.) Thus, it must be the intent of the author which is
being expressed. The header contains addresses, and other than
comments, only addresses. So the intent being expressed must relate
to addresses. Then, from what RFC822 does say, and even without
that, the name of the header itself, it is fairly clear that the
Reply-To header allows the originator of a message to indicate
addresses to be used for replies. What isn't clear is which replies
should use those addresses.
kre [Expires April 1998] [Page 6]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
It is clear from RFC822 that it cannot be intended that replies to
the author of a message should use Reply-To as an automatic choice.
Example A.2.4 makes that quite clear. In that example, the Reply-To
header indicates a committee, which is not the author of the message,
but which is intended to receive replies. A reply to the author
which sent to the addresses in the Reply-To header would thus not be
sent to the author of the message. A reply to the message would
however, and would be sent where the author requested.
It seems less important what is done with a reply to everyone, as by
its nature, the more addresses included the better.
Authors of messages often want to give some guidance as to which
addresses should receive replies, and almost as often, which should
not. A very common desire is to request that recipients of the
message reply to exactly a set of addresses specified by the author.
With that facility the originator of a message can direct replies to
specific addresses and away from others.
Authors sometimes also want to express conditional information as to
where replies should be sent. That is, for example, if you want to
reply to everyone, reply to this set of addresses. Or, if you don't
want to reply to everyone, reply to these addresses. In those cases
the author might not want to express a preference as to whether
recipients should reply to everyone or not, just to suggest reply
addresses depending upon the choice made by the recipient.
Sometimes the author may even want to say: if you want to reply to me
(ie: a personal reply), use this address. This seems to be a simple
case however, the address(es) of the author(s) of the message are in
the From: header already. On odd occasions though, especially where
there are multiple authors of the message (more than one address in
the From: header) it might be desirable to designate just one of
those, or even someone different, as the principal author, and to
request that personal replies go just to that one author.
5. Possible Solutions
It seems quite clear that one header cannot possibly satisfy all of
these desires. Therefore, and assuming that there is a requirement
to provide solutions for all of these problems, multiple headers will
be needed. One of those might be Reply-To. If not, then clearly
Reply-To would be useless, and should simply be deprecated. That
option is not considered further here.
There would seem to be two ways of dividing the problem in order to
come up with a solution. Reply address suggestions could be
considered unconditional or conditional, requiring at least two
kre [Expires April 1998] [Page 7]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
headers, one for an unconditional reply address suggestion, and one
for conditional reply address suggestions. Alternatively, one header
could be used for unconditional reply address suggestions, and a new
header for each kind of conditional address suggestion that might be
desired.
5.1. Using two headers
In this scenario, the conditional reply address suggestion would need
to use a new header, as the syntax of Reply-To, which it would be
unreasonable to change, provides no way to indicate which conditions
were being indicated. A new header, which for the sake of argument
here, we will call Reply-Targets, could have a new syntax allowing
the author of the message to indicate for which classes of messages
various sets of addresses would be used.
Using ABNF, such a header might be constructed as:
reply-targets = cond-target *( ";" cond-target )
cond-target = label ":" *address
label = phrase
Undefined non-terminals ("address" and "phrase") there are assumed
defined as in the current 822bis draft.
The intent would be that where the recipient desires to reply to the
class of addresses suggested by the label, the associated address(es)
should be used. A well known set of labels to handle the common
cases could be defined, which would assist in user understanding of
the functionality, while not limiting creativity for unusual cases.
For example, a simple case:
Reply-Targets: Author: user@some.example ;
Everyone: the-list@host.xx, extra@other.host ;
This suggests to the recipients two possible reply targets, the
author, or everyone, and the addresses to use to send to each of
those.
A more complex example:
Subject: New mailing list starting
Reply-Targets: Subscribe: list-request@whatever.host ;
Unsubscribe: list-request@whatever.host ;
Send To List: ;
Discuss: Related Lists: ietf@ietf.org,
drums@cs.utk.edu ;;
kre [Expires April 1998] [Page 8]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
In this example, assumed to be the announcement of a new mailing
list, four possible reply targets are given. Nothing is suggested
for a reply to the author, thus the address(es) on the From: header
would be used for that purpose. Simple addresses are given for
subscribing and unsubscribing, no address exists for sending to the
list, which would imply that such replies are not welcome (yet), and
for discussion, a group containing two addresses is to be used.
The Reply-To header would then be used to indicate the address(es)
that the author of the message believes should be used for replies to
the message. The two headers could both be used, to give the
author's suggested reply address(es), and some possible alternatives.
With such a scheme, a user agent might have two reply buttons. The
first would generate a "default reply" which would be sent to the
Reply-To address(es) if any, or to the user's choice of From: or
From:+To:+Cc: (or perhaps even From:+To:) if no Reply-To header
exists. The second would produce a menu of reply targets taken from
the labels in the Reply-Targets header, with default cases of
"Author" and "Everyone" added if not present, or if no Reply-Targets
exists at all.
Note, there is no suggestion here that a Reply-Targets header be
created exactly, or even approximately, as has been illustrated here.
This is simply an example of what could be done.
5.2. Many Headers
In this scenario, a new header would be invented for each new kind of
reply that may be desired for the author of a message to be able to
direct to addresses of her choosing. That is, there may a headers to
indicate the addresses to be used for replies to the author, a
different header to indicate replies to everyone, and another to
allow the author to express her preference as to where recipients
should reply.
In this scenario there seems to be no particular reason to assign the
existing Reply-To header to any one of these purposes in preference
to the others, and the choice could be arbitrary.
One suggestion has been that because many User Agents already use the
Reply-To header as the standard address for the "personal reply" type
functionality, then Reply-To should be defined for this purpose. As
already shown, this would be directly contrary to the uses of Reply-
To shown in RFC822, and thus about the only guidance we have had so
far as to how the header should be used.
kre [Expires April 1998] [Page 9]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
At least two new headers are going to be needed to follow this
scheme, in addition to Reply-To. That is, the one existing header,
and two (or more) new ones. While no real change can be made to the
existing header's name or syntax, the new headers could be whatever
is required. All but one of the new headers would be conditional
advice to the recipients, if you want this kind of reply, use these
addresses. The other, the one different one, would be the header
used to indicate the message author's suggested reply addresses.
Thus, there are two categories, header names, and header functions,
each of which has one special case, and some number of similar cases.
The obvious match is to associate the special cases, and the similar
cases from the two groups.
The conclusion would be that Reply-To, the one existing header,
should be used to indicate the author's suggested reply targets, and
new headers for the various possibilities for the author's
suggestions as to where recipients of the message may like to send
different kinds of replies.
5.3. One other option
Another suggestion for Reply-To is that it should simply be a
replacement for the address(es) in the From header when replies are
generated. This seems to be approximately equivalent to "We don't
know what the header means, but use it like this", which seems to be
a particularly poor excuse for a header definition. The argument for
this approach is that many user agents currently operate this way.
Apart from being philosophically inadequate as a definition, this
approach leaves the user of the header in much the same situation
they are in now - having no idea at all which addresses recipients
will use as the targets of a reply.
5.4. Resolution
It is suggested that Reply-To be defined as being the message
author's suggestion for the addresses (all the addresses) that
recipients should use when sending a normal reply to the message.
This has the advantage that no decision needs to be made now as to
which method to use to express conditional reply types. More work
can be done to determine whether a single header with many address
options, or many headers, is the better approach. Either way,
Reply-To would be defined with a stable meaning.
Another advantage is that the mailing list use of Reply-To continues
to function as it is now used, which will avoid the difficult upgrade
problems of resisting implementors (of lists).
kre [Expires April 1998] [Page 10]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
The obvious disadvantage is that user agents which treat Reply-To as
the destination for "reply to author" (already broken as shown
above), or as "replacement for From" (meaningless), will need to be
upgraded. Of course, to fully, or even partially, handle whatever
specification is developed for reply handling, User Agents are going
to need upgrades anyway.
There are currently two widespread uses of Reply-To, that used by
lists already described, and one where users set a standard Reply-To
in all mail they send containing their own address. The latter is
done either just because it is there, or in order to compensate for
some actual or believed defect in the generation of the From header.
Catering for defective, or broken, user agents should not be our
objective. Any remaining cases where the user sets a standard
Reply-To header containing their own address are trivial for the user
to fix by simply deleting that header configuration. Thus this
definition for Reply-To has a quite simple upgrade path from current
uses for the generation side.
For recipients, user agents currently tend to treat Reply-To as to be
used in personal replies, already broken, and which will not become
more badly broken by this scheme, and typically take the Reply-To and
add recipients from the other headers for reply-all functionality.
The latter will continue to cause the problems it now does until user
agents are upgraded - but at least having a clear indication of
appropriate handling of the header should lead to those problems
being fixed in time.
6. Suggested Text
The text below is intended to replace section 3.6.2 of the current
drums 822bis (message format) draft (the -02 version). Section 6.1
here is roughly equivalent to section 3.6 of that document for
numbering purposes.
6.1. Field definitions.
This is a dummy section just to get the section numbering in this
document somewhat aligned with that in the message format draft.
6.1.1. The origination date field
This is another dummy section, no changes are suggested here.
kre [Expires April 1998] [Page 11]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
6.1.2. Originator fields
The originator fields of a message consist of the from field, the
sender field (when applicable) and optionally the reply-to field.
Reply-To is not an originator field in quite the same way as the
others, but is commonly considered to fulfill a similar role.
The from field specifies the author(s) of the message, that is, the
mailbox(es) of the person(s) or system(s) responsible for the writing
of the message. It consists of the field name "From" and comma-
separated list of one or more mailbox specifications. If the from
field contains more than one mailbox specification in the mailbox-
list, then the sender field MUST be included in the message.
The sender field specifies the agent responsible for transmission of
the message. It is composed of the field name "Sender" and a single
mailbox specification. Where the sender and from headers would
specify exactly the same single mailbox, the sender header SHOULD be
omitted.
A reply-to field may be included in any message. It specifies the
complete list of all addresses suggested by the author of the message
as being the addresses to which replies to the message should be
sent. The field consists of the name "Reply-To", followed by a comma
specified list of addresses, in which groups are permitted.
from = "From:" mailbox-list CRLF
sender = "Sender:" mailbox CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. For example, if a secretary were to send a message for
another person, the mailbox of the secretary would go in the sender
field, and the mailbox of the actual author would go in the from
field. If the originator of the message can be indicated by a single
mailbox and the author and transmitter are identical, the from field
SHOULD be used and the sender field SHOULD NOT be used. Otherwise,
both fields SHOULD appear.
The originator fields also provide information required to reply to a
message. When the reply-to field is present, it indicates the
mailbox(es) to which the author of the message suggests that replies
be sent. In the absence of the reply-to field, replies SHOULD be
sent to the mailbox(es) specified in the from field, and at the
user's option, to other addresses selected from the destination
address fields. See also section 3.6.3 [in the original] for more
information on forming the destination addresses for a reply.
kre [Expires April 1998] [Page 12]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
In all cases, the from field SHOULD NOT contain any mailbox which
does not belong to the author(s) of the message. However, the user
SHOULD be able to set the from field to any mailbox which belongs to
him. User agents are not required to validate that setting.
6.1.3. Destination address fields
The destination address fields of a message consist of three possible
fields, each of the same form: The field name, which is either "To",
"Cc", or "Bcc", followed by a comma-separated list of one or more
addresses (either mailbox or group syntax). Both the to field and
the bcc field MAY occur alone, but the cc field SHOULD only be
present if the to field is also present.
to = "To:" address-list CRLF
cc = "Cc:" address-list CRLF
bcc = "Bcc:" [ address-list ] CRLF
The destination fields specify the recipients of the message. Each
destination field may have one or more addresses, the bcc field may
contain none. Each of the addresses receives a copy of the message.
The only difference between the three fields is how each is used.
The to field contains the address(es) of the primary recipient(s) of
the message. Generally persons addressed in this header are expected
to take particular note of the message. The cc field (where the "Cc"
means "Carbon Copy" in the sense of making a copy on a typewriter
using carbon paper, or perhaps "Courtesy Copy") contains the
addresses of others who should receive the message, though the
content of the message may not be directed at them.
The bcc field (where the "Bcc" means "Blind Cc") contains addresses
of recipients of the message whose addresses should not be revealed
to other recipients of the message. There are two ways in which the
bcc field can be processed. In the first case, when a message
containing a bcc field is prepared to be sent, the bcc header is
removed from the message, even though all of the recipients contained
in it are sent a copy of the message. In the second case, recipients
specified in the to and cc fields are each sent a copy of the message
with the bcc header removed as above, but the recipients named in the
bcc field get a separate copy of the message containing a bcc header.
This header may be sent in one of three ways, one copy of the message
containing the complete bcc header may be sent to all recipients
names in it, or a separate copy of the message can be sent to each
recipient, with the bcc header contained naming only that one
recipient, or one copy of the message may be sent to all the
recipients named in the bcc field, with the bcc field included with
all the addresses deleted from it. In any case the original to and
kre [Expires April 1998] [Page 13]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
cc fields should be retained. Which method to use with bcc fields is
implementation dependent, and ideally configurable by the user.
Refer to the "Security Considerations" section of this document
[drums message format] for a discussion of each.
It is beyond the scope of this specification to constrain user
behaviour, or consequently to attempt to constrain user-agent
behaviour, the following is offered for guidance as a suggestion of
how users may comply with the spirit of the address fields when
generating replies. Note that nothing here is in any way intended to
limit the addresses to which users can send messages, be those
messages replies to other messages or simply new compositions.
When a message is a reply to another message, and there was a reply-
to field in that other message, the to field of the reply should
normally be copied from the reply-to field of the subject message.
Other destination fields would be omitted by default. Where there
was no reply-to header in the subject message, the to field of the
reply would normally contain addresses from the from field of the
subject message, and may contain addresses from the to field. A cc
field may be added and may contain addresses from the to or cc fields
of the original message.
If a bcc field was present in the original message, addresses in that
field may appear in the bcc field of the reply, but should normally
not appear in the to or cc fields, as doing so may reveal to
recipients of the original message that additional recipients were
sent that message without their knowledge. Of course, simply
replying to a message that was received because of an address in a
bcc header will reveal to all who receive the reply that additional
undisclosed recipients exist. Users receiving blind copies may
prefer to reply only to addresses in the from field.
Where a reply-to field was present in the original message, an
identical field should normally be copied to any reply.
Users may choose to add or delete addresses from these default lists,
or to configure their user agents to perform that task automatically.
Users may also prefer to ignore a reply-to field and reply to other
addresses, perhaps the from field addresses, or even the address from
the sender field, if present. the
6.1.4. Identification fields
Nothing further in the message format draft from DRUMS is intended to
be changed by this document. (Though the author would prefer to add
in this section that message-id fields should be added by any relay
or MTA a message passes though if the message does not already
kre [Expires April 1998] [Page 14]
Internet Draft draft-ietf-drums-kre-reply-to-00.txt October 1997
contain that field.) At some future time examples showing the uses of
the various originator and destination fields will be added above.
7. Further Work
Work is still needed to define the precise methods to be used to
convey conditional reply address information.
Work is also required to define all aspects of processing mailing
lists, of which how replies should be handled is one important
aspect. That work will need to deal with the issue of replying to a
message which has been sent to multiple lists.
8. Security Considerations
The only issues even partly related to security in this document
concern whether is correctly being backed up at the various
Internet-Drafts repositories.
9. References
If you can't work out what are, and then find, the references
mentioned in this document, you're probably not in its intended
audience.
Author's Address
Robert Elz
University of Melbourne
Department of Computer Science
Parkville, Vic 3052
Australia
Email: kre@munnari.OZ.AU
kre [Expires April 1998] [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 13:05:55 |