Re: empty quoted strings and other oddities

Bruce Lilly <> Thu, 03 October 2002 23:20 UTC

Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g93NK0h26360 for ietf-822-bks; Thu, 3 Oct 2002 16:20:00 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g93NJxv26354 for <>; Thu, 3 Oct 2002 16:19:59 -0700 (PDT)
Received: from ([] by with esmtp (Exim 3.35 #1) id 17xFGD-0007Aa-00; Thu, 03 Oct 2002 19:20:02 -0400
Received: from (localhost []) by with ESMTP id g93NJsEQ015481(8.12.3/8.12.3/SuSE Linux 0.6/2002-07-27 16:10:46); Thu, 3 Oct 2002 19:19:55 -0400
Received: from ( []) by with ESMTP id g93NJqM1015480(8.12.3/8.12.3/Submit/2002-06-01 20:08:15); Thu, 3 Oct 2002 19:19:53 -0400
Message-ID: <>
Date: Thu, 03 Oct 2002 19:19:52 -0400
From: Bruce Lilly <>
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910
X-Accept-Language: en-us, en, fr, ru, ja
MIME-Version: 1.0
To: Keith Moore <>
Subject: Re: empty quoted strings and other oddities
References: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavis-milter (
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>

Keith Moore wrote:

> first of all, it's really not a boundary condition - it's just one example 
> of an invalid address

It's a boundary condition as it's a unique case (zero content).

 > second, your conclusion doesn't follow even if
> it is a boundary condition - all that is necessary is that it not cause
> any problems.

An MTA or MUA that does not handle [] well may indeed cause
problems.  That might range from (multiple) DNS lookups of
garbage, or malformed DNS lookups to a program crash.

> well, it's not like those thousands of existing implementations of email
> software are going to change their implementation techniques just to
> accomodate this case.  

If it becomes a MUST NOT generate construct, damage can be
prevented even if an existing defective implementation of
a receiver does not change.

> as for use of lex, I've tried it.  it's not a good fit.  2822 syntax analysis 
> is somewhat context-dependent (is "Mon" a day or an atom?),  good error 
> recovery is difficult, and you need to have the lexical analyzer recover from
> common syntax errors (such as putting dot in a phrase) in situations where
> look-ahead is required to disambiguate that kind of error from other 
> errors.
> Having done both, I can confidently say that it's easier to write correct 
> C code to do the scanning than to write correct lex code to do it.

Having done both, I've come to the opposite conclusion, but
that's a bit off topic.

> adding cruft to the standard (or to code) to detect cases which
> never happen is not progress.

We're not talking about detection, but rather about relegating
a useless and potentially troublesome construct to MUST NOT
generate status.

> progress is increasing the reliability
> of mail delivery.

Is that relevant to the message format (as opposed to transport
methods and protocols)?