Subject: Re: email-arch: bounce vs... return?
From: SM <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 18 Oct 2007 12:40:39 -0700
List-Id: <ietf-smtp.imc.org>

At 09:59 18-10-2007, Dave Crocker wrote:
>Using the RFC2822 field name Return-Path has obvious appeal, but I 
>am concerned that
>
>    a) it is not in broad use and is restricted to a smaller email 
> geek community -- maybe that's ok?, and

The term may not sound that obtuse to non-technical people.  By 
coining new terms, we create a disconnect between the email "geek" 
community and non-technical people.

>    b) the string really isn't a "path" even tough it might be legal 
> to be -- it's an address, and

It's easier if we leave it as "path" as the person can see that in 
the header.  Path also conveys where the message will be returned if 
it cannot be delivered.

>    c) the non-geek community uses the term 'return address' for 
> mail that contains the same semantic information, albeit from the postal world.

Some people may confuse the "return address" with what they see from 
the visible part of the message.  The difference between the postal 
world and email is that people actually see the envelope whereas 
email hides that information from the recipient.

Regards,
-sm 

Date: Thu, 18 Oct 2007 13:30:45 -0400
From: George Schlossnagle <[email-masked]>
To: [email-masked]
CC: SM <[email-masked]>, [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Dave Crocker wrote:
>
>
>
> SM wrote:
>>> There has been some community input suggesting that "Return [Path] 
>>> address" and "Return Handler" would be better choices.
>>
>> The Return-path is a header with an address which is the 
>> reverse-path.  Reverse-path is better than "Bounce handling 
>> address".  I prefer "Return-path Handler" over "Return Handler" as 
>> people may be able to relate to what they see in a message.
>
> Using the RFC2822 field name Return-Path has obvious appeal, but I am 
> concerned that
>
>    a) it is not in broad use and is restricted to a smaller email geek 
> community -- maybe that's ok?, and
I see this as a benefit, actually.   By using a term that hasn't taken 
on meanings in other contexts you lower the risk of people having 
built-in and hard-to-break assumptions about what it means.

George

Date: Thu, 18 Oct 2007 09:59:24 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: SM <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

SM wrote:
>> There has been some community input suggesting that "Return [Path] 
>> address" and "Return Handler" would be better choices.
> 
> The Return-path is a header with an address which is the reverse-path.  
> Reverse-path is better than "Bounce handling address".  I prefer 
> "Return-path Handler" over "Return Handler" as people may be able to 
> relate to what they see in a message.

Using the RFC2822 field name Return-Path has obvious appeal, but I am 
concerned that

    a) it is not in broad use and is restricted to a smaller email geek 
community -- maybe that's ok?, and

    b) the string really isn't a "path" even tough it might be legal to be -- 
it's an address, and

    c) the non-geek community uses the term 'return address' for mail that 
contains the same semantic information, albeit from the postal world.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Thu, 18 Oct 2007 09:55:24 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
Subject: John Klensin incommunicado until next week
Sender: [email-masked]

John is currently unable to see his normal email mailbox, so will be
unable to respond to any of the threads going on right now until next week.

But keep those cards and letters coming. If we can hash out the issues
without his input, that would be good.

	Tony Hansen
	[email-masked]

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  ISSUE: terminology (was: Mailing List Last Call now open for draft-klensin-rfc2821bis-05.txt)
Date:  Thu, 18 Oct 2007 10:50:33 +0200
Lines: 29
Sender: [email-masked]

Hi,
=20
as already noted by several contributors the definitions in
2821bis section 2.3 are (apparently) verbatim copies of the
corresponding BCP 14 definitions (sections 1..5).

In the interest of readers I propose to reduce section 2.3:

| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20
| "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
| and "OPTIONAL" in this document are to be interpreted as
| defined in RFC 2119 sections 1-5.

With that wording any strange objections that 2821bis might
not exactly adhere to the guidance in section 6 of BCP 14
are doomed.

The draft could even adopt Bruce's style and only define the
terms actually used in the draft:  I found no occurence of
REQUIRED, SHALL, SHALL NOT, RECOMMENDED, NOT RECOMMENDED, or
OPTIONAL in the body of 2821bis-05.  With that we'd get:

| The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
| and "MAY" in this document are to be interpreted as
| defined in sections 1-5 of RFC 2119.

Idnits will holler, but that's okay. =20

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis?
Date:  Thu, 18 Oct 2007 08:41:05 +0200
Lines: 17
Sender: [email-masked]

Ned wrote:

> We are way past the point where backwards compatibility is an
> acceptable excuse for something like this.

I'm curious if somebody can produce an example, where NO-WS-CTL
is actually needed in "domain literals" of an existing network
using SMTP and/or the Internet Message format.  At the moment I
still think that it's not even "backwards compatible", it's a
hypothetical "IPvFuture" construct incompatible with RFC 3986.

> if common sense isn't enough here, how about the fact that it
> is pretty clear that these things have obvious and severe
> interoperability problems that will make it hard to meet the
> criterua for draft standard?

 Frank

Date: Wed, 17 Oct 2007 15:01:13 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Hi Dave,
At 12:48 13-10-2007, Dave Crocker wrote:
>In the Internet Mail Architecture draft:
>
>    <http://www.ietf.org/internet-drafts/draft-crocker-email-arch-09.txt>
>
>There terms "Bounce Handler" and "Bounce address" are used.  As the 
>document notes, the terms are not the nicest, but they seem to be 
>the most prevalent.
>
>(Earlier drafts attempted to use the term "Notices" but this gained 
>to traction.)
>
>There has been some community input suggesting that "Return [Path] 
>address" and "Return Handler" would be better choices.

The Return-path is a header with an address which is the 
reverse-path.  Reverse-path is better than "Bounce handling 
address".  I prefer "Return-path Handler" over "Return Handler" as 
people may be able to relate to what they see in a message.

Bounce unfortunately has a negative connotation given the reject 
versus bounce debate.

Regards,
-sm 

Date: Wed, 17 Oct 2007 11:14:22 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Tony Finch wrote:
> On Wed, 17 Oct 2007, Tony Finch wrote:
>> What is special about the return path is that it's the only address to which
>> bounces may be sent, and it isn't used for other kinds of response.

What about its use for positive DSNs?

Those are not 'bounces'.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 17 Oct 2007 18:58:18 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

On Wed, 17 Oct 2007, Tony Finch wrote:
>
> What is special about the return path is that it's the only address to which
> bounces may be sent, and it isn't used for other kinds of response.

Arnt points out that I should have said "it's only used for auto-
responses". (RFC 3834 of course) I tend to use "bounce" as a shorthand for
"message with a null return path", which is not very accurate since not
all bounces have null return paths (despite what 2821 says) and not all
messages with null return paths are bounces (though they SHOULD all be
auto-replies).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: NORTHERLY 5 AT FIRST IN EAST, OTHERWISE SOUTHEASTERLY 4 OR
5 INCREASING 6 OR 7. MODERATE OR ROUGH. RAIN LATER. GOOD, OCCASIONALLY
MODERATE LATER.

To: Pete Resnick <[email-masked]>
Cc: [email-masked], Frank Ellermann <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
From: [email-masked]
Date: Wed, 17 Oct 2007 13:55:02 -0400
Sender: [email-masked]

--==_Exmh_1192643702_3070P
Content-Type: text/plain; charset=us-ascii

Argh.  Life of Brian.   My brains are tapioca this week - a close co-worker
passed away a few days ago and everything's still a big mess.... 

--==_Exmh_1192643702_3070P
Content-Type: application/pgp-signature

--==_Exmh_1192643702_3070P--

To: Pete Resnick <[email-masked]>
Cc: [email-masked], Frank Ellermann <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
From: [email-masked]
Date: Wed, 17 Oct 2007 13:38:04 -0400
Sender: [email-masked]

--==_Exmh_1192642684_3070P
Content-Type: text/plain; charset=us-ascii

On Wed, 17 Oct 2007 09:46:35 PDT, Pete Resnick said:

> Right now, control characters are allowed in the following:
> 
> - Domain literals on the right hand side of addresses

Are there corresponding RFCs in the pipe that will allow actually doing an MX
lookup of such beasts?  Or ways to use them in a mailto: URI? Or all the *other*
myriad ways that people actually *expect* the right hand side of an address to
work? (Including the "internationalized domain names" effort now underway?)

Otherwise...

Judith: [on Stan's desire to be a mother] Here! I've got an idea: Suppose you
	agree that he can't actually have babies, not having a womb - which is
	nobody's fault, not even the Romans' - but that he can have the *right*
	 to have babies.
Francis: Good idea, Judith. We shall fight the oppressors for your right to
	have babies, brother... sister, sorry.
Reg: What's the *point*?
Francis: What?
Reg: What's the point of fighting for his right to have babies, when he can't
	have babies?
Francis: It is symbolic of our struggle against oppression.
Reg: It's symbolic of his struggle against reality. 

(Monty Python and the Holy Grail)

--==_Exmh_1192642684_3070P
Content-Type: application/pgp-signature

--==_Exmh_1192642684_3070P--

Date: Wed, 17 Oct 2007 09:46:35 -0700
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Cc: Frank Ellermann <[email-masked]>, ietf-822 <[email-masked]>, [email-masked]
Sender: [email-masked]

I've copied this conversation over to ietf-822, since I think that 
will probably be where this issue is addressed.

On 10/17/07 at 6:51 AM -0700, [email-masked] wrote:

>>Peter J. Holzer wrote:
>>
>>>Which reminds me: What is the reason for allowing control 
>>>characters in email addresses?
>>
>>Idiocy.
>
>I try hard to stay out of these sorts of debates, but in this case I 
>am forced to agree. We are way past the point where backwards 
>compatibility is an acceptable excuse for something like this. It 
>should be obvious why  allowing nonprinting control characters in 
>addresses is a bad idea on many levels.
>
>And if common sense isn't enough here, how about the fact that it is 
>pretty clear that these things have obvious and severe 
>interoperability problems that will make it hard to meet the 
>criterua for draft standard?

Right now, control characters are allowed in the following:

- Domain literals on the right hand side of addresses
- Quoted strings (which can be on the left hand size of addresses as 
well as lots of other structured header fields)
- Comments (which can appear in lots of structured header fields 
including address fields)
- Unstructured text (in fields and in the body)

Where are you proposing we should remove controls?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: [email-masked]
Cc: [email-masked]
Date: Wed, 17 Oct 2007 06:51:23 -0700 (PDT)
Subject: Re: Missing ABNF terms in 2821bis?
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> Peter J. Holzer wrote:

> > Which reminds me: What is the reason for allowing control characters
> > in email addresses?

> Idiocy.

I try hard to stay out of these sorts of debates, but in this case I am forced
to agree. We are way past the point where backwards compatibility is an
acceptable excuse for something like this. It should be obvious why  allowing
nonprinting control characters in addresses is a bad idea on many levels.

And if common sense isn't enough here, how about the fact that it is pretty
clear that these things have obvious and severe interoperability problems that
will make it hard to meet the criterua for draft standard?

				Ned

From: Tony Finch <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Date: 17 Oct 2007 12:21:09 +0100
Sender: [email-masked]

On Oct 15 2007, Dave Crocker wrote:
>
>The field does not define a sender.  It defines a receiver.

That is not a very useful way of thinking about it. The return path 
identifies (something to do with) the sender as much as the Sender: and 
From: fields do. The originator fields all define receivers of messages, 
but only those sent in response to the current message, which is a bit 
irrelevant. It's best to talk about exactly one message at a time when 
defining which addresses identify receivers to avoid confusion.

What is special about the return path is that it's the only address to 
which bounces may be sent, and it isn't used for other kinds of response.
Hence the usefulness of VERP techniques.

-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Bounce address
Date:  Wed, 17 Oct 2007 12:16:23 +0200
Lines: 53
Sender: [email-masked]

Hector Santos wrote:
=20
>> Sorry, Hector, I think that's hogwash. =20
> Niceeeeeee!

Yeah, my flame thrower was hot after I read Dave's statement:
| The field does not define a sender.  It defines a receiver.
 <http://permalink.gmane.org/gmane.ietf.smtp/6224>

After considering suggestions for question 1.f in RFC 4858
I somehow managed to attack only your unrelated article. ;-)

 [The SHOULD about DSNs in 2821]
> Good, because unless you have $60 grand to fund the=20
> reprogramming of our system, it ain't going to happen
> anytime soon.

Right, that's your business.  We could discuss what a BCP 14
"SHOULD" means, but after that it's still your business, and
nobody proposed to replace it by MUST in 2821bis or UTF8SMTP.

> Terminologies, especially in regards to the "BOUNCE ADDRESS",
> whether it is RETURN PATH, RETURN ADDRESS, SENDER ADDRESS,
> etc, is always going to be understood by SMTP developers and
> operators.

Yes, and the fun starts when they understand it differently,
with effects like "accept-and-bounce".  Or RFC 1123 5.3.6(a).

> When you refer to end-users or even help desk and/or management
> or marketing, Envelope Sender Address doesn't guarantee=20
> understanding as much as anything else.

It's not difficult to figure out "envelope sender address",
it fits into the usual snail mail analogies.  It's also hard
to come to a wrong understanding, e.g. confuse it with a PRA
or a 2822-Sender.

> Return Address or Sender Address is probably the BEST choice

"Sender Address" is even worse than "Bounce Address", the 2822
Sender isn't necessarily related to the envelope sender.

"Return address" might work.  It kind of misses the point that
there's a responsible actor, the "originator", who submitted
the mail and has to deal with the consequences of this action,
like error reports and other auto-replies.

"Return path" and "return address" are not exactly identical.
IMO "envelope sender address" is a modern term for what used
to be known as "return path", but isn't a path anymore.

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Missing ABNF terms in 2821bis?
Date:  Wed, 17 Oct 2007 09:20:21 +0200
Lines: 7
Sender: [email-masked]

Peter J. Holzer wrote:

> Which reminds me: What is the reason for allowing control characters
> in email addresses?=20

Idiocy.

Date: Tue, 16 Oct 2007 21:26:18 +0200
From: "Peter J. Holzer" <[email-masked]>
To: [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

--eheScQNz3K90DVRs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-10-16 11:02:07 -0700, Douglas Otis wrote:
> Perhaps something like this could be added to RFC2821bis:
[...]
>=20
> NO-WS-CTL       =3D       %d1-8 /         ; US-ASCII control characters
>                         %d11 /          ;  that do not include the
>                         %d12 /          ;  carriage return, line feed,
>                         %d14-31 /       ;  and white space characters
>                         %d127

Which reminds me: What is the reason for allowing control characters in
email addresses?=20

	hp

--=20
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate=20
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"

--eheScQNz3K90DVRs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--eheScQNz3K90DVRs--

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Re: Missing ABNF terms in 2821bis?
Date: Tue, 16 Oct 2007 11:02:07 -0700
To: John C Klensin <[email-masked]>
Sender: [email-masked]

On Oct 15, 2007, at 7:59 PM, John C Klensin wrote:
> --On Monday, 15 October, 2007 16:32 -0700 Douglas Otis
> <[email-masked]> wrote:
>
>> John,
>>
>> Is there a reason for including obsolete definitions for General- 
>> address-literal?
>
> Is there any particularly reason why you think they are obsolete?

It seems that the RFC2821bis draft might wish to decide whether text  
means 0-127 decimal, or means 1-9, 11-12, 14-127 for General-address- 
literal.

Unless there is a reason to include obsolete definitions for General- 
address-literal, it seems better to restate definitions for dcontent  
and exclude obsolete definitions for text and quoted-pair.

Per RFC2822:

In some of the definitions, there will be nonterminals whose names
start with "obs-".  These "obs-" elements refer to tokens defined in
the obsolete syntax in section 4.  In all cases, these productions
are to be ignored for the purposes of generating legal Internet
messages and MUST NOT be used as part of such a message.  However,
when interpreting messages, these tokens MUST be honored as part of
the legal syntax.  In this sense, section 3 defines a grammar for
generation of messages, with "obs-" elements that are to be ignored,
while section 4 adds grammar for interpretation of messages.

quoted-pair     =       ("\" text) / obs-qp

obs-qp          =       "\" (%d0-127)

text            =       %d1-9 /         ; Characters excluding CR and LF
                         %d11 /
                         %d12 /
                         %d14-127 /
                         obs-text

obs-text        =       *LF *CR *(obs-char *LF *CR)

obs-char        =       %d0-9 / %d11 /          ; %d0-127 except CR and
                         %d12 / %d14-127         ;  LF

dtext           =       NO-WS-CTL /     ; Non white space controls
                         %d33-90 /       ; The rest of the US-ASCII
                         %d94-126        ;  characters not including  
"[",
                                         ;  "]", or "\"

NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
                         %d11 /          ;  that do not include the
                         %d12 /          ;  carriage return, line feed,
                         %d14-31 /       ;  and white space characters
                         %d127

dcontent        =       dtext / quoted-pair

Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

General-address-literal  = Standardized-tag ":" 1*dcontent

Standardized-tag  = Ldh-str

                      ; MUST be specified in a standards-track RFC
                      ; and registered with IANA

>>  The 2821bis declares dcontent only defined in RFC2822?
>
> I can't parse this sentence sufficiently to figure out what you are  
> asking

Sorry.  "dcontent" is only used for "General-address-literal" and  
were once included in RFC2821.  Is there current use of General- 
address-literal?  Does this allow some type of tagging per RFC3464 as  
defined in RFC3461?

In other words, is there a definition for this term or terms found  
somewhere else other than RFC2822 that requires the use of these  
obsolete terms?

Perhaps something like this could be added to RFC2821bis:

text-no-eol     =       %d1-9 /         ; Characters excluding CR and LF
                         %d11 /
                         %d12 /
                         %d14-127

dtext           =       NO-WS-CTL /     ; Non white space controls
                         %d33-90 /       ; The rest of the US-ASCII
                         %d94-126        ;  characters not including  
"[",
                                         ;  "]", or "\"

NO-WS-CTL       =       %d1-8 /         ; US-ASCII control characters
                         %d11 /          ;  that do not include the
                         %d12 /          ;  carriage return, line feed,
                         %d14-31 /       ;  and white space characters
                         %d127

Let-dig 	= 	ALPHA / DIGIT
Ldh-str 	= 	*( ALPHA / DIGIT / "-" ) Let-dig
Standardized-tag  = 	Ldh-str

q-pair-no-eol 	=      	("\" text-no-eol)

dcontent-xeol   =       dtext / q-pair-no-eol

General-address-literal  = Standardized-tag ":" 1*dcontent-no-eol

-Doug

Date: Tue, 16 Oct 2007 12:37:28 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Issue:  Section 3.6.2  Leaping into a  822 (DKIM) concept within 821 context
Sender: [email-masked]

Small nit:

I understand it makes people feel good to throw in DKIM work into this 
section, but DKIM has nothing to do with the Return Path verification 
insights provided here in 3.6.2 paragraph two.

3.6.2. Mail eXchange Records and Relaying

    ....

    This specification does not deal with the verification of return
    paths for use in delivery notifications.  Recent work, such as that
    on SPF [42] and DKIM [43] [44], has been done to provide ways to
    ascertain that an address is valid or belongs to the person who
    actually sent the message.  A server MAY attempt to verify the return
    path before using its address for delivery notifications, but methods
    of doing so are not defined here nor is any particular method
    recommended at this time.

SPF is fine because it is 100% related to the return path.  DKIM is 
independent and has nothing to do with the return path.

The nit is that this section talks purely about the return path, then 
throws in an unrelated 822 idea and concludes with a return path idea as 
it was all related - they are not.

If we want to reference DKIM in 2821bis, I think it will fit better in 
any DATA discussions, possibly stating but not exclusive to:

    "A server MAY attempt to verify the MAIL TRANSACTION which includes
    822 considerations using recent work such as DKIM [43]"

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Tue, 16 Oct 2007 09:15:05 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: email-arch: terminology
Sender: [email-masked]

Tony Finch wrote:
> On Mon, 15 Oct 2007, Tony Finch wrote:
>> In general I think the email architecture document needs to replace many
>> of its neologisms where there is existing terminology with the same
>> meaning.
> 
> Dave has asked me to expand on my grumble.

And Dave now VIGOROUSLY encourages others to respond to Tony, so that we can 
get some sense of community preferences.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 16 Oct 2007 17:08:20 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: email-arch: terminology
Sender: [email-masked]

On Mon, 15 Oct 2007, Tony Finch wrote:
>
> In general I think the email architecture document needs to replace many
> of its neologisms where there is existing terminology with the same
> meaning.

Dave has asked me to expand on my grumble.

"email object" - Should be "message".

"Originator" - In *822 this comprises multiple authors, a distinguished
sender, and a list of reply-to addresses. (There's also the return path
which tends to be the same as the sender.) However Email-arch describes it
as comprising one author. In a number of places the draft uses "author"
where "sender" would be more correct per 822, so the "originator"/"author"
synonym is off the mark. I think email-arch would be better off if it
didn't try to lump these concepts together, except for presentational
purposes.

"Source" - Is this supposed to comprise more than the message submission
service? Or is it the whole outgoing email infrastructure of the
originaing domain?

"Dest" - there's a box in a diagram but no description.

"ADMD" - I'd prefer simply "domain", though this is liable to confusion
with domain names.

"Mediator" - I remember it being difficult to find a good word for these
entities, and I think it's still not quite right. To me "mediator" implies
somthing acting on behalf of the other entities to achieve some goal (e.g.
in a non-computing context, mediation to resolve a dispute without going
to court) with active back-and-forth communication between the mediator
and the others. However this email thing is often acting in its own
interest, and the communication is open-loop (section 1.2). I suggest
"intermediary" since it has a closer meaning to what we want (or rather,
less misleading implications), and the adjective "intermediate" leads to
better grammar when describing situations involving intermediaries, e.g.
original source, intermediate dest, intermediate source, final dest (c.f.
section 5).

"Envelope" - The description here is much better than in earlier drafts,
though it fails to explain the rationale for the header/envelope split,
i.e. that basic message relay and delivery can be performed using only the
envelope, and without inspecting the message data but only sticking a
Received: or Return-Path: field (respectively) at the front.

"2821.EHLO" - the table at the start of section 4.1.4 is correct but the
longer paragraph is completely wrong.

Some more general comments.

There's no serious mention of authenticated security boundaries in the
draft. The most significant ones are between the MUA and the MSA (message
submission) and between the MUA and the server message store (POP & IMAP).
(There's also the option of authenticated SMTP relay, though that's
usually by IP address rather than SASL or TLS, and is relatively simple
architecturally.)

The draft sort-of covers message submission in its discussion of the
"Source", though it does not explain the dual-allegiance in terms of
enforcing a security boundary.

The MDA / message store discussion is more confused, because the
boundaries that the draft draws do not correspond to security boundaries.
I'd argue that the MDA and server message store are all part of the MHS,
since they are behind the security boundary that separates MHS
administration from the users.

Should the draft have more to say about "final delivery"? (This fits in
with the terminology discussion above, e.g. "as performed by the MDA at
the final dest".)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: SOUTHWEST BECOMING CYCLONIC, THEN NORTH, 5 TO 7,
PERHAPS GALE 8 LATER. SLIGHT OR MODERATE, OCCASIONALLY ROUGH. OCCASIONAL RAIN
OR DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Tue, 16 Oct 2007 11:34:28 -0400
From: Tony Hansen <[email-masked]>
To: SMTP Interest Group <[email-masked]>
CC: ietf-822 mailing list <[email-masked]>, LEMONADE WG mailing list <[email-masked]>, IMAP extensions mailing list <[email-masked]>, EAI WG mailing list <[email-masked]>, POP3 extensions mailing list <[email-masked]>, USEFOR WG <[email-masked]>
Subject: Mailing List Last Call now open for draft-klensin-rfc2821bis-05.txt
Sender: [email-masked]

This is a "formal" Mailing List Last Call on
draft-klensin-rfc2821bis-05.txt. The last call will last for two weeks
time, ending on October 30, 2007.

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Simple Mail Transfer Protocol
> 	Filename        : draft-klensin-rfc2821bis-05.txt
>...
> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-05.txt

If you go to http://tools.ietf.org/html/draft-klensin-rfc2821bis and
click on [Diff1], you'll see a highlighted list of changes between this
and the previous version.

Major changes for this release are indicated in Appendix G.7.

   G.7.  Changes from version -04 to -05
   1.  Added registry pointers to Section 8 (issue 36).
   2.  "for" clause in Received header reduced to a single mailbox,
       since this seems to reflect list consensus (issue 37).  An
       "additional registered clauses" entry was made to allow for
       future extension (also issue 37).
   3.  Corrected some I-D references to point to now-published RFCs.

At this point, all extant issues are considered closed.

The Mailing List Last Call is now declared open.

Depending on the outcome of the Mailing List Last Call, the next step
will be to submit the document (or its revision) to the IESG for
IETF-wide Last Call.

Thanks!

	Tony Hansen
	[email-masked]

Date: Tue, 16 Oct 2007 09:53:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: Bounce address
Sender: [email-masked]

Frank Ellermann wrote:
> Hector Santos wrote:
> 
>> My only opposition to using exclusively the NDN terminology
>> (because it better matches Moore's document), is the possible
>> notion that Moore's RFC might be interpreted to mean it is
>> now an SMTP requirement which is it not.
> 
> Sorry, Hector, I think that's hogwash.  

Niceeeeeee!

> RFC 2821, I-D.2821bis,
> UTF8SMTP, and Dave's I-D already have NORMATIVE references to
> some DSN RFCs (if that's what you dub as "Moore's RFC").  It's
> actually a SHOULD in RFC 2821 and I-D.2821bis.

Good, because unless you have $60 grand to fund the reprogramming of our 
system, it ain't going to happen anytime soon.

> Using a term like "envelope sender address" won't twist this
> SHOULD into a MUST, and avoiding this term won't twist it into
> a MAY.

Look Franky.

Terminologies, especially in regards to the "BOUNCE ADDRESS", whether it 
is RETURN PATH, RETURN ADDRESS, SENDER ADDRESS, etc, is always going to 
be understood by SMTP developers and operators.

When you refer to end-users or even help desk and/or management or 
marketing, Envelope Sender Address doesn't guarantee understanding as 
much as anything else.  Return Address or Sender Address is probably the 
BEST choice since it at the very least matches the real world snail mail 
concept.

But Bounce Address has always work and continue to work in the context 
of whom you are communicating with.

Furthermore and more importantly which seems to have been forgotten 
here, it is 100% independent of any other PROTOCOL, including any 
phantom ones that are spoken as if they are standards and embedded in 
our lives - they are not.

Finally, BOUNCE traditionally has a very special meaning.  It means the 
entire message was literally BOUNCED back to the sender.  The STYLE in 
which it is done has changed (i.e, DSN) but it is still a BOUNCE.

There is a BIG technical difference between BOUNCE and the idea of a 
"Non-Delivery NOTIFICATION" in which the latter does not necessarily 
have to include the original content.

So I could careless what you guys which want to do with semantics. I 
prefer the improvements in the automations of the systems. I prefer 
technical documents, not just for me, but the future that spells on the 
possibilities, and in the case of a message rejection, the idea of 
echoing back the original message vs sending just a notification should 
be want is discussed.

I hope the above hogwash taste better. :)

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Bounce address (was: email-arch:  bounce vs... return?)
Date:  Tue, 16 Oct 2007 10:46:22 +0200
Lines: 29
Sender: [email-masked]

Hector Santos wrote:

> My only opposition to using exclusively the NDN terminology
> (because it better matches Moore's document), is the possible
> notion that Moore's RFC might be interpreted to mean it is
> now an SMTP requirement which is it not.

Sorry, Hector, I think that's hogwash.  RFC 2821, I-D.2821bis,
UTF8SMTP, and Dave's I-D already have NORMATIVE references to
some DSN RFCs (if that's what you dub as "Moore's RFC").  It's
actually a SHOULD in RFC 2821 and I-D.2821bis.

Using a term like "envelope sender address" won't twist this
SHOULD into a MUST, and avoiding this term won't twist it into
a MAY.

Using the term "envelope sender address" in an I-D that anyway=20
_normatively_ references one of the RFCs where it's defined is=20
perfectly okay, certainly better than any highly controversial
"bounce address" desinformation.

But maybe what you're talking about is the term "non-delivery
notice" (NDN).  You find that already in STD 10 (RFC 821),
later RFC 2821 changed it to "non-delivery report" (NDR), so
that's no prejudice wrt the DSN RFCs.

JFTR, BATV is still an I-D, the DSN RFCs are draft standards.

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Bounce address (was: email-arch:  bounce vs... return?)
Date:  Tue, 16 Oct 2007 10:05:23 +0200
Lines: 42
Sender: [email-masked]

John Leslie wrote:

> Dave Crocker (and others) set out this idea in Bounce Address
> Tag Verification: http://mipassoc.org/batv/

Yes, I know this.  I try to explain why the term "bounce address"
in the context of Dave's I-D is IMO an excessively bad choice:

1 - You've already noted that RFC 2821 still uses "bounce" as a
    synonym for "reject".  RFC 2821bis will fix this, and UTF8SMTP
    avoids this confusion.  But we're not there yet, Dave's I-D
    has to make sense for readers only familiar with RFC 2821.

2 - BATV by design enforces a sound concept of a "BA".  Arguably
    SES, SRS, and redistribution (incl. mailing lists) are also
    built on a sound idea idea of BA.

    Besides the BA in BATV is actually a shorthand for "crypto
    timestamp encoded envelope sender address allowing to
    reconstruct the original envelope sender mailbox in the ADMD
    of the originator" (for Dave's definition of ADMD).  That's
    a mouthful, and BA is a nice shorthand for this concept.

    OTOH Dave's BA cannot guarantee that it's in the ADMD of the
    originator, it can be in an unrelated ADMD of a 3rd party
    without prior consent of its administrator.  For various
    reasons that could be very wrong, it also doesn't reflect
    the original idea of a hop-by-hop return path.

3 - Last but not least Dave claims that the term "return path"
    was always wrong, it should have been BA.  IMO that's not
    the case, quite the contrary, 821 SMTP was well designed.

    It was the removal of reverse routes while keeping 1123
    5.3.6(a) forwarding that caused in essence most problems=20
    with mail today.

IOW, the established term "envelope sender address" is far better
than "bounce address", the former is correct, the latter should
be limited to contexts like BATV.

 Frank

Date: Mon, 15 Oct 2007 22:59:50 -0400
From: John C Klensin <[email-masked]>
To: Douglas Otis <[email-masked]>
cc: [email-masked]
Subject: Re: Missing ABNF terms in 2821bis?
Sender: [email-masked]

--On Monday, 15 October, 2007 16:32 -0700 Douglas Otis
<[email-masked]> wrote:

> John,
> 
> Is there a reason for including obsolete definitions for
> General-address-literal?

Is there any particularly reason why you think they are obsolete?

>  The 2821bis declares dcontent only defined in RFC2822?

I can't parse this sentence sufficiently to figure out what you
are asking

   john

Cc: [email-masked]
From: Douglas Otis <[email-masked]>
Subject: Missing ABNF terms in 2821bis?
Date: Mon, 15 Oct 2007 16:32:10 -0700
To: John C Klensin <[email-masked]>
Sender: [email-masked]

John,

Is there a reason for including obsolete definitions for General- 
address-literal?  The 2821bis declares dcontent only defined in RFC2822?

-Doug

Date: Mon, 15 Oct 2007 15:36:06 -0400
From: George Schlossnagle <[email-masked]>
To: Tony Finch <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Tony Finch wrote:
> On Sat, 13 Oct 2007, Dave Crocker wrote:
>   
>> There has been some community input suggesting that "Return [Path] address"
>> and "Return Handler" would be better choices.
>>     
>
> I think these are better since they are closer to the terms used in the
> standards for over 25 years, and to the name used for the field in the
> message header after final delivery which end-users see. "Bounce" has too
> many meanings.
>
> In general I think the email architecture document needs to replace many
> of its neologisms where there is existing terminology with the same
> meaning.

I agree with Tony.  Return-Path has been in use at least since RFC 822 
(the 25 years above), is well-understood by most if not all technical 
people operating in the world of mail, and is neither ambiguous nor 
suffers from having been overloaded with other meanings (as 'bounce' has).

George

Date: Mon, 15 Oct 2007 19:54:58 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

On Sat, 13 Oct 2007, Dave Crocker wrote:
>
> There has been some community input suggesting that "Return [Path] address"
> and "Return Handler" would be better choices.

I think these are better since they are closer to the terms used in the
standards for over 25 years, and to the name used for the field in the
message header after final delivery which end-users see. "Bounce" has too
many meanings.

In general I think the email architecture document needs to replace many
of its neologisms where there is existing terminology with the same
meaning.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Mon, 15 Oct 2007 14:32:10 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

John,

First, do we have a choice here?  I don't think so, so it would be a 
waste of time to blew against this wind.

But I have two comments:

1) I think this is yet another example of RFC editor vs audience 
conflict. In my view the RFC document style generally mix two 
disciplines - technical and functional specifications.  IMO, "Bounce" 
covered all disciplines, including support and end users.  In our 
experience, however, terms like "failure," "Error," and/or "reject" has 
always typically been expressed or reported by end-users.  So if you 
want to make it more technical, I think you should be aware that may not 
the best for other disciplines.

2) My only opposition to using exclusively the NDN terminology (because 
it better matches Moore's document), is the possible notion that Moore's 
RFC might be interpreted to mean it is now an SMTP requirement which is 
it not.   So as long it doesn't raise any false idea or ambiguity that 
an NDN reference in 2821bis does not mean a direct support for Moore's 
RFC, I personally have no problem with the bounce term deprecation in 
2821bis.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

John C Klensin wrote:
> 
> 
> --On Monday, 15 October, 2007 11:24 -0400 "David F. Skoll"
> <[email-masked]> wrote:
> 
>> I think we should avoid "bounce" completely.  We should say
>> "reject with an SMTP failure code" and "generate a failure
>> notification message" because those phrases are unambiguous.
> 
> This is more or less what 2821bis does now.   
> 
> The old "bounce" terminology was removed, not because of any
> conspiracy, but because, if one read other documents that were
> floating around, and other meanings (including the "bounce to
> someone else" that you mention), it was clear that the term had
> become ambiguous unless the reader read 2821 (or 821) very
> carefully and kept their definitions separate from others that
> might be floating around.   While I was sorry to see it go for
> various historical reasons, ambiguity, even apparent ambiguity
> based on sloppy reading, serves no one well.   It is in our
> interest to eliminate it when that isn't too painful.
> 
> I think Dave (Crocker) is now asking the same question about
> email-arch.     I didn't take his note as an invitation for
> people to propose new terminology that had not been actively
> used before, no matter how attractive that terminology might be.
> 
> My only reservation about some of the suggestions is that I
> don't think we get ahead by introducing yet more terminology.
> As with "bounce" some people will draw some analogies and
> decided the meanings for the new terms are obvious.  Others may
> find them less obvious, or even that they obviously mean
> something else.
> 
> Where precision is needed, it seems to me that we have two basic
> alternatives:
> 
> 	(i) Use terminology similar to that suggested above,
> 	which is very clear, very precise, and avoids trying to
> 	reify everything down to a single term whose meaning we
> 	hope is clear.
> 	
> 	(ii) Use the established precise terminology when needed
> 	to talk about addresses, which, for this case, is
> 	"backward-pointing [envelope] address" or
> 	"reverse-pointing [envelope] address".  It is clumsy
> 	but, again, there is no ambiguity.
> 
> The main reason I mentioned the new usage in 2821bis is that I
> don't think it helps us to introduce terminology in the
> architecture document that is inconsistent with the terminology
> used in the base specifications.  If the architecture document
> uses one term to refer to a given concept, and the base protocol
> specifications use a different term, the readers are left
> wondering whether there is actually a difference that must be
> understood or whether we are just confused and trying to get
> them to join us in our confusion.
> 
>      john
> 
> 
> 

Date: Mon, 15 Oct 2007 13:16:25 -0400
From: John C Klensin <[email-masked]>
To: "David F. Skoll" <[email-masked]>
cc: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

--On Monday, 15 October, 2007 11:24 -0400 "David F. Skoll"
<[email-masked]> wrote:

> I think we should avoid "bounce" completely.  We should say
> "reject with an SMTP failure code" and "generate a failure
> notification message" because those phrases are unambiguous.

This is more or less what 2821bis does now.   

The old "bounce" terminology was removed, not because of any
conspiracy, but because, if one read other documents that were
floating around, and other meanings (including the "bounce to
someone else" that you mention), it was clear that the term had
become ambiguous unless the reader read 2821 (or 821) very
carefully and kept their definitions separate from others that
might be floating around.   While I was sorry to see it go for
various historical reasons, ambiguity, even apparent ambiguity
based on sloppy reading, serves no one well.   It is in our
interest to eliminate it when that isn't too painful.

I think Dave (Crocker) is now asking the same question about
email-arch.     I didn't take his note as an invitation for
people to propose new terminology that had not been actively
used before, no matter how attractive that terminology might be.

My only reservation about some of the suggestions is that I
don't think we get ahead by introducing yet more terminology.
As with "bounce" some people will draw some analogies and
decided the meanings for the new terms are obvious.  Others may
find them less obvious, or even that they obviously mean
something else.

Where precision is needed, it seems to me that we have two basic
alternatives:

	(i) Use terminology similar to that suggested above,
	which is very clear, very precise, and avoids trying to
	reify everything down to a single term whose meaning we
	hope is clear.
	
	(ii) Use the established precise terminology when needed
	to talk about addresses, which, for this case, is
	"backward-pointing [envelope] address" or
	"reverse-pointing [envelope] address".  It is clumsy
	but, again, there is no ambiguity.

The main reason I mentioned the new usage in 2821bis is that I
don't think it helps us to introduce terminology in the
architecture document that is inconsistent with the terminology
used in the base specifications.  If the architecture document
uses one term to refer to a given concept, and the base protocol
specifications use a different term, the readers are left
wondering whether there is actually a difference that must be
understood or whether we are just confused and trying to get
them to join us in our confusion.

     john

Date: Mon, 15 Oct 2007 09:55:03 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: "Carl S. Gutekunst" <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Carl S. Gutekunst wrote:
> It certainly seems sensible; my only hesitation is simply that I haven't 
> heard it used before, despite the wide-spread recognition of the 
> Return-Path header field. I'm certainly in a position to use it and see 
> people's reactions, though.

It's clear that at least some (substantial) portion of the email community is 
solidly entrenched in using a term that includes the word 'bounce'.  For that 
group, we are definitely talking about changing their behavior.  On the 
average I am against such efforts, because they almost always fail, especially 
after so much time using the previous term.

However a) there are other constituencies that find the term problematic -- 
which is what prompted my bringing the matter to this list -- and b) this 
thread has done a nice job of showing why continued use of the 'bounce' is 
problematic.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 15 Oct 2007 09:50:50 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: Hector Santos <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Hector Santos wrote:
>
> +1.  What is more fascinating is "who" convinced John K. we have to 
> worry about banning the decades old term. Hilarious. <g>

I didn't think this discussion was about "banning" anything; it's about 
clear and unambiguous language. In all my standards work over the years, 
I'm hard pressed to think of any point with more confusion and ambiguity 
than the many different kinds of "sender" addresses in Internet E-mail.

<csg>

Date: Mon, 15 Oct 2007 09:47:11 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Dave Crocker wrote:
> No one is commenting on the alternative I'm suggesting, which is 
> "return address".
>
> It directly maps to its real function and, of course, the term used 
> for postal mail. 

And everyone knows you put the return address on the envelope.

It certainly seems sensible; my only hesitation is simply that I haven't 
heard it used before, despite the wide-spread recognition of the 
Return-Path header field. I'm certainly in a position to use it and see 
people's reactions, though.

<csg>

Date: Mon, 15 Oct 2007 12:42:45 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "Carl S. Gutekunst" <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Carl S. Gutekunst wrote:

> I've also have heard "bounce" used for an SMTP reject (5xx return), 
> although that was among people who would never read a standard. I'm not 
> real worried about that case; and I've never heard the term "bounce 
> address" used ambiguously. Indeed, the reason I like it is because it 
> has always had 100% recognition even among people who'd never heard the 
> term before.

+1.  What is more fascinating is "who" convinced John K. we have to 
worry about banning the decades old term. Hilarious. <g>

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Mon, 15 Oct 2007 09:37:53 -0700
From: Bill McQuillan <[email-masked]>
To: SMTP Discussion <[email-masked]>
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

On Mon, 2007-10-15, David F. Skoll wrote:
> Jeff Macdonald wrote:
>> perhaps 'inline-bounce' is better? Or 'inband-bounce'? I've heard of
>> both from my MTA vendor.

> "Bounce" has yet another meaning.  I believe Mutt refers to
> redirecting e-mail as "bouncing" it.  In other words, if mail from
> [email-masked] comes in to [email-masked], Bob can "bounce" it
> to [email-masked] and it appears to come from [email-masked].

> I think we should avoid "bounce" completely.  We should say "reject
> with an SMTP failure code" and "generate a failure notification message"
> because those phrases are unambiguous.

"Bounce" causes a lot of confusion, I believe, because it implies that the
same message is being handled. Because of this the redirection usage makes
more sense than the rejection usage.

It seem that rejection should cause, directly or indirectly, a *new*
message which contains rejection information as well as possibly a *copy*
of part or all of the original message to be generated and sent to the MAIL
FROM address.

I think that "return address", analogous to the snail mail equivalent, would
be the best name. (It's interesting that that address is put into the
"Return-Path" header field when the message is finally delivered.)

-- 
Bill McQuillan <[email-masked]>

Date: Mon, 15 Oct 2007 09:18:12 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

> I've also have heard "bounce" used for an SMTP reject (5xx return), 
> although that was among people who would never read a standard. I'm not 
> real worried about that case; and I've never heard the term "bounce 
> address" used ambiguously. Indeed, the reason I like it is because it 
> has always had 100% recognition even among people who'd never heard the 
> term before.

No one is commenting on the alternative I'm suggesting, which is "return 
address".

It directly maps to its real function and, of course, the term used for postal 
mail.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 15 Oct 2007 12:04:21 -0400
From: Jeff Macdonald <[email-masked]>
To: "David F. Skoll" <[email-masked]>
Cc: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

On Mon, Oct 15, 2007 at 11:24:51AM -0400, David F. Skoll wrote:
> 
> Jeff Macdonald wrote:
> 
> > perhaps 'inline-bounce' is better? Or 'inband-bounce'? I've heard of
> > both from my MTA vendor.
> 
> "Bounce" has yet another meaning.  I believe Mutt refers to
> redirecting e-mail as "bouncing" it.  In other words, if mail from
> [email-masked] comes in to [email-masked], Bob can "bounce" it
> to [email-masked] and it appears to come from [email-masked].
> 
> I think we should avoid "bounce" completely.  We should say "reject
> with an SMTP failure code" and "generate a failure notification message"
> because those phrases are unambiguous.

Ah, very clear indeed.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

Date: Mon, 15 Oct 2007 08:48:18 -0700
From: "Carl S. Gutekunst" <[email-masked]>
To: John Leslie <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

John Leslie wrote:
> Frank Ellermann <[email-masked]> wrote:
>   
>> In 2.1.3 you say "bounce handling address".  That's a neologism
>> for a concept that already has more than enough names.
>>     
>
>    I have sympathy for that name. I think we're heading towards
> models where the RFC2821 MAIL FROM points to an MTA near the submission
> server which will redirect DSNs in accordance with directives from
> the originator -- after passing some validity tests.

We (Postini) do that extensively in our SMTP proxy server to manage 
blowback. We aren't currently using a standard like BATV (we could, and 
probably should), but the concept is certainly in production use now.

>    "Bounce" in the name is problemmatic because folks sometimes refer
> to an error _during_ the SMTP connection as a "bounce". This, IMHO,
> is just plain wrong; but perhaps we have already lost that battle...
>   

It's amusing (albeit unhelpful) to note that, in those places where 
Internet Mail and X.400 have the same features, they popularly use the 
same language and terminology. Where we have trouble is features that 
are unique to SMTP; different communities have created different 
language to fill the gap. For example, at Postini, folks have turned 
"500," "400," and "NDR" into verbs, like so:

    "That setting will cause the server to 500 the message."
    "We just four-hundreded the message, so it will retry."
    "Exchange doesn't check addresses in SMTP, so it NDRs the message."

We actually use these with customers, because their complete lack of 
ambiguity makes them immediately understood. Heaven help anyone who 
attempted to codify these into a standard. :-(

I've also have heard "bounce" used for an SMTP reject (5xx return), 
although that was among people who would never read a standard. I'm not 
real worried about that case; and I've never heard the term "bounce 
address" used ambiguously. Indeed, the reason I like it is because it 
has always had 100% recognition even among people who'd never heard the 
term before.

<csg>

Date: Mon, 15 Oct 2007 08:47:37 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

John Leslie wrote:
>> Why not simply use "envelope sender address" as in the DSN RFCs ?
> 
>    I could live with that, too. I tend to think of it as a status
> notification address.

The field does not define a sender.  It defines a receiver.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 15 Oct 2007 11:24:51 -0400
From: "David F. Skoll" <[email-masked]>
CC: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Jeff Macdonald wrote:

> perhaps 'inline-bounce' is better? Or 'inband-bounce'? I've heard of
> both from my MTA vendor.

"Bounce" has yet another meaning.  I believe Mutt refers to
redirecting e-mail as "bouncing" it.  In other words, if mail from
[email-masked] comes in to [email-masked], Bob can "bounce" it
to [email-masked] and it appears to come from [email-masked].

I think we should avoid "bounce" completely.  We should say "reject
with an SMTP failure code" and "generate a failure notification message"
because those phrases are unambiguous.

Regards,

David.

Date: Mon, 15 Oct 2007 10:53:29 -0400
From: Jeff Macdonald <[email-masked]>
To: John Leslie <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

On Mon, Oct 15, 2007 at 07:43:36AM -0400, John Leslie wrote:
>    "Bounce" in the name is problemmatic because folks sometimes refer
> to an error _during_ the SMTP connection as a "bounce". This, IMHO,
> is just plain wrong; but perhaps we have already lost that battle...

perhaps 'inline-bounce' is better? Or 'inband-bounce'? I've heard of
both from my MTA vendor.

-- 
:: Jeff Macdonald | Director of Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

Date: Mon, 15 Oct 2007 15:21:39 +0200
From: Alex van den Bogaerdt <[email-masked]>
To: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Reply-To: [email-masked]
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Oct 15, 2007 at 07:43:36AM -0400, John Leslie wrote:

>    "Bounce" in the name is problemmatic because folks sometimes refer
> to an error _during_ the SMTP connection as a "bounce". This, IMHO,
> is just plain wrong; but perhaps we have already lost that battle...

"Bounce" is indeed problematic, as folks sometimes refer to it
as an email which is received and then sent back.

Older RFCs mentioned in 2821 don't mention "bounce".

RFC2821 has this to say:

2.4
   Delivery SMTP systems MAY
   reject ("bounce") such messages rather than deliver them.

Here "bounce" is an alternative word for "reject".  In all fairness,
the text suggests this is done after receiving the body (i.e. some
5xx code after DATA... <crlf>.<crlf>).

3.4
   Servers MAY reject or bounce messages ...

It isn't clear if this means "choose between reject or bounce", or
rather "reject ("bounce")...".  Codes are 550 or 551, so my money
is on "reject ("bounce")" again.

3.5.3
   Similarly, the discussion in section 3.4 applies to the
   use of reply codes 251 and 551 with VRFY (and EXPN) to indicate
   addresses that are recognized but that would be forwarded or bounced
   were mail received for them.

I read this as 251->forward, 551->bounce.

And then there's the use of bounce in e.g. light.  Light isn't received
and then retransmitted when it bounces.  It is not entering the material
on which it bounces.  So, why would mail enter the MTA?

Date: Mon, 15 Oct 2007 07:43:36 -0400
From: John Leslie <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

Frank Ellermann <[email-masked]> wrote:
> Dave Crocker wrote:
>  
>> There terms "Bounce Handler" and "Bounce address" are used.
> 
> In 2.1.3 you say "bounce handling address".  That's a neologism
> for a concept that already has more than enough names.

   I have sympathy for that name. I think we're heading towards
models where the RFC2821 MAIL FROM points to an MTA near the submission
server which will redirect DSNs in accordance with directives from
the originator -- after passing some validity tests. Dave Crocker (and
others) set out this idea in Bounce Address Tag Verification:

http://mipassoc.org/batv/

and I'm convinced other proposals along these lines will follow.
(Disclaimer: I'm working on one myself.)

> Why not simply use "envelope sender address" as in the DSN RFCs ?

   I could live with that, too. I tend to think of it as a status
notification address.

   "Bounce" in the name is problemmatic because folks sometimes refer
to an error _during_ the SMTP connection as a "bounce". This, IMHO,
is just plain wrong; but perhaps we have already lost that battle...

--
John Leslie <[email-masked]>

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: email-arch:  bounce vs... return?
Date:  Mon, 15 Oct 2007 07:55:40 +0200
Lines: 30
Sender: [email-masked]

Dave Crocker wrote:
=20
> There terms "Bounce Handler" and "Bounce address" are used.

In 2.1.3 you say "bounce handling address".  That's a neologism
for a concept that already has more than enough names.  Why not
simply use "envelope sender address" as in the DSN RFCs ?

-| This Bounce handling address (also known as a Return address)
+| This envelope sender address (also known as Return address)

You could also replace the term "bounce handler" by "envelope=20
sender" for consistency with SMTP and DNS terminology.=20

> This is not an exercise in what any of us would prefer, but what
> we think already has the most traction in the community (or is
> most likely to gain that traction.)

"MAIL FROM" (address) is also in use, but it's clumsy.
"2821-From" (address) certainly isn't better.
"Return" (address or path) is rather conservative, however
 readers might at least know the corresponding header field.
"Reverse path" is too technical, "bounce" (address) is too sloppy.

"Envelope sender" (address) is IMO the best choice.  You could
keep the term "bounce" in figure 3, because it expresses what
happens if an alleged "envelope sender" is NOT the "originator".

 Frank

Date: Sat, 13 Oct 2007 19:10:01 -0400
From: John C Klensin <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: email-arch:  bounce vs... return?
Sender: [email-masked]

--On Saturday, 13 October, 2007 12:48 -0700 Dave Crocker
<[email-masked]> wrote:

> 
> Folks,
> 
> Howdy.
> 
> In the Internet Mail Architecture draft:
> 
> 
> <http://www.ietf.org/internet-drafts/draft-crocker-email-arch-
> 09.txt>
> 
> There terms "Bounce Handler" and "Bounce address" are used.
> As the document notes, the terms are not the nicest, but they
> seem to be the most prevalent.
> 
> (Earlier drafts attempted to use the term "Notices" but this
> gained to traction.)
> 
> There has been some community input suggesting that "Return
> [Path] address" and "Return Handler" would be better choices.
> 
> Again, please note that the document attempts to use whatever
> is already dominant in the community.
> 
> This is not an exercise in what any of us would prefer, but
> what we think already has the most traction in the community
> (or is most likely to gain that traction.)
> 
> I'm soliciting comments.

Dave, I believe the prevalent terminology is "bounce" and that
it has been the prevalent terminology almost as long as I can
remember.  However, because there is a movement to prohibit
non-delivery notification messages and stress SMTP-time
rejections instead, we were persuaded to modify 2821bis to
remove the word "bounce" and more clearly distinguish between
the "rejection" and "NDN" cases.

I suspect this does not answer your question, but it is the only
insight I have on the subject.

     john

Date: Sat, 13 Oct 2007 12:48:54 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: email-arch:  bounce vs... return?
Sender: [email-masked]

Folks,

Howdy.

In the Internet Mail Architecture draft:

    <http://www.ietf.org/internet-drafts/draft-crocker-email-arch-09.txt>

There terms "Bounce Handler" and "Bounce address" are used.  As the document 
notes, the terms are not the nicest, but they seem to be the most prevalent.

(Earlier drafts attempted to use the term "Notices" but this gained to traction.)

There has been some community input suggesting that "Return [Path] address" 
and "Return Handler" would be better choices.

Again, please note that the document attempts to use whatever is already 
dominant in the community.

This is not an exercise in what any of us would prefer, but what we think 
already has the most traction in the community (or is most likely to gain that 
traction.)

I'm soliciting comments.

Thanks.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net