Subject: The "Postmaster" text

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jul 2000 17:09:27 -0400

I've tried to synthesize something from the various suggestions
that seemed to reach agreement among portions of the WG.  Please
consider this a "can you live with this" last call on the
paragraph below.

	SMTP systems are expected to make every reasonable
	effort to accept mail directed to Postmaster from any
	other system on the Internet.  In extreme cases --such
	as to contain a denial of service attack or other breach
	of security-- an SMTP server may block mail directed to
	Postmaster. However, such arrangements SHOULD be
	narrowly tailored so as to avoid blocking messages which
	are not part of such attacks.

This seems to capture the core of Chris's original proposal,
gets rid of the objectionable "mechanism" statement, and adds
Keith's "narrowly tailored" language, which I (and apparently
several others) rather like.

   john

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Jul 2000 21:13:37 -0400

looks good to me.

-Keith

---

From: Peter Koch <[email-masked]>
Date: Sat, 08 Jul 2000 15:01:50 +0200

> 	are not part of such attacks.

The term ``to block mail'' is not defined in the document. It could mean
to silently discard the message or to refuse delivery with an error
indication. In 2.4 the term ``bounce'' is defined ``en passant'', so how
about substituting this word for ``blocking'' here?

-Peter

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 Jul 2000 11:48:24 -0400

Peter,

Based on earlier discussions in the WG about some related
issues, my intent was precisely to leave "bounce or discard"
vague.  There is already a prohibition on discarding mail (in
the "take responsibility once one sends the 250 in response to
DATA ... CRLF.CRLF" section.  But most of us know situations in
which that prohibition needs to be ignored, e.g., when one is
under a sufficiently aggressive spammer attack against
non-existent addresses that bouncing each message individually
only increases system loads and provides potentially-enabling
information to an attacker.  The situation with Postmaster is,
arguably, even worse: we want Postmaster-addressed messages to
be delivered in the overwhelming number of cases; in those that
justify not delivering them, providing information about
non-delivery may be unattractive.

Moreover, in addition to the "bounce" and "discard" cases,
"block" could include "divert, log, and file for possible
subsequent review".

We could, of course, define "block" and include some of the
above discussion, but that would appear to run counter to the
WG's sense that we should not get any further into mechanisms in
that area than needed.

What would you, and others, suggest?

    john

-------------

--On Saturday, 08 July, 2000 15:01 +0200 Peter Koch
<[email-masked]> wrote:

> The term ``to block mail'' is not defined in the document. It
> could mean to silently discard the message or to refuse
> delivery with an error indication. In 2.4 the term ``bounce''
> is defined ``en passant'', so how about substituting this word
> for ``blocking'' here?
> 
> -Peter

---

From: [email-masked] (Kai Henningsen)
Date: 09 Jul 2000 22:21:00 +0200

> What would you, and others, suggest?

Current proposed text looks just fine to me.

MfG Kai

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Jul 2000 23:24:29 +0900

>I've tried to synthesize something from the various suggestions

proposed text looks good.

I like the semantic vagueness of 'block' in this case.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Peter Koch <[email-masked]>
Date: Tue, 11 Jul 2000 11:26:31 +0200

> WG's sense that we should not get any further into mechanisms in

I understand that the text for the exceptional case of ``blocking'' postmaster
mail is aimed at the faction which sometimes confuses protocol documents for
wordings of a law (cf. wild accusations of ``RFC violation'' in Usenet
newsgroups).
So keeping out of this is really a good idea, but the current text is
already in. Thanks for the background info.

-Peter