Subject: Outstanding issues for smtpupd-12

From: John C Klensin <[email-masked]>
Date: Wed, 07 Jun 2000 16:10:27 -0400

DRUMS participants,

I have received comments on smtpupd-11 from very few people,
but they have been extensive.  Most of them are editorial,
straightforward, and have been incorporated into the working
copy that will become -12 (which I hope will be the end of
this overlong and overdue process).  The comments did raise a
few questions that I think the WG needs to address, especially
since, in a few cases, I got both "make it weaker" and "make
it stronger" comments.  

In no particular order (since I'm still working on the -12 
routine/editorial) stuff, there might be more to come)...

(i) CRLF line termination (and use of bare CR and bare LF).

  The current text prohibits the recognition of bare CR and
  bare LF as line terminators, but stops there.  This leaves
  an ambiguity as to where else (if at all) they can appear
  "bare".  Possibilities include:

  (a) Prohibit _all_ appearances of bare CR and LF.  This is at
  least clear.

  (b) State clearly that bare CR and bare LF are permitted in
  running text, but are to be considered as textual
  characters, never line terminators.  This probably causes
  interoperability problems but is, in principle, possible (it
  was also, if I recall, the normal interpretation, especially
  for LF, in the early 70s).

  (c) Give it up and permit (or require) them as line
  terminators, possibly by making a "generate/ accept"
  distinction (a technique that is not used significantly in
  the 821bis document).

(ii) 251 and 551 response codes.

  The present text deprecates 251 but continues to
  tolerate 551.  Like 251, 551 implies capabilities that are
  properly supported by almost nothing today and that may not
  even be workable in today's typical client-server/ split-UA
  world (as distinct from having the SMTP sender running in
  the user's process on the same originating machine).  It
  appears that we should just deprecate both.  Comments or
  disagreement?

(iii) The last sentence of section 4.5.1 ("This requirement
  does not imply that SMTP systems must deliver Postmaster
  mail in particular cases (e.g., problematic origin
  addresses) in which they have substantive reasons for not
  doing so.") was written in response to considerable WG
  discussion about cases in which it should not be a
  requirement to deluge the postmaster with trash.  The
  language I chose probably creates a larger loophole than was
  really intended, and conformance to this requirement is not
  testable on the wire anyway (unless the non-conforming
  implementation bounces, rather than discards, the apparent
  postmaster mail). 

  Should the statement be changed and, if so, to what?  Chris
  suggested:

     SMTP systems are expected to make every reasonable effort
	 to accept mail directed to Postmaster from any other
	 system on the Internet.  However, in extreme cases, it
	 may be necessary to block all mail from a given
	 origination address or domain to prevent denial of
	 service attacks, and this requirement is not intended to
	 preclude SMTP systems from offering such security
	 facilities when unavoidable.

  Is that ok with everyone?  If not, specific text suggestions
  would be appreciated here. 

(iv) The text, borrowing from RFC 821 if I recall, makes
  several statements about "128 ASCII characters".  The
  original intent was, I believe, just that.  But the
  widespread use of NULL as a string terminator and elsewhere
  causes a lot of problems and/or tricky code if interpreted
  literally and may not be worth it.  Any objections to
  changing this to "127" and essentially prohibiting the use
  of NULL?

 --john

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 7 Jun 2000 16:02:55 -0700

>   distinction (a technique that is not used significantly in

Slight preference for (a) over (c), but think (b) is very likely to 
cause lack of interoperability and confusion.

>(ii) 251 and 551 response codes.

Deprecate both.

>(iii) The last sentence of section 4.5.1

Chris' text is very good, and more clear than the current text.

>(iv) . . . Any objections to

Sounds good.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Allbery <[email-masked]>
Date: 07 Jun 2000 17:01:39 -0700

> cause lack of interoperability and confusion.

My preference is likewise for (a).

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Keith Moore <[email-masked]>
Date: Wed, 07 Jun 2000 20:40:15 -0400

re: 251 vs. 551 - I would deprecate 251 only.  551 is still useful.
(and it does get used occasionally)

Keith

---

From: Robert Elz <[email-masked]>
Date: Thu, 08 Jun 2000 16:18:34 +1000

Date:        Wed, 07 Jun 2000 16:10:27 -0400
    From:        John C Klensin <[email-masked]>
    Message-ID:  <2616520932.960394227@JKLENSIN01>

  | (i) CRLF line termination (and use of bare CR and bare LF).

Anything but (c).

  | (ii) 251 and 551 response codes.

I'd actually prefer to keep them both, they're harmless.   But if
it is too late for 251 (which I can't say I've ever seen used, 250
is generally used when 251 would technically be correct) at least
keep 551 (which as Keith said, is used).

  | (iii) 
  |   Should the statement be changed and, if so, to what?  Chris
  |   suggested:

Looks good.

  | (iv) 
  |   Any objections to
  |   changing this to "127" and essentially prohibiting the use
  |   of NULL?

Fine, do it.

kre

---

From: Jacob Palme <[email-masked]>
Date: Thu, 8 Jun 2000 15:11:03 +0200

> 	 facilities when unavoidable.

Denial of service attacks by clever attackers may not be
detectable by a "given origination address or domain".
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Jun 2000 11:23:25 -0400

> detectable by a "given origination address or domain".

I think we all know that.  How would you suggest changing the
text, if at all?  Or would you recommend trying to prohibit any
such action on the theory that it wouldn't always work?

    john

---

From: Wilbert <[email-masked]>
Date: Fri, 09 Jun 2000 01:42:43 +0200

At 11:23 8-6-00 -0400, John C Klensin wrote:
>On 08 June, 2000 15:11 +0200 <[email-masked]> wrote:

prohibit DOS attacks... I'm in favor of that :)

But seriously, I'd prefer the text with some (minor) modifications:

A SMTP system SHOULD make every reasonable effort to accept mail directed
to postmaster@ from any system on the Internet.  In extreme cases, it MAY
temporary block mail from a certain origination address(es) or domain(s) to
evade DOS attacks.

while I'm at it:

(i) CRLF
Prohibit it or allow it in running text. Permitting as line terminators
doesn't seem to make much sense.
A or B... not C, with a preference for option A. 

(ii) 251 and 551 response codes
Indifferent.

(iii) postmaster mail
See above.

(iv) 128 -> 127
Yes...

Gr,
	Wilbert

---

From: Keith Moore <[email-masked]>
Date: Fri, 09 Jun 2000 01:56:14 -0400

> such action on the theory that it wouldn't always work?

I recommend being slightly less specific here about the mechanisms.
The blocking criteria could as easily be something else - 
say, if the message contained a vb script attachment.
e.g.

...it may be necessary to block messages with certain characteristics
when it is known that messages with those characteristics are being
used to mount denial-of-service attacks or other breaches of security.
The requirement to accept Postmater mail is not intended to preclude 
SMTP systems from offering such security facilities.  However, such
facilities SHOULD be narrowly tailored so as to avoid blocking
messages which are not part of such attacks.

Keith

---

From: Peter Koch <[email-masked]>
Date: Fri, 09 Jun 2000 10:18:15 +0200

> temporary block mail from a certain origination address(es) or domain(s) to

There is a very fine line between protocol issues and (local) policy here.
Local policy issues cannot be covered completely anyway, so that ``MAY'' is a
bit too strong. I'm fine with the text in the current draft, but also the
modification suggested in John's first message. However, the latter introduces
the term ``to block all mail'' without defining it (could be inside or outside
of SMTP).

-Peter

---

From: Jacob Palme <[email-masked]>
Date: Fri, 9 Jun 2000 12:23:23 +0200

> messages which are not part of such attacks.

Sounds good. Maybe possibly also add that such blocks
should be limited in time?
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Jun 2000 02:29:54 -0400

--On Friday, June 09, 2000 12:23 +0200 Jacob Palme
<[email-masked]> wrote:

>> The requirement to accept Postmater mail is not intended to
>> preclude SMTP systems from offering such security facilities.
>> However, such facilities SHOULD be narrowly tailored so as to
>> avoid blocking messages which are not part of such attacks.
> 

821bis has so far attempted to be mostly a protocol document and
not a mail policy document.  Since "limited in time" is not
testable on the wire, and could be used by a bad guy to justify
repeated probing until something got through, I'm reluctant to
put this in unless there is strong consensus behind it.

    john

---

From: Keith Moore <[email-masked]>
Date: Sun, 11 Jun 2000 20:48:18 -0400

personally, I think "narrowly tailored" covers time as well as 
other selection criteria for blocking, and it's therefore 
unnecessary to specifically mention time as one of the criteria.

Keith

---

From: Dan Wing <[email-masked]>
Date: Thu, 15 Jun 2000 00:00:40 -0700 (PDT)

> such action on the theory that it wouldn't always work?

Remove the phrase describing how to detect the DoS, leaving, simply:

  SMTP systems are expected to make every reasonable effort to accept mail
  directed to Postmaster from any other system on the Internet.  However,
  in extreme cases -- such as a denial of service attack -- an 
  SMTP system may block mail directed to Postmaster.

-Dan Wing

---

From: "Christian Kuhtz" <[email-masked]>
Date: Fri, 16 Jun 2000 16:46:17 -0400

> From: Dan Wing [mailto:[email-masked]]

I support this approach.  Sounds good.

Cheers,
Chris

--
Christian Kuhtz, Sr. Network Architect              Architecture, BellSouth.net
<[email-masked]> -wk, <[email-masked]> -hm                       Atlanta, GA
                                                    "Speaking for myself only."