headers
John C Klensin | 6 Jun 22:02

Filtering outgoing messages on DNS names or local-part structure


Hi.

I recently posted draft-klensin-name-filters-01.txt as an I-D. 
It addresses the issues raised by web sites thinking they know 
all of the top-level domain names (so that, e.g., forms that 
specify domains of ".museum" or ".aero" are rejected as invalid) 
and by various applications that are convinced they know the 
valid formats of email local-parts and hence reject 
foo+bar <at> domain, bar/baz <at> domain, and a series of other things as 
invalid.

It is just an analysis and reprise of existing standards, and 
doesn't propose any new standards.  The hope is that, by drawing 
things together into one place, we might have something easy to 
point to and get a bit more conformance.

Comments welcome.

    john
Permalink | Reply | 2 comments |
headers
Pete Resnick | 6 Jun 22:15
Favicon

Multi-message reply and "References:"

[I am sending this message to the IETF-822 <at> imc.org mailing list and I 
am Bcc'ing the USEFOR list. Please post all follow-ups to the 
IETF-822 list; it is a discussion that USEFOR people will be 
interested, but certainly doesn't belong on that list.]

Though I am not working on Eudora full-time anymore, occasionally I 
still do write code and discuss new features. We've got a new feature 
we're implementing in Eudora: Replying to multiple messages. With 
this feature, you can select multiple messages and hit "Reply", and 
Eudora will address the reply to all of the senders of the original 
message (Cc'ing all of the recipients if you say "Reply-to-All"), 
quote the text of those messages in the reply (in some fancy ways 
that have to do with another feature that's being worked on), and 
allow you to edit your reply. That's all well and good.

When the reply is formed, two additional fields appear in the header 
of the message you send: "In-Reply-To:" and "References:". Forming 
the "In-Reply-To:" is easy. You take the message-id's of all of the 
messages to which you're replying and put them in.

But "References:" is a different problem. As it is used in usenet and 
elsewhere now, everything assumes a single rooted thread. But when 
replying to multiple messages, you can end up with a multi-rooted 
thread. And if you reply to two messages that have a common root, you 
end up with branches re-joining. I've got an idea of what a 
"References": field should look like, but I thought others might want 
to give their input.

Below is a message from Steve Dorner with the idea that he and I 
worked out. We'd like a little feedback on the proposal, including
(Continue reading)

Permalink | Reply | 22 comments |
headers
Adam M. Costello | 7 Jun 04:20

Re: Filtering outgoing messages on DNS names or local-part structure


John C Klensin <john+smtp <at> jck.com> wrote:

> I recently posted draft-klensin-name-filters-01.txt as an I-D.
>
> Comments welcome.

Good idea.  I'd love to see web applications stop mangling the plus-sign
in my email address.

Section 3 says:

         Abc\@def <at> example.com

    is a valid form of an email address.

    Conventional double-quote characters may be used to surround strings.

         "Abc <at> def"@example.com

I think the first form is not valid (but the second is).  If I'm not
mistaken, RFCs 821, 822, 2821, and 2822 all agree that quoted-pairs are
allowed in quoted-strings, but not in atoms.

The character you called "acute accent" is actually a grave accent.

Section 4 says "The syntax for URLs (Uniform Resource Locators) is
specified in [4]" (where [4] maps to RFC 1738).  RFC 1738 specifies
the syntax of some URLs, but others (including http and mailto) are
currently specified by other documents.  See the IANA URI scheme
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam M. Costello | 7 Jun 06:03

Re: Multi-message reply and "References:"


Pete Resnick <presnick <at> qualcomm.com> wrote:

> We've got a new feature we're implementing in Eudora: Replying to
> multiple messages.

Mutt does this.

> Forming the "In-Reply-To:" is easy. You take the message-id's of all
> of the messages to which you're replying and put them in.

That's what mutt does, and what RFC 2822 specifies.

> But "References:" is a different problem.

Agreed.  Mutt constructs some list of message-IDs, but it's not obvious
how, and I can't find any documentation (let alone justification) for
the behavior.  RFC 2822 discourages the creation of a References field
for a reply that has multiple parents.

> As it is used in usenet and elsewhere now, everything assumes a single
> rooted thread.  But when replying to multiple messages, you can end up
> with a multi-rooted thread. And if you reply to two messages that have
> a common root, you end up with branches re-joining.

If every message is a reply to at most one message, then the full graph
is a tree, and the ancestry of any one message is a linear chain, which
is easily represented by the References field.

But if every message can be a reply to several other messages, then the
(Continue reading)

Permalink | Reply | 16 comments |
headers
Adam M. Costello | 7 Jun 08:08

Re: Filtering outgoing messages on DNS names or local-part structure


I wrote:

> I never noticed what a nightmare RFC 2368 is in this respect.
>
> This requirement is complete nonsense.

Wow, I really could have found a more tactful way to say that.  I must
have been in an obnoxious mood at that moment, and now I'm embarrassed.
My apologies to the authors.  Speaking of which, I should really glance
at the author list when reading an RFC.  Hi Paul.  :)

Switching to a more constructive mode... if any of the authors of 2368
are reading this, can you remember what the requirement in question was
aiming for?

AMC
Permalink | Reply | 0 comments |
headers
D. J. Bernstein | 7 Jun 08:11
Picon

Re: Multi-message reply and "References:"


RFC 2822 is incorrect when it suggests that References has all of the
message's ancestors. What References actually has is the start of the
thread, followed by the most recent ancestors, ending with the parent.
Ancient ancestors other than the start of the thread are often missing.

(This is explained in various pieces of USENET documentation, and was
pointed out in the discussions that led up to RFC 2822, so there's
really no excuse for RFC 2822 error.)

Threaded readers reconstruct the thread by looking at References in many
messages. This would obviously be necessary even if the naive RFC 2822
model of References were accurate: a message doesn't know anything about
other branches of the same thread, particularly branches that don't even
exist yet. (I have no idea what Costello thinks his proposal is supposed
to accomplish.)

As for multiple parents: This is the only time that I'd recommend
actually putting In-Reply-To into a message. The reader, after seeing
the multiple parents in In-Reply-To, will realize that References is a
mix of ancestor information from those parents. End of problem.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Permalink | Reply | 3 comments |
headers
Adam M. Costello | 7 Jun 08:27

Re: Multi-message reply and "References:"


"D. J. Bernstein" <djb <at> cr.yp.to> wrote:

> (I have no idea what Costello thinks his proposal is supposed to
> accomplish.)

Me neither, actually.  Someone asked how to represent a message's
ancestry when a message can have multiple parents, and I had an idea, so
I volunteered it.  I don't know what the intention was for using that
ancestry information.

AMC
Permalink | Reply | 0 comments |
headers
Bruce Lilly | 7 Jun 18:34
Picon

Re: Multi-message reply and "References:"


> When you reply to a message, you put that message's message-id in the 
> In-Reply-To header.  You copy any References header from that message 
> into the new message, and append the original message-id to it.  So if I 
> have messages 1 (the original), 2 (a reply to 1) and 3 (a reply to 2), 
> the headers look like:
> 
> 1:
>     Message-Id: 1
> 
> 2:
>     Message-Id: 2
>     In-Reply-To: 1
>     References: 1
> 
> 3:
>     Message-Id: 3
>     In-Reply-To: 2
>     References: 1 2

Note that a References header field may appear in contexts other
than a reply: RFC 2046 section 5.2.2.2 specifically permits use
of References with message/partial media types representing
fragments of an original message.  So a large message with id X
may be split for transport into fragments:

Message-ID: 1
Body contains header of original message, including the Message-ID: X
and any References fields (N.B. these are in the *body* of message 1).
(Continue reading)

Permalink | Reply | 4 comments |
headers
D. J. Bernstein | 7 Jun 19:40
Picon

Re: Multi-message reply and "References:"


Bruce Lilly writes:
  [ ignoring newer USENET docs, and apparently misrepresenting RFC 2822 ]
> While RFCs 1036 and 2822 suggest ordering of the msg-ids in the References
> field, there is no requirement to use a specific ordering.  In particular,
> UAs should not presume that the order of appearance of msg-ids in a 
> References field is significant.

In the real world, UAs do pay attention to the order inside References.
It's particularly important for References to start with the thread ID
and end with the parent ID.

My understanding is that trn---which uses References to construct a
thread picture even when some messages are missing---works best when
References is sorted. This is violated by some of the multiple-parent
proposals. Perhaps multiple parents should be handled by simply

   * creating a References field from the newest parent and
   * creating an In-Reply-To field from all the parents.

But I wouldn't support this proposal, or any other proposal, without
seeing a careful investigation of current thread-displaying software.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Permalink | Reply | 2 comments |
headers
Adam M. Costello | 7 Jun 23:22

Re: Multi-message reply and "References:"


"D. J. Bernstein" <djb <at> cr.yp.to> wrote:

> It's particularly important for References to start with the thread ID
> and end with the parent ID.

If a message is a reply to multiple messages then there are multiple
parents, each of which may have a different thread ID, in which case
we'd need multiple References fields in order to satisfy this rule.
RFC 822 allows multiple References fields, but RFC 2822 does not (when
creating new messages).

AMC
Permalink | Reply | 0 comments |

Gmane