Re: Last Call: draft-resnick-2822upd (Internet Message Format) to Draft Standard

John C Klensin <> Sat, 05 April 2008 20:19 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id D241E3A6A44; Sat, 5 Apr 2008 13:19:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 536DE28C38D for <>; Sat, 5 Apr 2008 13:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.013
X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L-v7tH3DiRGt for <>; Sat, 5 Apr 2008 13:19:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D23D28C26B for <>; Sat, 5 Apr 2008 13:19:04 -0700 (PDT)
Received: from [] (helo=p3.JCK.COM) by with esmtp (Exim 4.34) id 1JiEr1-0003PY-CD; Sat, 05 Apr 2008 16:19:12 -0400
Date: Sat, 05 Apr 2008 16:19:10 -0400
From: John C Klensin <>
To: Frank Ellermann <>,
Subject: Re: Last Call: draft-resnick-2822upd (Internet Message Format) to Draft Standard
Message-ID: <1C6AF6C07BA71958E4092D98@p3.JCK.COM>
In-Reply-To: <ft85nn$sga$>
References: <> <><ft57m4$csu$> <8BB8410A1437A8973C333DCE@p3.JCK.COM> <> <ft85nn$sga$>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

--On Saturday, 05 April, 2008 17:29 +0200 Frank Ellermann
<> wrote:

> Brian E Carpenter wrote:
>> John's message reached me with X-Original-To,
> A draft about Original-* didn't make it so far, it could
> be classified as "could be specified if folks go to the
> trouble to try it".  IMO it's no bug in 2822upd if nobody 
> tries it.  RFC 3864 would have to be updated for generic
> Original-* registrations.
>> X-Virus-Scanned, X-Spam-Flag, X-Spam-Score, X-Spam-Level,
>> X-Spam-Status,
> Hopefully these header fields are specified in the manual
> of anti-spam tools used by MTAs on your side.

This is precisely the reason why, although I think the sort of
text I suggested would be useful, I don't think we should go
much further down that path.  Most of these fields would be
reasonable candidates for the "private use" category -- they are
used to communicate between what SMTP sees as the final delivery
MTA and the message store and/or receiving MUA (either
server-side or client-side in split MUA models).    If one tried
to define "private use" (and I suggest that we do not) part of
the process would involve asking the question "could this be
standardized in 2821* or used-on-the-Internet-wire-2822*".   For
these things that communicate among modules on the far side of
the final delivery MTA, the answer is that any standardization
would have to occur in IMAP or POP, or in the never-defined
message store standard, but not in SMTP.   Maybe LTMP, used as a
message store protocol, changes that and maybe it does not (the
fact that it is Informational and not standards-track doesn't
help), but you see where this line of reasoning is headed.

And, speaking personally, I don't care whether private use
headers use non-X field names and are registered.   What I want
to push back against is (i) intentional use of X-headers for
non-private-use applications and (ii) anything (including (i))
that would create a requirement (or strong reason) to register
anything starting with "X-".

In any event, sorting out those special-use header fields is not
a problem for 2822bis.

>> X-Mailman-Version
> In the direction of User-Agent and tracing.  It's hard to
> define what constitutes "potential useful info", and the
> security / privacy / I18N considerations for header fields
> can be also rather tricky.  Maybe an informative reference
> to RFC 4249 in 2822upd would be good.
>> Leaving this completely undocumented harms the relevance
>> of the standard.
> The RFC 3864 reference in 2822upd is informative, would a
> normative reference help for your conerns ?

IMO, probably not.  More important, I'd really object to
standardizing a version specification for a single type of
redistribution software.  If this is needed at all, it should
probably be turned into something like
  List-Exploder: <name>, <version>
and that, of course, would be part of a different spec entirely.


IETF mailing list