[Top] [All Lists]

"More-stuff" in Received fields (was: Re: Transparency)

2005-09-10 23:57:13

--On Sunday, 11 September, 2005 05:38 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

John C Klensin wrote:

  Opt-info = [Via] [With] [ID] [For] [More-stuff]
where More-stuff would be something like
  More-stuff = Keyword-atom String
and with some syntax or handwaving about Keyword-Atom

The "handwaving" must be good enough to find the critical
semicolon before <date-time>.

Yep, or at least maybe.  Never trust me to do syntax while also
thinking about design (that is pretty much why I didn't do the
ABNF in 2821, just pasted it in).   With the understanding that
I'm doing it again and this may not be right either,...

First, even in this form, that would really need to be more like 

   Opt-info = [Via] [With] [ID] [For] *[More-stuff]

generating the option of keyword-value pairs.  
I'm not certain why colon-finding would be hard: one could
either make that
    More-stuff = Keyword-atom Keyword-value
and then define both of those tokens as not permitting
semicolons -- which probably would not prohibit anything
sensible -- or could do something a little more complex with
those rules.

Or one could do something completely different, such as leaving
Opt-info alone and change Stamp to something like

   Stamp = From-domain By-domain Opt-info [CFWS] ";" FWS
                  date-time *[More-stuff]

But, with the variations in practice on date-time fields, it
could be hard to determine where the More-stuff keyword-value
pairs started without a reserved delimiter or known set of
keywords, neither of which would be current practice by any
stretch of the imagination.   To make things worse, I've
certainly seen Received lines without date-time fields (or the
semicolon).  And, while there may be counterexamples, my sense
is that most of the MTAs who put non-standard things into
Received fields do it before the semicolon and date-time or
instead of them.

I think the big point here is that one can't make _any_ change
of this sort lightly.  There are almost always complications.


<Prev in Thread] Current Thread [Next in Thread>