Subject: To MX or not to MX?

From: Graham Klyne <[email-masked]>
Date: Thu, 18 Feb 1999 12:52:31 +0000

At 21:26 17/02/99 -0500, John C Klensin wrote:
>821, if you recall, provided for SMTP over several 
>different things, some of them distinctly "not internet".
[...]
>   "SMTP" == "Internet SMTP" == 821bis
>Whatever you want to do "somewhere else" is, in that 
>context, your problem.

I think there's a crucial point here that seems to have got lost in the noise.

I don't think anyone has argued against requiring MX resolution for sending
messages across the global Internet e-mail infrastructure.  MX resolution
is definitely a required part of the Internet e-mail service.

BUT, does SMTP/821bis define a protocol (which can be used for other
services, including injection of messages into Internet e-mail), or the
Internet e-mail service?

I conclude:  if 821bis defines the protocol, then MX is a MAY and some
other document is needed that describes the Internet e-mail service.  If
821bis defines the service then MX is a MUST.

#g

------------
Graham Klyne
([email-masked])

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 1999 22:22:11 -0500 (Eastern Standard Time)

> services, including injection of messages into Internet e-mail), or the

Interesting way to characterize the situation.  One might 
want to substitute different words for "protocol" and 
"service", but using what I understand to be yours and your 
definition...

> 821bis defines the service then MX is a MUST.

If 821bis defines "the protocol" (term used as above), then 
not only is MX usage a MAY, but so is virtually every other 
feature/statement of the specification that could be used 
(or not) without preventing operation in at least one 
situation or scenario.

<Personal opinion>

It seems to me that the essence of an IETF protocol 
specification ("protocol" used somewhat more broadly than 
you use it above) is to specify conditions under which 
functional and effective interoperability can occur on the 
Internet.   Effective interoperability not only requires 
that the bits get somewhere and do something, but that the 
effects of actions are predictable: we specify behaviors in 
order that sending systems, receiving systems, and users 
can have shared expectations about what is going to 
happen.   If one system can reasonably interpret "RCPT 
TO:<joe@foo>" as implying delivery to "foo" and another 
can interpret it as implying delivery to "baz" without 
either having out-of-band information that leads it to 
ignore the specification, we really don't have a protocol 
in the IETF sense.   And, if such out-of-band information, 
not specified in the protocol, is used to do something 
different than what the protocol specifies, it is perfectly 
sensible to describe the system that uses such information 
as "partially conforming".   That isn't inherently a 
negative term, it simply means that an observer shouldn't 
have the same expectations that the system in question will 
behave in a protocol-predicted fashion as that observer 
would reasonably have of a fully-conforming implementation 
configured to operate in a fully-conforming way.

We rewrite and tighten specifications (in the fashion of 
1122/1123 and 821bis/822bis) because we have determined that
real or imagined user-observers (or the servers or clients) 
won't be able to adequately predict how a client or server 
will behave given particular stimuli.  

Seems to me that is what it is all about.  

Now, of course, we could write a specification that said 
"this a list of things you MAY do in this situation, 
perhaps there are other things you MAY do that are not on 
the list either, and other documents might be written to 
describe what subset must be chosen to actually interwork 
in a particular situation.  The latter types of documents 
are known as "profiles" or "pro formas" in the world that 
made them popular and turn out, in practice, to be far more 
important than the option-laden protocol specifications 
themselves.   For whatever it is worth, that approach 
doesn't have the successful track record the IETF "no 
profiles" approach does, partially because the marketplace 
rewarded situations in which two implementations could 
conform to the same protocol but have no hope of 
interoperating because the profiles chosen were different.

</personal opinion>

    --john

---

From: Robert Elz <[email-masked]>
Date: Fri, 19 Feb 1999 16:18:15 +1100

Date:        Thu, 18 Feb 1999 12:52:31 +0000
    From:        Graham Klyne <[email-masked]>
    Message-ID:  <[email-masked]>

  | BUT, does SMTP/821bis define a protocol (which can be used for other
  | services, including injection of messages into Internet e-mail), or the
  | Internet e-mail service?

The IETF defines standards for use over the Internet.   What anyone does in
the privacy of their own LAN (extended or otherwise) or with some consenting
ISP is no-one's business but theirs.   If they care to adopt an IETF
protocol for those purposes, fine, if they care to adopt an IETF protocol and
modify it, also fine - but the IETF's primary purpose is to define the
standards for what happens across the internet.

kre

---

From: Bart Schaefer <[email-masked]>
Date: Fri, 19 Feb 1999 10:30:22 -0800 (PST)

On Thu, 18 Feb 1999, John C Klensin wrote:

> happen.

Effectively, we have two pieces of protocol, which might be termed
"conversational" vs. "operational."  A typical "dumb" email client is
conversationally compliant with RFC821 (to a greater or lesser degree),
but is not operationally compliant with RFC1123, and doesn't have to be
because it isn't an "internet host."

As the "conversational" part is already isolated to section 4 of 821bis,
perhaps all that's needed is to make note of the distinction somewhere in
section 2 and then the change the phrase "an SMTP client" in the very
first sentence of section 5 to refer only to the "operational" part (a
better word than "operational" is probably needed; suggestions?).

Simple clients could then claim "821bis section 4" compliance without
being declared generally non-compliant by section 5.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Feb 1999 11:59:30 +0800

>the privacy of their own LAN (extended or otherwise) or with some consenting

John Klensin's response is more thorough and formal in its language but, I 
believe, says exactly the same thing as Robert.

I concur with them both.  IETF standards pertain to the global Internet and 
what is required for operation there.

There is nothing wrong with products that permit deviations, for use in 
private circumstances, but it is essential that the IETF documents make 
clear what is required for adequate interoperability over the public 
Internet.  For example, absence of MX support renders an SMTP client 
useless over the public Internet.

d/

ps.  One could imagine writing a document which specifies a variant of 
SMTP, to be used in special circumstances.  One could even imagine this 
reaching status as a BCP, perhaps.  However we need to be careful to ensure 
that the "specialness" of such a document is not misunderstood.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                       Tel: +60 (19) 3299 445
<mailto:[email-masked]>             Post Office Box 296, U.P.M.
                                         Serdang, Selangor 43400  MALAYSIA
Brandenburg Consulting
<http://www.brandenburg.com>                       Tel: +1 (408) 246 8253
Fax: +1(408)273 6464             675 Spruce Dr., Sunnyvale, CA 94086  USA

---

From: Brad Knowles <[email-masked]>
Date: Tue, 23 Feb 1999 20:39:25 +0100

On Mon, Feb 22, 1999, Jamie Zawinski <[email-masked]> wrote:

>And allowing multiple parents in References violates 1036 semantics.
>So, we need to pick one, and in this case, I choose 1036 over 822.

    RFC  1036 is news, not mail.  In this context, I don't give a flying
flip about news.  Since that standard is also currently under review, and
we can easily imagine cases where the multiple parents are more than
appropriate, maybe it's better to kick this back to USEFOR and request
that 1036bis be updated to reflect that fact.

>I find it hard to see changing the semantics of In-Reply-To as being a
>big deal, given that in my surveys of common usage of In-Reply-To, I've
>not once come across a real-world usage of In-Reply-To that contained
>multiple message IDs.  I've come across In-Reply-To fields that
>contained "<X@Y>" text -- but in the examples I've grepped for, it has
>always been the case that only one was an ID, the rest were addresses.

    I don't want anyone to misinterpret this question, but I'm curious to
know how many messages you've surveyed, and what their sources are.  For
example, have you contacted any ISPs that have hundreds of thousands of
customers (or even millions of customers) and gotten their permission to
do a statistical sample of their headers, etc...?

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit

---

From: Jamie Zawinski <[email-masked]>
Date: Tue, 23 Feb 1999 13:19:00 -0800

Brad Knowles wrote:
> flip about news.

Well I don't give a flying flip about the distinction, I just want
something that works.  Just because you choose to call it "news" instead
of "mail" doesn't mean it's not real-world experience highly relevant to
the topic at hand.

> Since that standard is also currently under review, and we can easily
> imagine cases where the multiple parents are more than appropriate,
> maybe it's better to kick this back to USEFOR and request that 1036bis
> be updated to reflect that fact.

Oh, sure, that'll work.

> know how many messages you've surveyed, and what their sources are. 

Last year, I grepped through a whole lot of old mail and archived
mailing lists.  Of all the mail messages I examined, 22,950 of them 
had In-Reply-To headers:

    18,396  had at least one occurence of <>-bracketed text.
     4,554  had no <>-bracketed text at all (just names and dates.)
       714  contained one <>-bracketed addr-spec and no message IDs.
         4  contained multiple message IDs.
         1  contained one message ID and one <>-bracketed addr-spec.

The most common forms of In-Reply-To seemed to be

       31%  NAME's message of TIME <ID@HOST>
       22%  <ID@HOST>
        9%  <ID@HOST> from NAME at "TIME"
        8%  USER's message of TIME <ID@HOST>
        7%  USER's message of TIME
        6%  Your message of "TIME"
       17%  hundreds of other variants (average 0.4% each?)

I don't remember the specific mailing lists whose archives I searched,
but I did try to get a mix of technical and non-technical ones.  It's
probably safe to assume that this sample set was somewhat skewed toward
unix users, and/or toward people who had been on the net for quite some
time (due mainly to the age of the archives.)

> For example, have you contacted any ISPs that have hundreds of
> thousands of customers (or even millions of customers) and gotten
> their permission to do a statistical sample of their headers, etc...?

No, have you?

If you have better numbers than I do, I'd love to see them.

-- 
Jamie Zawinski
[email-masked]    http://www.mozilla.org/   (work)
[email-masked]        http://www.jwz.org/       (play)

---

From: Robert Elz <[email-masked]>
Date: Wed, 24 Feb 1999 09:18:47 +1100

Date:        Tue, 23 Feb 1999 13:19:00 -0800
    From:        Jamie Zawinski <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't remember the specific mailing lists whose archives I searched,

Mailing lists aren't the best place to find a reply to multiple parents,
and it isn't surprising that you wouldn't find many (and perhaps even
less surprising that it is hard to work out what is going on from the
Reply-To header, even if there were any such messages).

A reply to multiple (distinct) parents is more likely to occur for
personal mail.   Just imagine a case where two (or more) people all
send you mail telling you something (for example: "there's a party on
tonight, want to come?")   Sure, you can reply to each of those
individually, but is just as easy (in many cases) to reply to all of
them in one reply ("Yes, knew about it, I'll be there") which not
only answers all of the mail in one easy step, but also lets all of
the people that told you about it know about all of the others who did.

But regardless of how often this actually occurs, it would be folly
to remove this as potential functionality from the standard, as it is
clearly a useful ability, regardless of whether or not people writing
mail readers know how to deal with them - and incidentally, showing
pretty little diagrams of the messages' relationship to each other is
about the least useful thing that can be done with References ... for
usenet where there can be hundreds of new messages each time you go
look at what is there perhaps it makes some sense - for e-mail where
most of the messages' references are ones that have already been seen,
(and hence are often not shown again by default) there are considerably
less replies considerably less hastily, most times, the "graph" tends
to be meaningless, as most of the relevant messages don't appear.   Much
more useful is to be able to quickly reference previous messages (display
them, forward a whole set, ...)   Multiple parents presents no real
difficulty for any of that at all.

Even worse is to imagine that multiple parents as a functionality can be
removed now, and then if it seems to get some usage, be added back sometime
later.   How then would anyone ever demonstrate the usage?  There would be
no way at all in the headers to show multiple parents, so if you did a
message scan you'd be guaranteed of never seeing a single one.   Further,
with the standard saying that a message should have exactly one parent,
what UA implementor is going to provide a mechanism for there to be more
than one?

Multiple parent messages simply have to be retained.   If people really
think it is necessary, a usage warning could be added, along the lines of:
"Caution: generating a message with references to multiple parents may
cause some deficient user agents to have trouble displaying the message
correctly."  But that is as far as we should go.

kre

---

From: Jamie Zawinski <[email-masked]>
Date: Tue, 23 Feb 1999 15:41:18 -0800

Brad Knowles wrote:
> 
>     The problem is, news and mail have always been very similar but
> somewhat distinct, and from what I have seen both here and on USEFOR,
> that distinction seems to be likely to remain forever, whether we like it
> or not.

This is probably true.  But not for good reasons, as far as I can tell.
The reasons seem to me to be primarily that the group of people who care
about mail and the group of people who care about news don't talk to
each other very much, and are each very focussed on their particular
applications.  There are a lot of people who like to focus on the
differences between mail and news as an excuse to ignore the
similarities.  (But I'm not bitter.)

>     I think it would take a *very* concerted effort to consolidate the
> two sets of standards, and both sides would have to accept a lot of stuff
> that they don't like (or don't care about), in order to get the broadest
> possible standard that could encompass both of them.

I'm not talking about consolidating the two sets of standards.
I'm only talking about them interpreting the References header
in the same way!

If even something as simple as that isn't possible, then we should
all just go home.

> That would mean that USEFOR would have to accept messages with
> multiple parents, for example.

I don't accept that multiple parents are useful in mail but not 
useful in news.  If they're useful in one, they're useful in the
other, and vice versa.

I accept that multiple parents might be useful someday, with some
hypothetical as-yet-uninvented user interface.

I don't see what "mail" versus "news" has to do with this.

>     Just your own personal mail, or that which belongs to multiple
> people?  How many total messages is this?  Over what period of time does
> this stretch?

My own personal mail, going back several years; plus some public mailing
list archives I pulled off of the net (but I don't remember which, it
was a long time ago and I neglected to keep track of that.)

>     As kre pointed out, this is not a proper sample.  

I *know* it's not an unbiased sample.
I *said* it's not an unbiased sample.

It is, however, the sample I have.

If you have a better one, I'd love to see it.

> You have pre-selected content from places that are not likely to have
> the sort of thing you were searching for, and therefore you didn't
> find it.  You now declare that it can't possibly exist.

I said no such thing.  I said that in my experience, and in the samples
I searched, I didn't see any usages of multiple parents.  (In fact, I
misspoke when I said that -- my search turned up exactly 4.)

And, by the way, when I did this search last year, I wasn't "searching"
for anything, I merely wanted to understand how In-Reply-To was used in
the real world.  This was as close to "the real world" as I could easily
get.  I just wanted to know what kind of hoops I was going to have to
jump through to (practically) use In-Reply-To for threading in the
absence of a sane References header.

>     However, after getting the appropriate approval from my boss, I might
> be able to do a search of all the existing mailboxes and look for both
> "References:" and "In-Reply-To:" headers and see what kinds of numbers I
> can dig up.

That would be wonderful.

I'm perfectly willing to listen to other evidence.  In the messages I've
examined, multi-parented messages by and large didn't exist, let alone
seem useful.  If you want to argue that they are used and are useful,
then come up with your own data refuting that.  Just telling me that
what I've seen isn't applicable is hardly a productive approach.

If someone else wants to re-write the text about References and
In-Reply-To construction again, feel free.  If the rest of you want
to just revert that text to what RFC 822 said, feel free.  But the
current DRUMS text (which is different from the RFC 822 text) is
pretty bad, and should be replaced once way or another, either by
moving forward or backward.

I've tried to rewrite it twice now and been shot down, it's someone
else's turn.

---

From: Brad Knowles <[email-masked]>
Date: Wed, 24 Feb 1999 01:04:25 +0100

On Tue, Feb 23, 1999, Jamie Zawinski <[email-masked]> wrote:

>applications.

    Well, I'm on both DRUMS and USEFOR.  If you're like-minded, then I
suggest you get on both as well.  If we can get enough people together
that feel the same way, then maybe we *can* make them more similar than
they are today, with hopes towards real convergence somewhere down the line.

>I'm only talking about them interpreting the References header

    But you're talking about throwing away existing functionality in
order to "dumb down" the mail standard on this to be conformant to how
Usenet news works.  IMO, that doesn't seem to be a particularly good
solution, especially given the counter-examples that have been mentioned here.

>useful in news.  If they're useful in one, they're useful in the

    I'll agree with that.

>hypothetical as-yet-uninvented user interface.

    It's not hypothetical at all.  I think you're just mis-using the term
"user interface".  Anyone who wants to can go in and edit the headers of
their message so as to give it multiple parents (that's a "user
interface", albeit rather arcane ;-), and my guess is that there are some
text/screen-oriented MUAs that already use this feature.  You just
haven't run into them yet.

    Since news does not permit multiple parents, you can't use it as a
counter example that this sort of thing isn't useful.

>That would be wonderful.

    I will see what I can do.

>seem useful.

    Unfortunately, you don't seem to have followed up your previous
research to see if there are groups of people whom you do not normally
have discussions with but who make use of the multiple parent feature of
RFC 822.

    Please don't mis-understand -- I'm not blaming you, I'm just saying
that this is an important step, one which does not appear to have yet
been taken.  Maybe in my research, I can turn up some usernames and get
data from them as to what MUA they use, what types of groups they
typically communicate with, etc....

>              If you want to argue that they are used and are useful,

    I can't say that I've seen them in person, however I can say that I
can see the feature as being potentially useful, and I can add that there
are others in this WG that have advocated them (and who have lead me to
believe that they have actually seen them in person).

    If we can conceptually accept the concept of a hard link to a
filename in Unix, and represent this fact in some fashion in a filesystem
browser, I see no reason why we can't use the same UI features to
represent multiple parents of a message in a MUA.

    That said, if a relatively well-designed statistical survey were
performed and we found that the usage of this feature was vanishingly
small, and we likewise spoke with lots of MUA authors and found an almost
total lack of interest in paying serious attention to this feature, then
I might be willing to stand aside and let DRUMS kill it, if there was a
strong consensus for that action.

    However, I do not believe that we have yet gathered enough
information to support any kind of strong action of this sort (we are
talking about taking away an existing and potentially useful feature,
after all).

>I've tried to rewrite it twice now and been shot down, it's someone

    I'm sorry.  I didn't mean to shoot you down.  I just meant to state
that I have reservations about taking a strong action like this without
what I feel is sufficient evidence or strong consensus.

---

From: Russ Allbery <[email-masked]>
Date: 23 Feb 1999 16:50:12 -0800

> they are today, with hopes towards real convergence somewhere down the

Jamie's probably already on it.  I certainly already am.  Having people on
both is not the problem.

> But you're talking about throwing away existing functionality in order
> to "dumb down" the mail standard on this to be conformant to how Usenet
> news works.

Brad, this is just a ridiculous assertion.  It makes no sense.  People are
pointing out that multiple parents confuses the only *working* threading
model that we have, that mail doesn't currently use this functionality
anyway, and that in practice this functionality has proven near-useless.
This has nothing to do with dumbing things down.

I concur with Jamie here.  Multiple parents is a bad idea.  References has
one well-defined and successful meaning and a lot of bad attempts.  RFC
822 is one of the *worst* attempts.  Going with existing practice that
works is better than trying to allow for data representation that in
practice is very poorly defined and not handled by clients.

And for the record, I *do* regularly reply to multiple messages at the
same time, and my mail reader has that functionality.  So I'm presumably
within the target audience for this feature... except I don't want it, and
consider it a bug, not a feature.  The net result is always confused
threading on the receiver side.

-- 
Russ Allbery ([email-masked])         <URL:http://www.eyrie.org/~eagle/>

---

From: Brad Knowles <[email-masked]>
Date: Wed, 24 Feb 1999 00:02:48 +0100

I think it would take a *very* concerted effort to consolidate the
two sets of standards, and both sides would have to accept a lot of stuff
that they don't like (or don't care about), in order to get the broadest
possible standard that could encompass both of them.  That would mean
that USEFOR would have to accept messages with multiple parents, for example.

    Frankly, I doubt that there's a person or small community of people
in the entire world that have enough will power to make that happen. 
Given that, we might as well keep the things that are distinct for mail
and for which we can come up with good justifications, even if it's just
the last resort of "we don't want to declare overnight that all current
clients and servers are hereby broken".

>mailing lists.

>time (due mainly to the age of the archives.)

    As kre pointed out, this is not a proper sample.  You have
pre-selected content from places that are not likely to have the sort of
thing you were searching for, and therefore you didn't find it.  You now
declare that it can't possibly exist.

    This is like the blind man who has the elephant's trunk who has been
told that there might be these things called legs, but who declares them
nonexistant upon being unable to feel anything other than the trunk.

>If you have better numbers than I do, I'd love to see them.

    I work at the largest residential ISP in Belgium (which isn't saying
much -- the country is only the size of Maryland, we've only got 11
million residents in the entire country, and because of European
telephone tariffs that charge by-the-minute for even local calls, we only
recently celebrated our 100,000th customer).  Most of our users download
all their e-mail with POP3.

    Nevertheless, it would be most instructive if we could get a variety
of places to do this same sort of thing, especially if you could get a
place like mail.com (née iName), hotmail, etc... to do the same.  It
would be a ghodsend if you could get a place like AOL to do this, but
unfortunately they have a proprietary mailbox format that makes this sort
of thing rather difficult.

    I can also look in my own private mailbox archives that go back to
1995 (or earlier).

---

From: Pete Resnick <[email-masked]>
Date: Wed, 24 Feb 1999 01:22:48 -0600

On 2/23/99 at 4:50 PM -0800, Russ Allbery wrote:

> People are pointing out that multiple parents confuses the only 
> *working* threading model that we have, that mail doesn't currently 
> use this functionality anyway, and that in practice this 
> functionality has proven near-useless. This has nothing to do with 
> dumbing things down.

OK, it seems that we might be working toward a stalemate here, so let 
me attempt to cut the knot:

1. In-Reply-To in 822 can take multiple message IDs. The semantics of 
that are clear: multiple parents. So in 822bis let's just define 
In-Reply-To to contain a list of one or more message IDs which is 
formed by taking the contents of the Message-ID field(s) of the 
parent message(s) and be done with it. In the MUA which I write, we 
have been planning to make use of this feature to deal with multiple 
parent replies and I'd like for that use not to be "outlawed" just as 
we release a new feature. News isn't using In-Reply-To anyway, so no 
harm done.

2. Forming a References field from one parent is easy, and Jamie 
provided decent text to do that. So in 822bis let's define References 
to contain the contents of the References field of the parent message 
(if any) followed by th Message-ID field of the parent message (if 
any).

3. Let's put a warning in 822bisthat says trying to form a References 
line from multiple parents is likely to confuse certain clients and 
therefore shouldn't be done. Then one of us bright people can go 
either (a) define a new field which will appear in some other 
document or (b) convince the USEFOR group to define References in 
such a way that it behaves differently in the presense of a 
multi-parent In-Reply-To.

Would this make all sides sufficiently happy and not violate anything 
that is currently going on in the world?

pr
--
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

---

From: Russ Allbery <[email-masked]>
Date: 24 Feb 1999 03:18:14 -0800

Pete Resnick <[email-masked]> writes:

> In-Reply-To to contain a list of one or more message IDs which is formed
> by taking the contents of the Message-ID field(s) of the parent
> message(s) and be done with it. In the MUA which I write, we have been
> planning to make use of this feature to deal with multiple parent
> replies and I'd like for that use not to be "outlawed" just as we
> release a new feature. News isn't using In-Reply-To anyway, so no harm
> done.

> provided decent text to do that. So in 822bis let's define References to
> contain the contents of the References field of the parent message (if
> any) followed by th Message-ID field of the parent message (if any).

> therefore shouldn't be done. Then one of us bright people can go either
> (a) define a new field which will appear in some other document or (b)
> convince the USEFOR group to define References in such a way that it
> behaves differently in the presense of a multi-parent In-Reply-To.

> that is currently going on in the world?

I'm *100%* in favor of this solution.  Thank you.

---

From: [email-masked] (Kai Henningsen)
Date: 01 Mar 1999 19:54:00 +0200

> Mailing lists aren't the best place to find a reply to multiple parents,

Mailing lists, and news, are the *only* places where I have actually seen  
replies to multiple messages. (Those in news obviously picked one as their  
parent; I have no idea what those on mailing lists did, if anything at  
all.)

I've *never* seen it in non-list mail.

> personal mail.

I seriously doubt this assertion. The (not representative, of course)  
evidence I've seen so far points strongly in the opposite direction.

> mail readers know how to deal with them -

Oh, and I seriously question the logic here. It most definitely is *not*  
clearly useful if it's not actually used. In fact, I'd say this makes it  
clearly *not* useful, if anything.

>and incidentally, showing

And of course, the exact same argument works for mailing lists.

> most of the messages' references are ones that have already been seen,

... exactly like in news ...

> less replies considerably less hastily, most times, the "graph" tends

There are? Not in my experience.

> to be meaningless, as most of the relevant messages don't appear.   Much

Most of the relevant messages don't appear because (excuse the language,  
but I'm really frustrated about this) thousands of shitty mail programs  
don't support the feature.

> difficulty for any of that at all.

Actually, they are difficult for the very same reasons. (The tree is in  
you head.)

The very first threading system I used, in a BBS (incidentally, I also  
implemented it, after someone showing me something similar for about  
twenty seconds in another BBS) did this, with +/- for parent/first child,  
</> for last/next sibling, and 0 for return-to-starting-message ("home").  
Worked very well (actually, still works very well, installed base somewhat  
over 100 BBSes and several 10,000 users - and some Internet/Usenet  
gateways).

We thought about implementing multiple parents maybe ten years ago, but  
quickly gave up on the idea when it became clear that there was no easy UI  
for it, and if we couldn't easily find our way through it, no way could  
our users.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 01 Mar 1999 19:36:00 +0200

> Pete Resnick <[email-masked]> writes:

[snipped - we've all seen it]

> I'm *100%* in favor of this solution.  Thank you.

Agree.

MfG Kai

---

From: Robert Elz <[email-masked]>
Date: Tue, 02 Mar 1999 16:39:18 +1100

Date:        01 Mar 1999 19:54:00 +0200
    From:        [email-masked] (Kai Henningsen)
    Message-ID:  <[email-masked]>

  | Mailing lists, and news, are the *only* places where I have actually seen  
  | replies to multiple messages.

I'm afraid I cannot help that.   I use it much more frequently outside
mailing lists.

Eg: one of the things I do is domain name registration.   For that, when
for some reason I am slow processing an application, what usually happens
is that the end client wonders what's up, they call their ISP who did all
the form filling, DNS server establishment, etc (and collected the fees) and
complain.   The ISP says (quite rightly in most cases) "It's not our fault,
its that bastard..."     At that point, it quite often happens that the ISP,
the client, and sometimes their web page designer (or similar) all send me
e-mail saying "what's up with our domain".  (independantly).   As I have no
great desire to respond to each of them separately, saying exactly the same
thing, when I reply (if I reply, but that is a different issue) I am most
likely to reply to all the messages on the topic with a single rpely message.
(At that point, sometimes one or more of the recipients of the reply will
respond, etc).     I would have absolutely no idea how I would select one
of the messages I am replying to as the "canonical parent" for my reply,
that's a ludicrous thing to ask - just as it is for you to demand I send
two or three replies when one will do.

On the other hand, when I see what appears to be a multi-parent reply on
usenet (when I bother to look there) or on a mailing list, what it usually
turns out to be is that the reply is to one of the messages, which was in
turn a reply to another (and another...).   In the reply comments are
made about things stated by multiple of the people, it can look like a reply
to more than one message at once, but that isn't really what it is.

  | I've *never* seen it in non-list mail.

Send me some non-list mail, I will reply to it, and other message (I'll
pick something at random) in one reply...   Then you'll have seen it.

  | Oh, and I seriously question the logic here. It most definitely is *not*  
  | clearly useful if it's not actually used.

Because you don't use doesn't mean it isn't used.  believe me, it *is* used.
Even ancient ucpmail (Mail, mailx whatever you want to call it) allows replies
to multiple messages (it is dumb and can't include text from any in the reply,
automatically anyway, if you reply to more than one, but the reply can be 
done).

  | > most of the messages' references are ones that have already been seen,
  | ... exactly like in news ...

No, for a mailing list, most of the seen messages get deleted as soon
as they're seen.  For usenet, they're stored on the server for some fixed
period of time (typically).   That's the difference between a shared message
store and a private one.

  | Most of the relevant messages don't appear because (excuse the language,  
  | but I'm really frustrated about this) thousands of shitty mail programs  
  | don't support the feature.

No, they don't appear because they're deleted already (which could explain
why many UA's don't bother implementing much in the way of "look back at
old messages" - typically there aren't many to look back at).

I don't know about you, but I receive about a thousand messages a day,
that's about 3Mb.   90% of them are junk, and get deleted very quickly
indeed.

I don't actually do that to drums mail as I consider that to be real work,
but I treated it the same way as most of the other lists I receive, then
in my drums mail today I woudl have seen Philip Hazel's messages, and your
set of messages (that was al that was new).   That is, not a single parent
message would have been around to be found.

kre

---

From: "R. Kelley Cook" <[email-masked]>
Date: Tue, 02 Mar 1999 17:54:17 -0500 (EST)

>useless over the public Internet.

No it doesn't.  

A MUAs communication request goes out over the internet via port 25. 
It talks to the one SMTP server it knows about.  Conversely, that one
server should know that the client is a trusted source.  Most
importantly, it works quite well for over 100 million people everyday.

Unless I was horrendously mistaken, this document is not supposed to be
just for SMTP server to server communications.  By requiring MX lookups
in all instances, Mr. Crocker, Mr. Elz, and Mr. Klensen have changed it
to be so.

 -- Kelley Cook

---

From: "R. Kelley Cook" <[email-masked]>
Date: Tue, 02 Mar 1999 17:47:21 -0500 (EST)

On Thu, 18 Feb 1999 22:22:11 -0500 (Eastern Standard Time), John C
Klensin wrote:

>Internet. 

John,

I disagree with this assertion.  If you are on a dial-up connection to
your ISP, who is connected to directly to the internet, you could
reasonably assume that your computer is connected to the internet and
therefore has to conform to IETF regulations.  

However, your stance for a MUST the MX lookups, does not conform to how
things operate now.  The vast majority of MUAs only relay information
to their ISPs (MX aware) SMTP server using everything in the current
SMTP protocol EXCEPT for MX lookups since there MUAs have been
configured to always send to one particular server.

Are those MUAs running on computers connected to the internet -- yes. 
They have a internet TCP/IP address assigned to them and are usually
able to run most any internet service.

Are their MUAs currently using the command syntax present in RFC822 to
send mail to their ISP SMTP server (which will then will send it on to
the rest of the internet).  In the vast majority of cases -- yes.

By requiring MX lookups, will you exclude the vast majority of users of
RFC822 by eliminating all currently compliant MUAs from the scope of
RFC822bis since they don't -- yes.

Does anyone realistically want MX lookups to be done by all MUAs -- I
am quite certain the answer is no.

In that case, must we write a separate document for how MUAs are
supposed to talk to their ISPs relaying SMTP server -- I hope not,
since it will be 99% the same as 822bis.

 .....

So where do we go from here?

I think we have to include internet connected MUAs into a SMTP spec. 
They do talk (slightly) differently then SMTP-server to SMTP-server. 
But it is sufficently the same.

IMO, Dans suggestion was quite good, IMHO.  Require SMTP authentication
either by trusted host or MX lookups.

In other words rewrite the section on SMTP MX lookups to differentiate
between servers and MUAs.  Fully compliant SMTP servers and relayers
MUST do MX lookups.  Fully compliant SMTP clients SHOULD (MUST?) NOT.

This, IMO, is fully in support of the charter.  No new feature is
added, and more importantly, nothing is deleted from the scope of SMTP.

 -- Kelley Cook

---

From: Dave Sill <[email-masked]>
Date: Wed, 3 Mar 1999 15:59:11 -0500 (EST)

>MUST do MX lookups.  Fully compliant SMTP clients SHOULD (MUST?) NOT.

I agree.

    SMTP + MX = hub or relay (MTA)
    SMTP - MX = leaf node (MUA)

Regardless of what 821bis declares, SMTP refers to the dialogue over
port 25, not SMTP plus everything it takes to be a fully-functional
Internet mail hub.

-Dave

---

From: Brad Knowles <[email-masked]>
Date: Wed, 3 Mar 1999 21:12:57 +0100

>therefore has to conform to IETF regulations.

    Not really.  Do you run an SMTP server on your side of the dial-up
connection, where people are expected to deliver mail directly to your
machine, and is that line up 24 hoursw a day, seven days a week,
fifty-two weeks a year?  Probably not.  In fact, you probably have some
sort of POP3 connection that you pull down mail from, and all your mail
gets delivered to some machine at your ISP.

    The moment that the mail in question is handed from sendmail (or
whatever) to some local delivery agent, you have passed out of what is
considered "The Internet" into alternative mail delivery protocols, and
therefore your client would not be expected to adhere to things like MX
lookup, etc....

    There are some extremely precise definitions of what it means to be
"on the Internet", and these definitions do not necessarily correspond to
what the average user might think of in terms of being "on the Internet".

    Now, maybe what we need to do is lay out very clearly (at the top of
the document) what is considered to be "on the Internet" and what is not,
and at precisely what point you pass from "Internet protocols" (e.g.,
SMTP) to "non Internet protocols".

    I will agree that, no matter what we do, people will write programs
and claim that they speak "SMTP", regardless of whether it's an MTA that
is fully compliant with all the appropriate requirements, or an MUA that
simply dumps all outgoing mail on a pre-configured host name or IP address.

    Therefore, I think we need acknowledge that and make a human label
distinction between the two types of operation, and let them both be
called "SMTP" in some sense, but make one "rSMTP" (restricted/reduced
SMTP) and one just plain "SMTP".

    The latter would be for an MTA that is fully compliant with all the
appropriate requirements that we lay out, while the former would be for
any program that implements an "SMTP-like protocol which is intended to
submit or route electronic e-mail messages on behalf of users".

    Then, when it comes to talking about the "SMTP family of protocols",
we can apply a simple test -- does your program implement all the
features as laid out in sections X, Y, and Z of RFC NNNN?  If so, then it
actually does speak "SMTP".  If not, but it does at least implement all
the minimal features as laid out in only sections P and Q, then it is
said to speak rSMTP.

    Then we would make the further distinction that MUAs would only be
expected to speak rSMTP when uploading mail on behalf of their user(s),
and that they would rely on some other protocol (e.g., POP3 or IMAP) in
order to download mail for their user(s).

    We could then allow (and even encourage) rSMTP (and SMTP as well) to
use an authentication mechanism that would help ensure that the person
(or machine) at the other end really is who he/she/it claims to be, and
start taking steps down the road towards actually breaking initial
message submission down from the "mere" transit of pre-existing messages
from one MTA to another as the e-mail wends its way from the originator
to the recipient(s). 

>able to run most any internet service.

    Again, you fail to understand the extremely precise definition of
being "on the Internet".

>RFC822bis since they don't -- yes.

    No, you just simply define them to be using rSMTP.

>am quite certain the answer is no.

    I will agree with you on that.  However, I think the key is to have
two similar, but slightly different, names for the levels of
implementation of the SMTP protocol.  If we don't do "SMTP" and "rSMTP",
then perhaps "SMTPv1" and "SMTPv2".

>since it will be 99% the same as 822bis.

    It could be as simple as saying that the protocol in 822bis will be
followed, with a certain set of exceptions, and then list the exceptions.

>MUST do MX lookups.  Fully compliant SMTP clients SHOULD (MUST?) NOT.

    I really don't think we want to get into the terms "clients" and
"servers".  These terms have been used in very confusing ways in the
past, and in fact between any two MTAs (otherwise being fully
functional), one of them could be either the "client" or the "server",
depending on which end of the pipe they're on, and what it is they're
serving up (are they making the message available to whatever clients
should receive it, or are they making the reception service available to
whatever clients would like to transmit to it?).

    Think about the X terminology of what is a client versus what is a
server, and what can be a client client or a server client or a server
server or a client server.  AAAAAUUUUUUUGGGGGGGGHHHHHHH!!!!!!!!

---

From: [email-masked] (Kai Henningsen)
Date: 21 Mar 1999 20:06:00 +0200

> what the average user might think of in terms of being "on the Internet".

Which RFC would that be?

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 21 Mar 1999 20:02:00 +0200

>   | Mailing lists, and news, are the *only* places where I have actually
> seen   | replies to multiple messages.
>

I'm afraid I can't help that.

> reply will respond, etc).     I would have absolutely no idea how I would
> select one of the messages I am replying to as the "canonical parent" for my
> reply, that's a ludicrous thing to ask - just as it is for you to demand I
> send two or three replies when one will do.

I demand WHAT?

In a similar situation, I'd pick any one of those messages - probably the  
one best suited to give some context to quote - and reply to that, and cc  
the other people.

> to more than one message at once, but that isn't really what it is.

That's not what I'm talking about. What I see is someone answering to  
several parts of one thread in one "collect" message, usually because they  
feel that separate messages would be a waste.

> pick something at random) in one reply...   Then you'll have seen it.

Ha ha.

> Because you don't use doesn't mean it isn't used.  believe me, it *is* used.

That's a different question altogether.

> Even ancient ucpmail (Mail, mailx whatever you want to call it) allows
> replies to multiple messages (it is dumb and can't include text from any in
> the reply, automatically anyway, if you reply to more than one, but the
> reply can be done).

So then what *did* it do in that case?

> period of time (typically).   That's the difference between a shared message

For one, I've never quite understood why some people delete mail *faster*  
than news. I usually keep news for 14 days, list mail for 60, and personal  
mail for 365. If I feel I want something longer, there's a flag I can set  
to prevent it being expired.

For another, guess what? The sofware I'm using right now (and which seems  
to have a respectable userbase) has exactly one message store it uses for  
both mail and news. (In fact, it can follow threads that cross the medium,  
which happens quite a bit.)

And lastly, from what I hear, quite a number of people keep their mail  
even longer than I do. Of course, places like DejaNews keeps news forever.  
I've recently seen Russ followup to a five month old article.

> No, they don't appear because they're deleted already (which could explain

Not where I look they aren't - see above.

> old messages" - typically there aren't many to look back at).

For your version of "typically", which doesn't seem to have much overlap  
with mine.

I'm reminded of an abbreviation in use in alt.folklore.urban:

TWIAVBP - the world is a very big place (that is, other places can be very  
different)

> that's about 3Mb.   90% of them are junk, and get deleted very quickly

I just looked at some mail logs. 1000-2000 mails per day, say 5 MB. Most  
of it list mail, of course, so (see above) most of it kept for 60 days.  
That should amount to about 300 MB, or half of my message store.

> message would have been around to be found.

Well, neither do I do that to mail, nor do I understand why people would.  
It doesn't match the way I handle list mail, which is in batches, or by  
searching for stuff. Neither of wich works with the fast-delete thing.

MfG Kai

---

From: Robert Elz <[email-masked]>
Date: Mon, 22 Mar 1999 16:38:51 +1100

Date:        21 Mar 1999 20:02:00 +0200
    From:        [email-masked] (Kai Henningsen)
    Message-ID:  <[email-masked]>

  | In a similar situation, I'd pick any one of those messages - probably the  
  | one best suited to give some context to quote - and reply to that, and cc  
  | the other people.

If you're forced to a second rate interface, that's probably the best
you can do.   But you're really replying to all of the messages, there's
no reason to treat one as a "better" one than the others.   Quoting context
is another thing entirely - there's no reason that has to be at all bound 
to any of the messages to which you're replying.   It is entirely reasonable
to quote some context out of a quite different message, like:

[email-masked] said in <[email-masked]>:
   | Which RFC would that be?

and since that message is then referenced, add it to the References (see
the headers...)   (I happened to pick one of your messages just because it
was the last one received from drums before the one to which I am now replying).

  | That's not what I'm talking about. What I see is someone answering to  
  | several parts of one thread in one "collect" message, usually because they  
  | feel that separate messages would be a waste.

Yes, certainly people can do that.   But just because that is one kind of
multi-message reply does not mean it is the only one.

  | > | Oh, and I seriously question the logic here. It most definitely is *not*
  | > | clearly useful if it's not actually used.
  | >
  | > Because you don't use doesn't mean it isn't used.  believe me, it *is* used.
  | 
  | That's a different question altogether.

No it isn't.   Read the initial quote from you.   You said if it isn't
actually used, then it is not useful.   Refuting that simply involves
showing that it is used.

  | > Even ancient ucpmail (Mail, mailx whatever you want to call it) allows
  | > replies to multiple messages
  | So then what *did* it do in that case?

UCB Mail doesn't generate either In-Reply-To or References, so what it
does isn't really relevant here.  However, it does (still) allow replying
to more than one message (it simply constructs a To header out of the
From: headers of all of the messages to which you're replying).

  | For one, I've never quite understood why some people delete mail *faster*  
  | than news.

That's easy.   Mail is in my private mailstore.  It is for me alone.
When I have finished with it, I delete it.  News, on the other hand,
is shared.   Just because I have read it doesn't mean that everyone else
who wants to read it has done so.   Consequently, it is kept "long enough"
for everyone to have had a reasonable chance to read it.

  | I usually keep news for 14 days, list mail for 60, and personal  
  | mail for 365. If I feel I want something longer, there's a flag I can set  
  | to prevent it being expired.

I *never* expire mail.   Ever.   No matter what.   I delete junk, as soon
as I see it (do you really keep "Hi, my name is Sue, and you can see *all*
of me at http://..." which is addressed to you (ie: personal mail) for 365
days???   For me, mail on a list that I receive only because there's a tiny
chance that there may be something relevant is junk as soon as I see it
(except for that one in a thousand message which is of interest, and which
I then keep).  Most lists are archived somewhere anyway, there's no reason
that I need to duplicate that archive (even for a month or two).  I keep
only what I decide has value to me - all the rest is deleted as soon as
I have read it.

  | For your version of "typically", which doesn't seem to have much overlap  
  | with mine.

Whatever.   The point is, as you made a few lines later, there are lots
of different ways of operating all around the world - let's not kill any
of them - for example, by insisting that replies to multiple messages
(will all parents being truly equal) are not permitted.   I won't insist
that you run software that lets you do that, if you see no need for it.
On the other hand, you don't insist that the standards prohibit what I
want to achieve, OK?

  | Well, neither do I do that to mail, nor do I understand why people would. 

As above.  Not everyone is going to work the way you work.
 
  | It doesn't match the way I handle list mail, which is in batches, or by  
  | searching for stuff. Neither of wich works with the fast-delete thing.

Fine.   I can't search back through junk list mail which I have already
determined contains nothing of interest.   Do you think I am suffering
because of that?   Not that this is relevant to anything much.

kre

---

From: Alan Barrett <[email-masked]>
Date: Wed, 24 Mar 1999 10:39:26 +0200 (SAST)

> > what the average user might think of in terms of being "on the Internet".

RFC 1775

--apb (Alan Barrett)

---

From: Randall Gellens <[email-masked]>
Date: Tue, 30 Mar 1999 15:02:01 -0800

>submit or route electronic e-mail messages on behalf of users".

Well, we now have the message submission protocol (RFC 2476) which 
describes the protocol (SMTP with restrictions) and port to be used 
by clients submitting messages, leaving port 25 for server-to-server 
message transport (or relay).

>from one MTA to another as the e-mail wends its way from the originator

RFC 2476 does encourage this, and we now have RFC 2487 (for SMTP over 
TLS) and RFC 2554 (for SMTP AUTH ) to enable it.