Subject: RE: [Mailman-Developers] [[email-masked]:Undeliverable Mail]
From: "Dan Wing" <[email-masked]>
To: "Dan Kohn" <[email-masked]>, "Keith Moore" <[email-masked]>, "Terri Oda" <[email-masked]>
Cc: "Jay R. Ashworth" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 23 Jul 2002 22:22:37 -0700
List-Id: <ietf-822.imc.org>

Send us a screen shot of what your To line looked like,
though.

-d

> -----Original Message-----
> From: Dan Kohn [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 3:39 PM
> To: Keith Moore; Terri Oda
> Cc: Dan Wing; Jay R. Ashworth; [email-masked];
> [email-masked]
> Subject: RE: [Mailman-Developers]
> [[email-masked]:Undeliverable Mail] 
> 
> 
> FYI, Outlook with Exchange Server 2000, does the "right thing".  Here's
> the To lines on an outgoing message:
> 
> From: "Dan Kohn" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> 
>           - dan
> --
> Dan Kohn <mailto:[email-masked]>
> <http://www.dankohn.com/>  <tel:+1-650-327-2600>
> 
> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]] 
> Sent: Tuesday, July 23, 2002 13:38
> To: Terri Oda
> Cc: Dan Wing; Keith Moore; Dan Kohn; Jay R. Ashworth;
> [email-masked]; [email-masked]
> Subject: Re: [Mailman-Developers]
> [[email-masked]:Undeliverable Mail] 
> 
> 
> > Actually, the offending client in this case is Sylpheed, much as I'd
> like to
> > blame outlook. (goodness knows, I blame it for Klez.)
> 
> I take it Sylpheed is the one that generates bogus phrases?
>  
> > I'd have to find someone with a copy of outlook to try it and be sure,
> but I
> > think outlook does "[email-masked]" <[email-masked]> which probably
> > wouldn't have been a problem.
> 
> it might be syntactically legal, but it's still utterly stupid.
> 
> Keith
> 

content-class: urn:content-classes:message
Subject: RE: [Mailman-Developers] [[email-masked]:Undeliverable Mail] 
Date: Tue, 23 Jul 2002 15:39:04 -0700
From: "Dan Kohn" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Terri Oda" <[email-masked]>
Cc: "Dan Wing" <[email-masked]>, "Jay R. Ashworth" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

FYI, Outlook with Exchange Server 2000, does the "right thing".  Here's
the To lines on an outgoing message:

From: "Dan Kohn" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2002 13:38
To: Terri Oda
Cc: Dan Wing; Keith Moore; Dan Kohn; Jay R. Ashworth;
[email-masked]; [email-masked]
Subject: Re: [Mailman-Developers]
[[email-masked]:Undeliverable Mail] 

> Actually, the offending client in this case is Sylpheed, much as I'd
like to
> blame outlook. (goodness knows, I blame it for Klez.)

I take it Sylpheed is the one that generates bogus phrases?
 
> I'd have to find someone with a copy of outlook to try it and be sure,
but I
> think outlook does "[email-masked]" <[email-masked]> which probably
> wouldn't have been a problem.

it might be syntactically legal, but it's still utterly stupid.

Keith

From: Keith Moore <[email-masked]>
To: Terri Oda <[email-masked]>
cc: Dan Wing <[email-masked]>, Keith Moore <[email-masked]>, Dan Kohn <[email-masked]>, "Jay R. Ashworth" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Mailman-Developers] [[email-masked]:Undeliverable Mail] 
Date: Tue, 23 Jul 2002 16:37:33 -0400
Sender: [email-masked]

> Actually, the offending client in this case is Sylpheed, much as I'd like to
> blame outlook. (goodness knows, I blame it for Klez.)

I take it Sylpheed is the one that generates bogus phrases?
 
> I'd have to find someone with a copy of outlook to try it and be sure, but I
> think outlook does "[email-masked]" <[email-masked]> which probably
> wouldn't have been a problem.

it might be syntactically legal, but it's still utterly stupid.

Keith

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "Dan Kohn" <[email-masked]>, "Jay R. Ashworth" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Mailman-Developers] [[email-masked]:Undeliverable Mail] 
Date: Sun, 21 Jul 2002 01:07:48 -0400
Sender: [email-masked]

> Because in Microsoft's Outlook and Outlook Express, if a
> user is in your addressbook and you send a message to that
> user, only their friendly name ("Keith Moore") appears in
> the "To:" line.  You must click your mouse on the name to
> see the user@host form of the name.  The workaround is
> to put [email-masked] in the friendly name field so
> that [email-masked] displays in the "To:" line, which
> is a more natural address for email for many, many
> people.

so those who use Microsoft products lose.  what else is new?

Keith

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Dan Kohn" <[email-masked]>
Cc: "Jay R. Ashworth" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [Mailman-Developers] [[email-masked]:Undeliverable Mail] 
Date: Sat, 20 Jul 2002 18:44:33 -0700
Importance: Normal
Sender: [email-masked]

> perhaps even worse, it's redundant.  why say 
> 
> [email-masked] <[email-masked]>
> 
> or even
> 
> "[email-masked]" <[email-masked]>
> 
> when simply
> 
> [email-masked] 
> 
> will do?  

Because in Microsoft's Outlook and Outlook Express, if a 
user is in your addressbook and you send a message to that
user, only their friendly name ("Keith Moore") appears in
the "To:" line.  You must click your mouse on the name to 
see the user@host form of the name.  The workaround is
to put [email-masked] in the friendly name field so
that [email-masked] displays in the "To:" line, which
is a more natural address for email for many, many 
people.

> a phrase containing another copy of the address conveys no additional 
> information, it just wastes bandwidth and invites stupid mail handling tools
> to play with it.

-d

From: Keith Moore <[email-masked]>
To: "Dan Kohn" <[email-masked]>
cc: "Jay R. Ashworth" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Mailman-Developers] [[email-masked]:Undeliverable Mail] 
Date: Sat, 20 Jul 2002 16:38:12 -0400
Sender: [email-masked]

> "[email-masked] <[email-masked]>" is not legal under RFC 2822.  It is
> must not generate under either current (section 3) or obsolete (section
> 4) grammar.

true, it's illegal to have an '@' in a phrase unless its quoted.
it was illegal in RFC 822 also, which means it's been illegal for 20
years or so.  an '@' can't appear in an atom.

perhaps even worse, it's redundant.  why say 

[email-masked] <[email-masked]>

or even

"[email-masked]" <[email-masked]>

when simply

[email-masked] 

will do?  

a phrase containing another copy of the address conveys no additional 
information, it just wastes bandwidth and invites stupid mail handling tools
to play with it.

Keith

content-class: urn:content-classes:message
Subject: RE: [Mailman-Developers] [[email-masked]:Undeliverable Mail]
Date: Sat, 20 Jul 2002 12:39:22 -0700
From: "Dan Kohn" <[email-masked]>
To: "Jay R. Ashworth" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

"[email-masked] <[email-masked]>" is not legal under RFC 2822.  It is
must not generate under either current (section 3) or obsolete (section
4) grammar.

<mailbox> is defined as "[display-name] angle-addr", <display-name> is a
<phrase>, which is "1*word", where <word> is "atom / quoted-string".
<atom> is defined in section 3.2.4 *not* to include "@".  In other
words, you can't use an unquoted "@" in a <display-name> under either
current or obsolete grammar.

However, you could include the @ as part of a <quoted-string>, defined
in section 3.2.5.  Thus, the following:

  [email-masked] <[email-masked]>     <-- illegal
  "user\@domain.com" <[email-masked]>  <-- legal

I'm cc'ing [email-masked], which has taken the place of
comp.mail.headers, for confirmation.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>

-----Original Message-----
From: Jay R. Ashworth [mailto:[email-masked]] 
Sent: Saturday, July 20, 2002 09:12
To: [email-masked]
Subject: Re: [Mailman-Developers]
[[email-masked]:Undeliverable Mail]

On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote:
> I've been getting these periodically from one of my list members'
servers
> and I'm curious... is 
> 	To: [email-masked] <[email-masked]> 
> really an invalid address?  MailMAX is the only server I've ever seen
thrown
> an error on this.  
> 
> I keep meaning to email them and ask what's up, since it seems like a
bug to
> me, but before I do, does anyone know if this is actually an invalid
address
> and other servers just deal with it?

According to my reading of RFC 2822 3.4, no, it's fine: if a mailbox
can be a name-addr, and a name-addr is a display-name followed by an
angle-addr, then the display-name should be treated as a comment by
any mailre, provided that the angle-addr is syntactically correctly
constructed.

But this is more properly a topic for comp.mail.headers.  (Does that NG
still exist?  ;-)

Cheers,
-- jra
-- 
Jay R. Ashworth
[email-masked]
Member of the Technical Staff     Baylink
RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727
647 1274

   "If you don't have a dream; how're you gonna have a dream come true?"
     -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

_______________________________________________
Mailman-Developers mailing list
[email-masked]
http://mail.python.org/mailman-21/listinfo/mailman-developers

Date: Mon, 8 Jul 2002 10:43:34 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
Cc: [email-masked], Russ Allbery <[email-masked]>, Marc Mutz <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Lawrence Greenfield <[email-masked]>
>    And fetching the envelope structure (or ALL) is so much faster than even 
>    (ALL BODY[HEADER.FIELDS (REFERENCES)])
> 
> Actually, plenty of IMAP servers (such as the Cyrus-derived ones) will
> return References with approximately the same speed as ENVELOPE
> information, since this information is cached in the same place.

But more bandwidth use, which can be a problem. From next week, I'll be in
a place where pigeon-carried IP might be an improvement and expect to care
deeply about bandwidth.

Anyway, I've had luck with fetching only some references fields. The
algorithm goes something like this (rather simplified):

  1. Fetch the subjects.
  2. Group the message roughly by subject.
  3. For each subject group with at least one unthreaded message:
     a. Fetch the references field for the highest-numbered unthreaded
	message in that group.
     b. Use that to thread as many messages as possible.

It becomes a little more complex in reality, particularly if you want to
avoid round-trips, but the concept is fairly simple, and the algorithm
generally doesn't need to fetch very many references fields in order to
make sense of a thread.

--Arnt (doesn't think much of thread=references)

Date: Sun, 7 Jul 2002 17:22:33 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Russ Allbery <[email-masked]>, Marc Mutz <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

   From: Marc Mutz <[email-masked]>
   Date: Tue, 2 Jul 2002 10:45:38 +0200
[...]
   The "problem" is that some mailers (e.g. KMail) depend on in-reply-to to 
   thread messages. Yes, kmail should use References, too, but...
   One of the problems is that the IMAP fetch envelope command only returns 
   in-reply-to, not references:
[...]
   And fetching the envelope structure (or ALL) is so much faster than even 
   (ALL BODY[HEADER.FIELDS (REFERENCES)])

Actually, plenty of IMAP servers (such as the Cyrus-derived ones) will
return References with approximately the same speed as ENVELOPE
information, since this information is cached in the same place.

   So it should be "SHOULD" for both "references" and "in-reply-to".

   BTW: The only misuse of In-Reply-To I've seen is from early versions of 
   mutt 1.2.x or 1.3.x.

Check http://www.jwz.org/doc/threading.html for a good discussion of
the zillions of variations of In-Reply-To. We really should be pushing
people towards References.

Larry

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Tue, 2 Jul 2002 10:45:38 +0200
Content-Description: clearsigned data
Sender: [email-masked]

On Thursday 06 June 2002 22:15, Russ Allbery wrote:
> Keith Moore <[email-masked]> writes:
> >> Also, the SHOULD use "in-reply-to" and MAY use "References" is
> >> silly. In-Reply-To fields are enormously varied and hard to parse;
> >> "References" fields are much better.  We should definitely
> >> encourage people to support References over In-Reply-To.
> >
> > Seems like in-reply-to is more widely supported, though.  I'm
> > curious to hear what other people think about this.  It wouldn't
> > bother me too much to make both of them SHOULD.
>
> References is definitely more widely supported than In-Reply-To for
> actual practical purposes.  Many, if not most, In-Reply-To headers
> contain so much unstructured, extraneous information that they're
> essentially only informational to humans and cannot be effectively
> used by software. References has never had this problem, and is
> therefore clearly superior technically.
>
> I wholeheartedly agree that we should be recommending References over
> In-Reply-To at every opportunity.

The "problem" is that some mailers (e.g. KMail) depend on in-reply-to to 
thread messages. Yes, kmail should use References, too, but...
One of the problems is that the IMAP fetch envelope command only returns 
in-reply-to, not references:

RFC2060:
                     The fields of the envelope structure are in the
                     following order: date, subject, from, sender,
                     reply-to, to, cc, bcc, in-reply-to, and message-id.
                     The date, subject, in-reply-to, and message-id
                     fields are strings.  The from, sender, reply-to,
                     to, cc, and bcc fields are parenthesized lists of
                     address structures.

And fetching the envelope structure (or ALL) is so much faster than even 
(ALL BODY[HEADER.FIELDS (REFERENCES)])

So it should be "SHOULD" for both "references" and "in-reply-to".

BTW: The only misuse of In-Reply-To I've seen is from early versions of 
mutt 1.2.x or 1.3.x.

Marc

- -- 
Marc Mutz <[email-masked]>