IETF Logo Mail Archive

Re: Negotiated noncompliance

Robert Elz <kre@munnari.OZ.AU> Wed, 23 August 2000 16:35 UTC

Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17963 for <drums-archive@odin.ietf.org>; Wed, 23 Aug 2000 12:35:27 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA08541; Wed, 23 Aug 2000 12:35:08 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 23 Aug 2000 12:35:08 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id MAA08524; Wed, 23 Aug 2000 12:35:07 -0400 (EDT)
Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA08259; Wed, 23 Aug 2000 12:31:16 -0400 (EDT)
Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Wed, 23 Aug 2000 12:31:17 -0400
Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA02380; Thu, 24 Aug 2000 02:30:46 +1000 (from kre@munnari.OZ.AU)
From: Robert Elz <kre@munnari.OZ.AU>
To: Philip Hazel <ph10@cus.cam.ac.uk>
Cc: drums@cs.utk.edu
Subject: Re: Negotiated noncompliance
In-Reply-To: Your message of "Wed, 23 Aug 2000 16:36:04 +0100." <Pine.SOL.4.21.0008231623380.6317-100000@draco.cus.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Aug 2000 02:30:46 +1000
Message-Id: <16579.967048246@mundamutti.cs.mu.OZ.AU>
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

    Date:        Wed, 23 Aug 2000 16:36:04 +0100 (BST)
    From:        Philip Hazel <ph10@cus.cam.ac.uk>
    Message-ID:  <Pine.SOL.4.21.0008231623380.6317-100000@draco.cus.cam.ac.uk>

  | . Space character(s) after MAIL FROM: or RCPT TO:
  | . Local parts containing null components or having dots at either end.

Those ones I'd be willing to simply include as legal in the first place.
I never really understood the dot rule (why they had to be treated so
magically, rather than just being another legal character, in local parts,
I suspect it just made the grammar easier, rather than being expressly
designed, but I am guessing).   But I believe that some others believe that
this is actually important for some reason (maybe some MTA actually enforces 
that rule?)   The spaces I think are totally harmless.

  | . Multiple pairs of <>  e.g.   MAIL FROM:<<user@domain>>

That one I'm less sure about - also no <> at all I think occurrs as well.
I'd be tempted to just ban that noise, and have people fix the broken stuff.

  | I entirely agree. Unfortunately, the commercial world does not, and it's 
  | too late to put certain genies back into their bottles. Managers don't
  | want to be bothered with techical details. "Our clients worked with the
  | old MTA - go make the new MTA work with them too." is something that has
  | been passed on to me more than once. (The old MTA was "forgiving", you
  | see.)

Oh - that isn't the kind of client/server interaction I was imagining.
For that there doesn't need to be this strange "negotiated noncompliance"
where the server just guesses for itself what the client is trying to do.

This is a "known situation" - the server can be expressly configured to
allow the violations committed by known broken clients that have to be
dealt with (that's the kind of thing I meant where I said broken clients
that can't be fixed can just relay through a MTA that will fix things).

I had assumed that this "negotiated non-compliance" stuff was intended for
your average MTA receiving messages from the big wide world of unknown
who knows whats, rather than from the local installed client base (the people
that have to be answered to).

I have no problems at all with MTAs being able to be configured to be
lenient, when their operator finds that is necessary for the environment.
The problem I have is when the MTA simply decides that it should be, without
anyone telling it to relax the restrictions.

kre

v2.13.0 | Report a Bug | By Email