Subject: Re: out of sequence smtp communication
From: "Hector Santos" <[email-masked]>
To: "Sean Murray" <[email-masked]>, "IETF-SMTP" <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 27 Apr 2005 09:48:53 -0400
List-Id: <ietf-smtp.imc.org>

Sean,

This is just a swag (scientific wild ass guess).  The only thing that comes
to my mind on how this might possibly happen is

a) when sending a packet far greater than what the actual data demands,
and/or
b) you are not reading all the data from the socket correctly.

So you migh have inadvertingly have something like this:

    char szCmd[1024*8];
    strcpy(szCmd, "EHLO blah\r\n");
    send(socket, szCmd,sizeof(szCmd),0);

where you are sending the entire block, rather then the length:

    send(socket, szCmd,strlen(szCmd),0);

and you might not reading the entire socket, might be leaving behind a byte
or two which is enough to cause a reset which I can see in the tail end of
your network dump.

You did say your TCP is rusty. <g>

Anyway, it has been my experience that issues related to resets like this is
usually dye to incorrect reading/writing the socket.  This is especially
true in the ADSL market where we have a bandwidth mismatch (faster reading,
slowing writing) which pretty much mandates proper TCP half close operations
(per TCP/IP Illustrated Volume 1)

Swag!

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Sean Murray" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 25, 2005 8:16 AM
Subject: out of sequence smtp communication

>
> Hi
>
> I have a problem with smtp transaction.
> I often get a 503 error, well far more often than i would like.
>
> The destination mail server accuses mine of sending a MAIL FROM before
> it has received the EHLO/HELO command, duplicate EHLO/HELO or of out "out
of sequence smtp communication"
>
> I have attached an example packet sniff at the bottom. If someone wants
the
> full sniff I can send it off list, its about 22k for this example.
>
> The server is exim 4.32 (RHEL3) but this occurs using pmdf7(vms7.2) as
well and the remote mailservers
> are all types from exim,postfix,qmail,sendmail, mailmarshal, exchange and
some i have not heard
> of.
>
> A couple of odd things:
> 1. I get retransmissions in under 1 sec ( faulty misconfigured router ? ).
There are 2
> cisco routers between the mail server and the outside.
> 2. the retransmission of the 250 response appears in numerous place and
not only the 503 error
> however all the 503 errors do have a retransmission error of their 250.
> 3. This is all on top of tcp, while my tcp is abit rusty i thought tcp
guaranteed a connection and
> handled errors for things running on top of it, barring long timeouts of
course, yet i seem to loose commands for some reason.
> 4. It is not specific to a particular server and 10 seconds later
sometimes another mail will go through to the remote server,
> without the error.
>
> Any suggestions would be greatly appreciated.
>
> Thanks
> Sean
>

Date: Mon, 25 Apr 2005 14:16:02 +0200
From: Sean Murray <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: out of sequence smtp communication
Sender: [email-masked]

Hi

I have a problem with smtp transaction.
I often get a 503 error, well far more often than i would like.

The destination mail server accuses mine of sending a MAIL FROM before
it has received the EHLO/HELO command, duplicate EHLO/HELO or of out "out of sequence smtp communication"

I have attached an example packet sniff at the bottom. If someone wants the
full sniff I can send it off list, its about 22k for this example.

The server is exim 4.32 (RHEL3) but this occurs using pmdf7(vms7.2) as well and the remote mailservers
are all types from exim,postfix,qmail,sendmail, mailmarshal, exchange and some i have not heard
of.

A couple of odd things:
1. I get retransmissions in under 1 sec ( faulty misconfigured router ? ). There are 2
cisco routers between the mail server and the outside.
2. the retransmission of the 250 response appears in numerous place and not only the 503 error
however all the 503 errors do have a retransmission error of their 250.
3. This is all on top of tcp, while my tcp is abit rusty i thought tcp guaranteed a connection and
handled errors for things running on top of it, barring long timeouts of course, yet i seem to loose commands for some reason.
4. It is not specific to a particular server and 10 seconds later sometimes another mail will go through to the remote server,
without the error.

Any suggestions would be greatly appreciated.

Thanks
Sean

No.     Time        Source                Destination           Protocol Info
      99 6658.472911 196.21.124.19         196.31.215.251        TCP      51897 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460
SV=514476065 TSER=0 WS=0
     100 6658.802093 196.31.215.251        196.21.124.19         TCP      smtp > 51897 [SYN, ACK] Seq=0 Ack=1 Win=24616 Len=0
TSV=1960788066 TSER=514476065 WS=0 MSS=1460
     101 6658.802114 196.21.124.19         196.31.215.251        TCP      51897 > smtp [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=514476098
TSER=1960788066
     102 6662.990160 196.31.215.251        196.21.124.19         SMTP     Response: 220 mx01.eskom.imass.uunet.co.za ESMTP Thu, 21
Apr 2005 10:13:55 +0200 (GMT)
     103 6662.990198 196.21.124.19         196.31.215.251        TCP      51897 > smtp [ACK] Seq=1 Ack=79 Win=5840 Len=0
TSV=514476517 TSER=1960788486
     104 6662.990311 196.21.124.19         196.31.215.251        SMTP     Command: EHLO silence.tlabs.ac.za
     105 6663.979447 196.21.124.19         196.31.215.251        SMTP     [TCP Retransmission] Command: EHLO silence.tlabs.ac.za
     106 6664.274916 196.31.215.251        196.21.124.19         TCP      [TCP Previous segment lost] smtp > 51897 [ACK] Seq=93
Ack=27 Win=24616 Len=0 TSV=1960788616 TSER=514476517
     107 6667.190539 196.31.215.251        196.21.124.19         SMTP     [TCP Retransmission] Response: 250 2.0.0 OK
     108 6667.190648 196.21.124.19         196.31.215.251        SMTP     Command: MAIL FROM:<[email-masked]>
     109 6667.423687 196.31.215.251        196.21.124.19         SMTP     Response: 503 5.0.0 Polite people say HELO first
     110 6667.423822 196.21.124.19         196.31.215.251        SMTP     Command: QUIT
     111 6667.423850 196.21.124.19         196.31.215.251        TCP      51897 > smtp [FIN, ACK] Seq=65 Ack=133 Win=5840 Len=0
TSV=514476960 TSER=1960788939
     112 6667.659639 196.31.215.251        196.21.124.19         SMTP     Response: 221 2.0.0 mx01.eskom.imass.uunet.co.za closing
connection
     113 6667.659704 196.21.124.19         196.31.215.251        TCP      [TCP Keep-Alive] 51897 > smtp [RST] Seq=65 Ack=1936846515
Win=0 Len=0
     114 6667.676195 196.31.215.251        196.21.124.19         TCP      smtp > 51897 [FIN, ACK] Seq=192 Ack=65 Win=24616 Len=0
TSV=1960788962 TSER=514476960
     115 6667.676217 196.21.124.19         196.31.215.251        TCP      [TCP Keep-Alive] 51897 > smtp [RST] Seq=65 Ack=1936846515
Win=0 Len=0
     116 6667.676781 196.31.215.251        196.21.124.19         TCP      smtp > 51897 [ACK] Seq=193 Ack=66 Win=24616 Len=0
TSV=1960788962 TSER=514476960
     117 6667.676786 196.21.124.19         196.31.215.251        TCP      51897 > smtp [RST] Seq=66 Ack=1936846515 Win=0 Len=0

Date: Fri, 22 Apr 2005 06:10:25 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Folding White Space
Cc: David MacQuigg <[email-masked]>
Sender: [email-masked]

David MacQuigg writes:
> I'm working on a syntax for a DNS record to include a variety of 
> constructs, and I want to avoid inventing new syntax.  It looks like 
> the RFC2822 header syntax is almost what I need - versatile, compact, 
> and readable.  I have one question about folding white space (FWS).  
> Is it possible to split a line where a space is not allowed?

No. With one exception, and I'm dead certain you don't want to think 
about that one ;)

> Have I understood the existing syntax correctly?  Is there a better 
> way to do this?

You've understood the syntax correctly.

For your information and possible inspiration: There is one case in 
which the mail standards state that white space is to be discarded on 
reading, namely base64 decoding. A base64 encoder is free to insert 
white space wherever it wants, and a decoder must discard it wherever 
it sees any. (RFC 2045, page 25.)

Arnt

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Folding White Space
Date:  Fri, 22 Apr 2005 03:59:42 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

David MacQuigg wrote:

> It looks like the RFC2822 header syntax is almost what I need

Don't forget to get rid of obs-FWS.  For RfC (2)822 questions a
better list might be <ietf-822.imc.org>.

> Is it possible to split a line where a space is not allowed?

Depends on your syntax.  An FWS is always at least one WSP.  So
you can't have it where an SP is not allowed.  And an [FWS) is
nothing or an FWS, still probably not what you want, if an SP
has a meaning (e.g. WSP separated words).  If it has no meaning
(e.g. comma separated words) you could ignore all FWS.

See <http://article.gmane.org/gmane.ietf.ltru:1318> for LWSP
vs. FWS (warning, ABNF not checked by Bruce, don't believe it).

RfC 2017 3.1 has an example of inserting LWSP in an URL to fold
long URLs.  There it works because URLs cannot contain any WSP.

It's unrelated to SMTP, please propose another list, bye, Frank

Date: Thu, 21 Apr 2005 14:56:54 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Folding White Space
Sender: [email-masked]

I'm working on a syntax for a DNS record to include a variety of 
constructs, and I want to avoid inventing new syntax.  It looks like the 
RFC2822 header syntax is almost what I need - versatile, compact, and 
readable.  I have one question about folding white space (FWS).  Is it 
possible to split a line where a space is not allowed?  Here is an example:

XYZ:"ip4:207.171.160.32/28 ip4:207.171.164.32/28
   ip4:207.171.180.176/28 dk:o6lMIgulclWjZwP56LRqdg5ZX1
   5bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7   ~all"

If I understand section 3.2.3 of RFC2822, the unfolder leaves one SP in 
place of every FWS.  That works for the first line, but not the second, 
which had to be split in the middle of a long word.  I think I need to add 
a \ for this situation:

XYZ:"ip4:207.171.160.32/28 ip4:207.171.164.32/28
   ip4:207.171.180.176/28 dk:o6lMIgulclWjZwP56LRqdg5ZX1\
   5bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7   ~all"

Have I understood the existing syntax correctly?  Is there a better way to 
do this?

--
Dave

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Cc: "'IETF-SMTP'" <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: Anti-Spoofing Technology
Date: Wed, 20 Apr 2005 09:22:51 -0400
To: Dave Crocker <[email-masked]>
Sender: [email-masked]

> The problem with the rfc2821.mailfrom address is that it often is 
> highly
> UNrelated to the rfc2822.from.  There might be a logical relationship, 
> but
> nothing explicitly similar between the strings.

it's also the case that neither rfc2821.mailfrom or rfc2822.from 
necessarily have anything to do with the location to which the message 
was submitted.  nor is it necessarily the case that rfc2822.from 
identifies the person who submitted the message.

people often seem to want to cast this as an argument about which field 
should be authenticated.  overloading either rfc2821.mailfrom or 
rfc2822.from is harmful.  the right field to associate with the 
identity of the originator would be rfc2822.sender except that that 
field is so widely misused that it's useless in practice.

the right way to use rfc2821.mailfrom or rfc2822.from is not to ask "is 
this the person who sent the message?" or "did this message come from 
the right place?" but "did the originator have permission to use this 
address?"

Date: Sun, 17 Apr 2005 23:43:02 -0400
To: "John P Baker" <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: RE: Anti-Spoofing Technology
Cc: "'IETF-SMTP'" <[email-masked]>
Sender: [email-masked]

At 01:39 -0400 on 04/17/2005, John P Baker wrote about Re: 
Anti-Spoofing Technology:

>I had not yet looked at RFC 2822, but I have now pulled a copy and I am
>taking a look at it.
>
>What I am really thinking about is the mailbox designated by the "From:"
>header.
>
>I know that when a message is being transmitted between servers, it is
>really far too late to make any determination as to the validity of the
>"From:" header.
>
>However, it seems to me that when a message first enters the mail system
>(i.e., an ISP SMTP server receives a message from a client of that ISP),
>validation of the return address could be required.  Specifically, the
>"From" mailbox specified in the message header could, pursuant to an SMTP
>extension, be validated against a list of mailboxes allocated by the ISP to
>the client with whom the SMTP server is in session.

Does not fly when the ISP (ie: ISP1) blocks Outgoing Port 25 and thus 
forces all mail to go though their servers and you're trying to send 
mail using an ISP2 (who only runs their MSA [Email Injection] on 
Port25) From Address. The result in this case is that you can not 
route your ISP2 mail though an ISP2 SMTP Server and the ISP1 (ie: 
Current Connectivity Provider) Server rejects the From since it is an 
ISP2 Mailbox not an ISP1 one.

>
>There may already be something in the RFCs that I have yet to find.
>
>I am just beginning my research into this.
>
>John P Baker
>Software Engineer

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Inconsistency?
Date:  Mon, 18 Apr 2005 04:37:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 55
Sender: [email-masked]

John P Baker wrote:

> In RFC2821, a clear definition of the structure of a domain
> name is provided. In this definition, the length of a domain
> name may not exceed 255 characters, and consists of one (1)
> or more ?labels?

Two or more, because you have at least one dot, or you have a
domain literal without labels.

> Each label must begin with an alphabetic character

| sub-domain = Let-dig [Ldh-str]

Letter _or_ digit.

> In RFC2822, the definition is more obscure

RfC 2822 "allows" the absolute maximum before it definitely
breaks syntactically.  That's light years after you have lost
any plausible semantics.

OTOH you can see in RfC 2821 that narrow specifications of IPv6
domain literals also have their drawbacks, and the "general"
literal in RfC 2821 is much obscurer than the RfC 2822 syntax.
Ignoring many NO-WS-CTL in RfC 2822 for the moment, that was a
bad idea, as far as I'm concerned

> a much broader subset of ASCII

Oh yes, incl. the funny NO-WS-CTL.  It took me several months
of whining, ranting, moaning, and outright threatening to get
rid of it in USEFOR Message-IDs.

> ?@? appear to be valid within a domain name.

It depends, DNS allows it, but it's not okay in the FQDN of a
host name used for mail (A or MX).

> Does RFC2821 correctly reflect the syntactic requirements for
> domain names, or is it too incorrect

Domains without dot (a.k.a. TLDs) are possible, try it with a
`host ai`: ai = 209.88.68.34  The author said that the required
dot in 2821 is an intentional feature, IMHO that makes sense.

I'm not sure about the IPv6 domain literals in RfC 2821, the
tag IPv6: is rather odd.  The General-address-literal is also
odd, and IIRC it's incompatible with IPvfuture in RfC 3986.

The latter is a STD, therefore it's "better" (but unfortunately
it has absolutely nothing to do with SMTP ;-)

                             Bye, Frank

From: Dave Crocker <[email-masked]>
To: John P Baker <[email-masked]>, "'IETF-SMTP'" <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sun, 17 Apr 2005 18:21:59 -0700
Subject: RE: Anti-Spoofing Technology
Sender: [email-masked]

>
>  I had not yet looked at RFC 2822, but I have now pulled a copy and I am
>  taking a look at it.
>
>  What I am really thinking about is the mailbox designated by the "From:"
>  header.
>
>  I know that when a message is being transmitted between servers, it is
>  really far too late to make any determination as to the validity of the
>  "From:" header.

Not necessarily.  That is what the domainkeys and iim efforts are addressing, 
though not within smtp, per se.

>  However, it seems to me that when a message first enters the mail system
>  (i.e., an ISP SMTP server receives a message from a client of that ISP),
>  validation of the return address could be required.  

The problem with the rfc2821.mailfrom address is that it often is highly 
UNrelated to the rfc2822.from.  There might be a logical relationship, but 
nothing explicitly similar between the strings.  

>Specifically, the
>  "From" mailbox specified in the message header could, pursuant to an SMTP
>  extension, be validated against a list of mailboxes allocated by the ISP
>  to the client with whom the SMTP server is in session.

This might be useful for the submission segment, where the client is required 
to be related to the server, but not useful later in the MTA sequence.  As 
already noted in the thread, the SMTP Auth mechanism probably gives you waht 
you need, although not explicitly required to be the same as the From field.

More generally, the problem with tieing a user-level address to a 
transfer-level registration is that it creates an administrative nightmare, 
for many scenarios, because it requires administrative effort, every time the 
path changes.  Since email is a form of packet-switching, dynamic changes to 
paths are usually considered to be an essential feature.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Inconsistency? (was: Anti-Spoofing Technology)
Date: Sun, 17 Apr 2005 20:57:04 -0400
Cc: "John P Baker" <[email-masked]>
Sender: [email-masked]

On Sun April 17 2005 18:19, John P Baker wrote:

> In RFC2821, a clear definition of the structure of a domain name is
> provided.  In this definition, the length of a domain name may not exceed
> 255 characters, and consists of one (1) or more "labels", each separated
> from the other by a period (".").  The length of each label may not exceed
> 63 characters.

So far, so good.

> Each label must begin with an alphabetic character

No, "3com.com" is a valid domain name.

> (case-insensitive) and must terminate with an alphabetic character (again,
> case-insensitive) or with a decimal digit.  Characters internal to a label
> may be alphabetic (again, case-insensitive), decimal digit, or hyphen ("-").
> 
>  
> 
> In RFC2822, the definition is more obscure, with the domain name character
> set consisting of a much broader subset of ASCII.  Of particular concern is
> the fact that in this RFC, ASCII character which have special meaning such
> as "@" appear to be valid within a domain name.

2822 syntax was made general; actual content is determined by other
specifications.

> Does RFC2821 correctly reflect the syntactic requirements for domain names,
> or is it too incorrect, and there exists some other RFC which specifically
> addresses the issue?

2821 appears to be correct (note that labels may begin with a letter
or digit).  The definitive DNS RFCs are 1034 and 1035, as amended by
1123.

From: "John P Baker" <[email-masked]>
To: "'IETF-SMTP'" <[email-masked]>
Subject: Inconsistency? (was: Anti-Spoofing Technology)
Date: Sun, 17 Apr 2005 18:19:53 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C5437A.0E8C1620
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I have been reviewing some of the RFCs you have so kindly recommended.

I have found what appears to be a major inconsistency between RFC2821 and
RFC2822.

In RFC2821, a clear definition of the structure of a domain name is
provided.  In this definition, the length of a domain name may not exceed
255 characters, and consists of one (1) or more "labels", each separated
from the other by a period (".").  The length of each label may not exceed
63 characters.  Each label must begin with an alphabetic character
(case-insensitive) and must terminate with an alphabetic character (again,
case-insensitive) or with a decimal digit.  Characters internal to a label
may be alphabetic (again, case-insensitive), decimal digit, or hyphen ("-").

In RFC2822, the definition is more obscure, with the domain name character
set consisting of a much broader subset of ASCII.  Of particular concern is
the fact that in this RFC, ASCII character which have special meaning such
as "@" appear to be valid within a domain name.

Based upon the problems in RFC2822, I must conclude that the domain name
specification provided therein is incorrect.

Does RFC2821 correctly reflect the syntactic requirements for domain names,
or is it too incorrect, and there exists some other RFC which specifically
addresses the issue?

John P Baker

Software Engineer

------=_NextPart_000_0003_01C5437A.0E8C1620
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have been reviewing some of the RFCs you have so =
kindly
recommended.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have found what appears to be a major inconsistency
between RFC2821 and RFC2822.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In RFC2821, a clear definition of the structure of a =
domain
name is provided.&nbsp; In this definition, the length of a domain name =
may not
exceed 255 characters, and consists of one (1) or more =
&#8220;labels&#8221;,
each separated from the other by a period (&#8220;.&#8221;).&nbsp; The =
length
of each label may not exceed 63 characters.&nbsp; Each label must begin =
with an
alphabetic character (case-insensitive) and must terminate with an =
alphabetic
character (again, case-insensitive) or with a decimal digit.&nbsp; =
Characters
internal to a label may be alphabetic (again, case-insensitive), decimal =
digit,
or hyphen (&#8220;-&#8220;).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In RFC2822, the definition is more obscure, with the =
domain
name character set consisting of a much broader subset of ASCII.&nbsp; =
Of
particular concern is the fact that in this RFC, ASCII character which =
have
special meaning such as &#8220;@&#8221; appear to be valid within a =
domain
name.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Based upon the problems in RFC2822, I must conclude =
that the
domain name specification provided therein is =
incorrect.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Does RFC2821 correctly reflect the syntactic =
requirements
for domain names, or is it too incorrect, and there exists some other =
RFC which
specifically addresses the issue?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>John P Baker<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Software Engineer<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0003_01C5437A.0E8C1620--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Anti-Spoofing Technology
Date:  Sun, 17 Apr 2005 23:28:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

Dave Crocker wrote:
 
> Why is the rfc2821.mailfrom address of particular
{interest]
> rather than any of the other identification information,
> such as rfc2821.helo, rfc2822.from or rfc2822.sender?

Maybe because it gets any bounce, out-of-office, vacation, ...
"feedback", and the innocent owner will cause as much damage
as possible for the involved MTAs, their registrars, uplinks,
etc.  It's just the normal anti-spam-war, nothing personal.

                           Bye, Frank

Date: Sun, 17 Apr 2005 19:01:50 +1200
To: [email-masked]
From: Glenn Anderson <[email-masked]>
Subject: RE: Anti-Spoofing Technology
Sender: [email-masked]

At 1:39am -0400 17/4/2005, John P Baker wrote:
>However, it seems to me that when a message first enters the mail system
>(i.e., an ISP SMTP server receives a message from a client of that ISP),
>validation of the return address could be required.  Specifically, the
>"From" mailbox specified in the message header could, pursuant to an SMTP
>extension, be validated against a list of mailboxes allocated by the ISP to
>the client with whom the SMTP server is in session.
>
>There may already be something in the RFCs that I have yet to find.
>
>I am just beginning my research into this.

If you haven't yet, have a look at RFC 2554 (SMTP Service Extension 
for Authentication) and RFC 2476 (Message Submission).

An ISP or organization wanting to enforce a policy like you describe 
would force all clients to use SMTP AUTH, by doing something like 
blocking client IPs from using port 25 and requiring SMTP AUTH on a 
Message Submission port. Then credentials supplied via SMTP AUTH can 
then be used to decide what MAIL FROM, From, etc. addresses that 
client is allowed to use.

SMTP AUTH and the ability to change the port used for SMTP are 
already widely supported in clients, so it is basically a case of 
supporting those and implementing suitable policy at the server side.

Glenn.

From: "John P Baker" <[email-masked]>
To: "'IETF-SMTP'" <[email-masked]>
Subject: RE: Anti-Spoofing Technology
Date: Sun, 17 Apr 2005 01:39:39 -0400
Sender: [email-masked]

I had not yet looked at RFC 2822, but I have now pulled a copy and I am
taking a look at it.

What I am really thinking about is the mailbox designated by the "From:"
header.

I know that when a message is being transmitted between servers, it is
really far too late to make any determination as to the validity of the
"From:" header.

However, it seems to me that when a message first enters the mail system
(i.e., an ISP SMTP server receives a message from a client of that ISP),
validation of the return address could be required.  Specifically, the
"From" mailbox specified in the message header could, pursuant to an SMTP
extension, be validated against a list of mailboxes allocated by the ISP to
the client with whom the SMTP server is in session.

There may already be something in the RFCs that I have yet to find.

I am just beginning my research into this.

John P Baker
Software Engineer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hector Santos
Sent: Saturday, April 16, 2005 23:58
To: Dave Crocker; John P Baker; IETF-SMTP
Subject: Re: Anti-Spoofing Technology

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "John P Baker" <[email-masked]>; "IETF-SMTP"
<[email-masked]>
Sent: Saturday, April 16, 2005 11:03 PM
Subject: Re: Anti-Spoofing Technology

> >  Is there any extension to the SMTP protocol which, for a client
connection
> >  to an SMTP server, would require that all messages originating from
that
> >  client specify a return address known by the server to be associated
with
> >  that client?
>
> Why is the rfc2821.mailfrom address of particular address, rather than any
of
> the other identification information, such as rfc2821.helo, rfc2822.from
or
> rfc2822.sender?

I think he ask about SMTP and return address. not POST SMTP or 2822.  The
client domain machine is too far gone to be useable for anything today. So
CSV is out of the picture all together.

The return path is the closest then we have today to anything that can be
considered to be technically required to be "correct."   This is written
into the documents.

+80% of the time it is not and since most systems do not check, hence the
spoof problem.    From a SMTP standpoint,  the return path will have a great
technical value at the SMTP process to make sure , at a minimum, that it is
"verifiable."

Everything else (2822) is gravy.

I really hope this doesn't go into a useless debate about what is right or
wrong or SPF vs. CSV or some other machine.   He asked about SMTP and the
return address and today, there are some practical "anti-spoofing" SMTP
based protocols in place today that do attempt to address the return path
validity.  They exist in practice because they do offer some level of
protection.

----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats  (WcSAP Anti-Spam Stats)

From: "Hector Santos" <[email-masked]>
To: "Dave Crocker" <[email-masked]>, "John P Baker" <[email-masked]>, "IETF-SMTP" <[email-masked]>
Subject: Re: Anti-Spoofing Technology
Date: Sat, 16 Apr 2005 23:57:58 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "John P Baker" <[email-masked]>; "IETF-SMTP"
<[email-masked]>
Sent: Saturday, April 16, 2005 11:03 PM
Subject: Re: Anti-Spoofing Technology

> >  Is there any extension to the SMTP protocol which, for a client
connection
> >  to an SMTP server, would require that all messages originating from
that
> >  client specify a return address known by the server to be associated
with
> >  that client?
>
> Why is the rfc2821.mailfrom address of particular address, rather than any
of
> the other identification information, such as rfc2821.helo, rfc2822.from
or
> rfc2822.sender?

I think he ask about SMTP and return address. not POST SMTP or 2822.  The
client domain machine is too far gone to be useable for anything today. So
CSV is out of the picture all together.

The return path is the closest then we have today to anything that can be
considered to be technically required to be "correct."   This is written
into the documents.

+80% of the time it is not and since most systems do not check, hence the
spoof problem.    From a SMTP standpoint,  the return path will have a great
technical value at the SMTP process to make sure , at a minimum, that it is
"verifiable."

Everything else (2822) is gravy.

I really hope this doesn't go into a useless debate about what is right or
wrong or SPF vs. CSV or some other machine.   He asked about SMTP and the
return address and today, there are some practical "anti-spoofing" SMTP
based protocols in place today that do attempt to address the return path
validity.  They exist in practice because they do offer some level of
protection.

----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats  (WcSAP Anti-Spam Stats)

From: "Hector Santos" <[email-masked]>
To: "John P Baker" <[email-masked]>, "IETF-SMTP" <[email-masked]>
Subject: Re: Anti-Spoofing Technology
Date: Sat, 16 Apr 2005 23:43:25 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "John P Baker" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Sent: Saturday, April 16, 2005 9:51 PM
Subject: Anti-Spoofing Technology

> Is there any extension to the SMTP protocol which, for a client connection
> to an SMTP server, would require that all messages originating from that
> client specify a return address known by the server to be associated with
> that client?
>
> John P Baker
>
> Software Engineer

I hope this doesn't spark a useless debate.

First, there is no official SMTP "extension."  There are some proposals in
place.

Lets talk about is available today.  Currently, there are several methods in
place by a growing number of systems that "attempts" to validate the return
address.

1) SPF
2) Call Back Verification (CBV)
3) Challenge/Response (C/R) System

SPF

SPF attempts to authenticate the sender domain against a DNS policy defined
by the domain exposing the authorize client machine IP addressses allowed to
send mail on behalf of the domain.   see http://spf.pobox.com

This is done by a domain by adding a TXT DNS record defining the IP
addresses allowed to send mail for the domain.  Example:

    NSLOOKUP -query=txt aol.com

The SMTP server will do an SPF lookup for aol.com, and check the connection
IP address against the exposed SPF policy defined by aol.com.

CBV

This is a small background SMTP process to verify the return path at the
moment MAIL FROM is issued to call back and check the remote RCPT TO
response.
Example:

    HELO blah.com
    250 cool!
    MAIL FROM:  [email-masked]
    [  perform callback ]
    550 Sorry, [email-masked] not valid!

C/R:

C/R will accept and hold the message. It then sends a "challenge message" to
the return path. It will wait for a "Response" and use this to "authorize"
the held message to finally deliver it.

We use SPF and CBV on our SMTP product.

----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats  (WcSAP Anti-Spam Stats)

From: Dave Crocker <[email-masked]>
To: John P Baker <[email-masked]>, IETF-SMTP <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 16 Apr 2005 20:03:05 -0700
Subject: Re: Anti-Spoofing Technology
Sender: [email-masked]

>  Is there any extension to the SMTP protocol which, for a client connection
>  to an SMTP server, would require that all messages originating from that
>  client specify a return address known by the server to be associated with
>  that client?

Why is the rfc2821.mailfrom address of particular address, rather than any of 
the other identification information, such as rfc2821.helo, rfc2822.from or 
rfc2822.sender?

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: "John P Baker" <[email-masked]>
To: "IETF-SMTP" <[email-masked]>
Subject: Anti-Spoofing Technology
Date: Sat, 16 Apr 2005 21:51:03 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C542CE.63F31B60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Is there any extension to the SMTP protocol which, for a client connection
to an SMTP server, would require that all messages originating from that
client specify a return address known by the server to be associated with
that client?

John P Baker

Software Engineer

------=_NextPart_000_0035_01C542CE.63F31B60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is there any extension to the SMTP protocol which, =
for a
client connection to an SMTP server, would require that all messages
originating from that client specify a return address known by the =
server to be
associated with that client?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>John P Baker<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Software Engineer<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0035_01C542CE.63F31B60--

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Arun Sankar <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Sat, 16 Apr 2005 07:26:15 -0400
Cc: [email-masked]
Sender: [email-masked]

On Sat April 16 2005 05:49, Arun Sankar wrote:
> 
> Basically, we have aliases for our convenience, so that we do not end up 
> typing a huge number of mail-ids.

No, mailing lists and aliases exist for administrative reasons, not for
the convenience of senders.

> When we have to do [...] this has 
> to the other person.

More vague hand-waving; still no concrete example of a real problem. 

> Yes, this would have a few implimentational issues 

For crying out loud, get and use a spelling checker.

> Again the idea is not to force this feature on anybody but allow 
> it as an option to anybody who wants to use it. Encrypting each message 
> in every hop is similar.

Your scheme requires full implementation to "work".  Encryption is
not performed "in every hop", it is an end-to-end process -- see
RFCs 1847, 2480, 2634, and 3156.

Your scheme is incompatible with SMTP, per RFC 2821 section 3.10:

   An important mail facility is a mechanism for multi-destination
   delivery of a single message, by transforming (or "expanding" or
   "exploding") a pseudo-mailbox address into a list of destination
   mailbox addresses.  When a message is sent to such a pseudo-mailbox
   (sometimes called an "exploder"), copies are forwarded or
   redistributed to each mailbox in the expanded list.  Servers SHOULD
   simply utilize the addresses on the list; application of heuristics
   or other matching rules to eliminate some addresses, such as that of
   the originator, is strongly discouraged.

Note in particular that last sentence, which applies to the matching
rules in your proposed scheme.

Date: Sat, 16 Apr 2005 15:19:47 +0530
From: Arun Sankar <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Sender: [email-masked]

Basically, we have aliases for our convenience, so that we do not end up 
typing a huge number of mail-ids.

When we have to do a similar thing to a set of users wherein there is a 
superset alias available then the user is actually unable to use the 
superset alias and send it out to the subset. Now usage wise, every user 
can have a small example that could be absolutely of no significance to 
the other. So the idea of this draft needs to be seen more as an 
individualistic usage, though the importance of its usage is very 
personal and no other can do any sort of evaluation of the need this has 
to the other person.

Yes, this would have a few implimentational issues that the user would 
face. Again the idea is not to force this feature on anybody but allow 
it as an option to anybody who wants to use it. Encrypting each message 
in every hop is similar. Nobody is enforcing anybody to encrypt every 
message. If and only if the organization wants this feature then there 
has to be proper care taken in every mail hop that the feature is 
available. Thinking on similar lines, if an organization wants to use 
this feature then its the responsibility of the administrator to mandate 
appropriate MUA's and MTA's. This is very possible within an 
organization / a small company etc. So the basic idea is, so if somebody 
is very interested to use this feature, then there has to be a provision 
for it.  The problems that might have to be addressed have also been 
mentioned in the document for the areas wherein the adman has to take 
care to ensure he/she has done everything to have this feature.

Bruce Lilly wrote:

>On Thu April 14 2005 08:06, Arun Sankar wrote:
>  
>
>>Yes there are utilities to this draft.
>>
>>I have a few examples to explain the utilities,
>>
>>In a company, a team of say 20 there could be 2 contracters who should 
>>not be given the details that are to be passed to the other 18, some 
>>company confidential data. Everytime there is something confidentail, 
>>there needs to be an individualistic mail-ids need to be typed and sent 
>>across.
>>    
>>
>
>The appropriate solution to that "problem" is to have a separate list
>for confidential information distribution.  Any organization that has
>given a moment's thought to security/confidentiality considerations
>has already addressed that situation.  Under your scheme, real damage
>can occur if some sender forgets to exclude somebody who should not
>see confidential information, and/or if *any* component of message
>composition, transport, or delivery fails to adopt the sweeping changes
>proposed.
>
>  
>
>>It could be  
>>something as serious as this to something as simple yet important of 
>>sending a surprise birthday party mail to an alias of friends but just 
>>want to neglect only the important person who is celebrating his/her b'day.
>>    
>>
>
>An appropriate solution to this unusual (once-in-a-while) "problem" would
>be to simply send the message to the desired recipients rather than use
>a list expander.  SMTP explicitly provides for sending to multiple
>recipients (no extensions necessary, no changes to UAs, MTAs, etc.).
>Your scheme would require massive changes to the entire installed base
>of MUAs, MSAs, MTAs, and MDAs to be usable, and that's a huge overhead
>for such an issue that arises only occasionally.
>
>  
>
>>There could be innumerable situations, simple and complex wherein there 
>>needs to be a negation that is necesasry to help the user in making a 
>>few matters simplified.
>>    
>>
>
>More wishy-washy unclear hand-waving.  You have still not produced a
>single compelling example.
>
>Perhaps I wasn't sufficiently clear in my initial comments on the draft;
>the underlying problem with all of the defects of the draft appears to
>be that the author has not given due consideration to the issues as well
>as to the procedures and policies.  I apologize for being unclear.  I
>suggest that the author should carefully consider the documents to which
>he has been referred and the comments made here and elsewhere, and then
>carefully deliberate whether or not there is in fact a real "problem"
>in search of a solution and if so what backwards compatible solutions
>might be appropriate, or whether the proposal is a putative "solution"
>in search of a nonexistent problem. 
>
>
>  
>

-- 
Arun

Optimism: 
"Sir, we're surrounded!"
"Excellent. We can attack in any direction!"  --An Army Officer

From: "Hector Santos" <[email-masked]>
To: "Arun Sankar" <[email-masked]>
Cc: "ietf-smtp" <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Thu, 14 Apr 2005 11:40:11 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Arun Sankar" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "ietf-smtp" <[email-masked]>
Sent: Thursday, April 14, 2005 7:11 AM
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt

> Creating a different mailing lists is absolutely ok for small
> companies/simple mail server. Consider a huge corporate with a whole lot
> of aliases and a complex mail structure. Each time you want to eliminate
> a few mail-ids from a big list you have to send a request to the
> administrator to setup the new alias. This solution is more of a one
> time addition and solve the unable to negate problems.

I don't question the possible "benefits"  but you have too many  design
issues here.

Never mind the fact, I don't believe it has anything to do with SMTP (but
then again, I think some SMTP systems has built-in mailing list feature),
but inherently, its not a SMTP concept, atleast I don't think so.  So no
need for ESMTP features.

At the very least, this would be a MUA and LISTSERVER features.

1) The MUA would have to have a new "exclude" concept beside the basic TO:
CC and BC fields.

2) In general, it is the MUA smtp client that "massages" the headers to
cleanly separate the CC/BC from the sent  mail headers .   I can see the MUA
would not be able to include this exclude idea in this part of the process.

3) The LISTSERVER can now to its magic but you have now have a whole new
suite of new security/management and configuration design issues.

--- NCC Support Options ----

[_] Allow Mailing List support for NCC
    [X] Allow List Administrators to use NCC
    [_] Allow User to use NCC
         [X] Send Mail to Administrator for NCC authorization

    [ Button: Edit NCC Exemption List ]
      This is a list of users who YOU can not EXCLUDE (like the Admin)

X shows what I think should be the default settings for a new list.

What else?

Legal?

You probably need a disclaimer in your new subscription welcome message

          Note: Please not that some list information may be excluded
                   from distribution.

Why?

I guess the closest thing to this we have today is our online conferencing
system where we have Public/Private message attributes.  Sometimes you can
get into private conversions with a person or group in this conference and
what others will see is in increase in message counters but they don't see
the mail.    This is the god enough truth - I had people write to me "How
come I can't see the mail in the conferences?"

So as Murphy's law says it will happen with NCC when someone else in the
list who did get the a message and unbeknownst to him he blabs out to the
excluded person about a topic the excluded person knows nothing about.

        "Hey what do you think about that new business proposal?"

        "huh? What are you talking about?"

         "Oh, that .... oh, never mind..."

Please note, this can happen with a BC/CC concept as well.   This is why for
our MUA, it will add a line to the blind copy message text:

        *BLIND COPY! No one is aware you have received a copy of this
message.

To make sure the receiver is aware of the private nature of the message.

So do you need to to add a similar statement for NCC?

Maybe?  In this case, it might have to be a "HUSH" statement to all list
members got the message:

        *HUSH HUSH: The following people did not receive the message"

And so on and so on.

There is just too many design issues here and I personally, I think you can
handle it with separate mailing list that will inherently provide what you
are looking for without the "ergonomic" issues.

Anyway, thats my opinion on this proposal.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Thu, 14 Apr 2005 10:04:36 -0400
Cc: Arun Sankar <[email-masked]>
Sender: [email-masked]

On Thu April 14 2005 08:06, Arun Sankar wrote:
> 
> Yes there are utilities to this draft.
> 
> I have a few examples to explain the utilities,
> 
> In a company, a team of say 20 there could be 2 contracters who should 
> not be given the details that are to be passed to the other 18, some 
> company confidential data. Everytime there is something confidentail, 
> there needs to be an individualistic mail-ids need to be typed and sent 
> across.

The appropriate solution to that "problem" is to have a separate list
for confidential information distribution.  Any organization that has
given a moment's thought to security/confidentiality considerations
has already addressed that situation.  Under your scheme, real damage
can occur if some sender forgets to exclude somebody who should not
see confidential information, and/or if *any* component of message
composition, transport, or delivery fails to adopt the sweeping changes
proposed.

> It could be  
> something as serious as this to something as simple yet important of 
> sending a surprise birthday party mail to an alias of friends but just 
> want to neglect only the important person who is celebrating his/her b'day.

An appropriate solution to this unusual (once-in-a-while) "problem" would
be to simply send the message to the desired recipients rather than use
a list expander.  SMTP explicitly provides for sending to multiple
recipients (no extensions necessary, no changes to UAs, MTAs, etc.).
Your scheme would require massive changes to the entire installed base
of MUAs, MSAs, MTAs, and MDAs to be usable, and that's a huge overhead
for such an issue that arises only occasionally.

> There could be innumerable situations, simple and complex wherein there 
> needs to be a negation that is necesasry to help the user in making a 
> few matters simplified.

More wishy-washy unclear hand-waving.  You have still not produced a
single compelling example.

Perhaps I wasn't sufficiently clear in my initial comments on the draft;
the underlying problem with all of the defects of the draft appears to
be that the author has not given due consideration to the issues as well
as to the procedures and policies.  I apologize for being unclear.  I
suggest that the author should carefully consider the documents to which
he has been referred and the comments made here and elsewhere, and then
carefully deliberate whether or not there is in fact a real "problem"
in search of a solution and if so what backwards compatible solutions
might be appropriate, or whether the proposal is a putative "solution"
in search of a nonexistent problem. 

Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Thu, 14 Apr 2005 09:33:41 -0400
To: Arun Sankar <[email-masked]>
Sender: [email-masked]

> In a company, a team of say 20 there could be 2 contracters who should 
> not be given the details that are to be passed to the other 18, some 
> company confidential data.

that's not a valid application for this, as any MTA that doesn't 
support the extension will leak the confidential data.  if you really 
want to preserve confidential data, you don't trust it to the 
configuration of several different MTAs, even if they're all under your 
control.  it's much easier and safer to send 18 separate copies, and/or 
to encrypt the message so that it can only be read by the holders of 18 
public keys.

because of its inherently unreliable nature, ncc is really only useful 
in cases where not copying those recipients is a useful optimization 
but not required.  e.g. duplicate suppression from mailing lists.  but 
there are better ways to do duplicate suppression.

Date: Thu, 14 Apr 2005 14:24:06 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Cc: Arun Sankar <[email-masked]>
Sender: [email-masked]

Arun Sankar writes:
> In a company, a team of say 20 there could be 2 contracters who should 
> not be given the details that are to be passed to the other 18, some 
> company confidential data. Everytime there is something confidentail, 
> there needs to be an individualistic mail-ids need to be typed and 
> sent across. Here the team alias - id1 - id2 would do the trick.

I doubt you could get that example past the security chaps. If even one 
company employee replies with a current-day mail reader, confidential 
information is leaked.

Next, please.

> It could be something as serious as this to something as simple yet 
> important of sending a surprise birthday party mail to an alias of 
> friends but just want to neglect only the important person who is 
> celebrating his/her b'day.

Okay, let's count that as one.

For huge utility, you should have about five persuasive examples. 
Remember: If you don't have persuasive examples, your proposal quite 
simply will not be implemented.

Arnt

Date: Thu, 14 Apr 2005 17:36:52 +0530
From: Arun Sankar <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Sender: [email-masked]

Yes there are utilities to this draft.

I have a few examples to explain the utilities,

In a company, a team of say 20 there could be 2 contracters who should 
not be given the details that are to be passed to the other 18, some 
company confidential data. Everytime there is something confidentail, 
there needs to be an individualistic mail-ids need to be typed and sent 
across. Here the team alias - id1 - id2 would do the trick. It could be 
something as serious as this to something as simple yet important of 
sending a surprise birthday party mail to an alias of friends but just 
want to neglect only the important person who is celebrating his/her b'day.

There could be innumerable situations, simple and complex wherein there 
needs to be a negation that is necesasry to help the user in making a 
few matters simplified.

Hope I was clear,

--
Thanks
Arun

Arnt Gulbrandsen wrote:

>
> Arun Sankar writes:
>
>> Creating a different mailing lists is absolutely ok for small 
>> companies/simple mail server. Consider a huge corporate with a whole 
>> lot of aliases and a complex mail structure. Each time you want to 
>> eliminate a few mail-ids from a big list you have to send a request 
>> to the administrator to setup the new alias. This solution is more of 
>> a one time addition and solve the unable to negate problems.
>
>
> Arun,
>
> if you don't have any examples showing the huge utility you claim, 
> noone's going to implement the extension, so we might as well stop 
> talking about it right away.
>
> You should post good examples here, and also add them to the draft.
>
> Arnt
>
>

-- 
Arun

Optimism: 
"Sir, we're surrounded!"
"Excellent. We can attack in any direction!"  --An Army Officer

Date: Thu, 14 Apr 2005 13:43:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Cc: Arun Sankar <[email-masked]>
Sender: [email-masked]

Arun Sankar writes:
> Creating a different mailing lists is absolutely ok for small 
> companies/simple mail server. Consider a huge corporate with a whole 
> lot of aliases and a complex mail structure. Each time you want to 
> eliminate a few mail-ids from a big list you have to send a request 
> to the administrator to setup the new alias. This solution is more of 
> a one time addition and solve the unable to negate problems.

Arun,

if you don't have any examples showing the huge utility you claim, 
noone's going to implement the extension, so we might as well stop 
talking about it right away.

You should post good examples here, and also add them to the draft.

Arnt

Date: Thu, 14 Apr 2005 16:41:03 +0530
From: Arun Sankar <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: ietf-smtp <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Sender: [email-masked]

Creating a different mailing lists is absolutely ok for small 
companies/simple mail server. Consider a huge corporate with a whole lot 
of aliases and a complex mail structure. Each time you want to eliminate 
a few mail-ids from a big list you have to send a request to the 
administrator to setup the new alias. This solution is more of a one 
time addition and solve the unable to negate problems.

Hector Santos wrote:

>I find this option to be more of a listserver feature.  I can mention quite
>a few things, but just off hand how do you stop someone from using it if the
>list administrator did not want you to?   I mean, the listserver (mailing
>list expander) does not have to honor it but then you just exposed to the
>intended excluded user, information you didn't want him to see.  You are
>going to hurt his feelings. :-)
>
>I don't know about others systems but our SMTP server system is separate
>from the list server.  The only thing the list server provides to the SMTP
>server is the valid list of acceptable mailing list names.  Expansion takes
>place after it is received by SMTP.
>
>This requires an MUA changes and LISTSERVER changes.  I think the complexity
>overweight the benefits and you could do it today very simply by creating a
>separate mailing list.  No change to software anywhere.
>
>--
>Hector Santos, Santronics Software, Inc.
>http://www.santronics.com
>
>
>----- Original Message -----
>From: "Arun Sankar" <[email-masked]>
>To: "ietf-smtp" <[email-masked]>; "Keith Moore" <[email-masked]>
>Sent: Wednesday, April 13, 2005 8:16 AM
>Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
>
>
>  
>
>>This draft is in a state that most of the new features are. New in the
>>sense that as long as they are implemented in various forms (various
>>MTA's and MUA's) the usage of the new field would be very "limited". I
>>have mentioned this point in the Security field as well for more clarity
>>as well.
>>
>>The utility is huge on the long run. I agree it is a little of a problem
>>in the beginning, but this is the problem with any new additional
>>standard until there is sufficient implementation for it for it to be an
>>actual value add. Probably, if everybody within one company wants to
>>have it and are ready to make the changes and ready to use, it would be
>>a good start to the services growth.
>>
>>--
>>Best Regards
>>Arun
>>
>>Keith Moore wrote:
>>
>>    
>>
>>>[followups redirected to [email-masked] list]
>>>
>>>On Apr 8, 2005, at 5:25 AM, Arun Sankar wrote:
>>>
>>>      
>>>
>>>>It is definately backward compatiable as there is a Extended SMTP
>>>>header (NCC) that also needs to be in place for the NCC processing to
>>>>proceed.
>>>>        
>>>>
>>>no, it is not, in at least two ways:
>>>
>>>1. with existing MUAs and other processors that don't display or take
>>>the Ncc field into account, it creates a mistaken impression that the
>>>message was sent to recipients that the message was not actually sent to
>>>      
>>>
>>>2. because not all systems will support Ncc (either because they
>>>predated it, or because they think it's not a desirable feature)
>>>senders might send a message with the mistaken expectation that it
>>>will not be delivered to particular recipients.
>>>
>>>this extension seems of marginal value.  it can be used to attempt
>>>duplicate suppression, such as when a message arrives at a recipient's
>>>mailbox both directly and via a list - but it's better to just have
>>>duplicates suppressed at the recipient's message store.  the other use
>>>that comes to mind is that people will be tempted to use it as a way
>>>to implement "send to everyone on this mailing list except that
>>>troublemaker Joe".  while I sympathize with the desire to do that, it
>>>will work so unreliably in practice that it's better to not have the
>>>feature.
>>>
>>>
>>>      
>>>
>>--
>>Arun
>>
>>Optimism:
>>"Sir, we're surrounded!"
>>"Excellent. We can attack in any direction!"  --An Army Officer
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>  
>

-- 
Arun

Optimism: 
"Sir, we're surrounded!"
"Excellent. We can attack in any direction!"  --An Army Officer

From: "Hector Santos" <[email-masked]>
To: "Arun Sankar" <[email-masked]>, "ietf-smtp" <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Thu, 14 Apr 2005 04:42:52 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

I find this option to be more of a listserver feature.  I can mention quite
a few things, but just off hand how do you stop someone from using it if the
list administrator did not want you to?   I mean, the listserver (mailing
list expander) does not have to honor it but then you just exposed to the
intended excluded user, information you didn't want him to see.  You are
going to hurt his feelings. :-)

I don't know about others systems but our SMTP server system is separate
from the list server.  The only thing the list server provides to the SMTP
server is the valid list of acceptable mailing list names.  Expansion takes
place after it is received by SMTP.

This requires an MUA changes and LISTSERVER changes.  I think the complexity
overweight the benefits and you could do it today very simply by creating a
separate mailing list.  No change to software anywhere.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Arun Sankar" <[email-masked]>
To: "ietf-smtp" <[email-masked]>; "Keith Moore" <[email-masked]>
Sent: Wednesday, April 13, 2005 8:16 AM
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt

>
> This draft is in a state that most of the new features are. New in the
> sense that as long as they are implemented in various forms (various
> MTA's and MUA's) the usage of the new field would be very "limited". I
> have mentioned this point in the Security field as well for more clarity
> as well.
>
> The utility is huge on the long run. I agree it is a little of a problem
> in the beginning, but this is the problem with any new additional
> standard until there is sufficient implementation for it for it to be an
> actual value add. Probably, if everybody within one company wants to
> have it and are ready to make the changes and ready to use, it would be
> a good start to the services growth.
>
> --
> Best Regards
> Arun
>
> Keith Moore wrote:
>
> >
> > [followups redirected to [email-masked] list]
> >
> > On Apr 8, 2005, at 5:25 AM, Arun Sankar wrote:
> >
> >> It is definately backward compatiable as there is a Extended SMTP
> >> header (NCC) that also needs to be in place for the NCC processing to
> >> proceed.
> >
> >
> > no, it is not, in at least two ways:
> >
> > 1. with existing MUAs and other processors that don't display or take
> > the Ncc field into account, it creates a mistaken impression that the
> > message was sent to recipients that the message was not actually sent to
>
> >
> >
> > 2. because not all systems will support Ncc (either because they
> > predated it, or because they think it's not a desirable feature)
> > senders might send a message with the mistaken expectation that it
> > will not be delivered to particular recipients.
> >
> > this extension seems of marginal value.  it can be used to attempt
> > duplicate suppression, such as when a message arrives at a recipient's
> > mailbox both directly and via a list - but it's better to just have
> > duplicates suppressed at the recipient's message store.  the other use
> > that comes to mind is that people will be tempted to use it as a way
> > to implement "send to everyone on this mailing list except that
> > troublemaker Joe".  while I sympathize with the desire to do that, it
> > will work so unreliably in practice that it's better to not have the
> > feature.
> >
> >
>
> --
> Arun
>
> Optimism:
> "Sir, we're surrounded!"
> "Excellent. We can attack in any direction!"  --An Army Officer
>
>
>
>
>

Cc: ietf-smtp <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Wed, 13 Apr 2005 09:10:11 -0400
To: Arun Sankar <[email-masked]>
Sender: [email-masked]

> The utility is huge on the long run.

strongly disagree.  the utility is extremely marginal.  and there's too 
much potential for negative utility.

Date: Wed, 13 Apr 2005 14:47:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Cc: Arun Sankar <[email-masked]>, Keith Moore <[email-masked]>
Sender: [email-masked]

Arun Sankar writes:
> The utility is huge on the long run.

Could you give some examples?

> I agree it is a little of a problem in the beginning, but this is the 
> problem with any new additional standard until there is sufficient 
> implementation for it for it to be an actual value add.

If being an early adopter doesn't pay off, very few people bother to 
implement and use an SMTP extension. Look at BDAT for an example.

Arnt

Date: Wed, 13 Apr 2005 17:46:41 +0530
From: Arun Sankar <[email-masked]>
To: ietf-smtp <[email-masked]>, Keith Moore <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Sender: [email-masked]

This draft is in a state that most of the new features are. New in the 
sense that as long as they are implemented in various forms (various 
MTA's and MUA's) the usage of the new field would be very "limited". I 
have mentioned this point in the Security field as well for more clarity 
as well.

The utility is huge on the long run. I agree it is a little of a problem 
in the beginning, but this is the problem with any new additional 
standard until there is sufficient implementation for it for it to be an 
actual value add. Probably, if everybody within one company wants to 
have it and are ready to make the changes and ready to use, it would be 
a good start to the services growth.

--
Best Regards
Arun

Keith Moore wrote:

>
> [followups redirected to [email-masked] list]
>
> On Apr 8, 2005, at 5:25 AM, Arun Sankar wrote:
>
>> It is definately backward compatiable as there is a Extended SMTP 
>> header (NCC) that also needs to be in place for the NCC processing to 
>> proceed.
>
>
> no, it is not, in at least two ways:
>
> 1. with existing MUAs and other processors that don't display or take 
> the Ncc field into account, it creates a mistaken impression that the 
> message was sent to recipients that the message was not actually sent to 

>
>
> 2. because not all systems will support Ncc (either because they 
> predated it, or because they think it's not a desirable feature) 
> senders might send a message with the mistaken expectation that it 
> will not be delivered to particular recipients.
>
> this extension seems of marginal value.  it can be used to attempt 
> duplicate suppression, such as when a message arrives at a recipient's 
> mailbox both directly and via a list - but it's better to just have 
> duplicates suppressed at the recipient's message store.  the other use 
> that comes to mind is that people will be tempted to use it as a way 
> to implement "send to everyone on this mailing list except that 
> troublemaker Joe".  while I sympathize with the desire to do that, it 
> will work so unreliably in practice that it's better to not have the 
> feature.
>
>

-- 
Arun

Optimism: 
"Sir, we're surrounded!"
"Excellent. We can attack in any direction!"  --An Army Officer

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Dave Crocker <[email-masked]>
Subject: Re: reassembly
Date: Sun, 10 Apr 2005 15:04:57 -0400
Sender: [email-masked]

On Sat April 9 2005 15:34, Dave Crocker wrote:
> 
> >  Reassembly is architecturally a gateway function
> 
> 
> although it is a perfectly fine thing, to be able to do reassembly in a 
> gateway, there is nothing that requires it to be done there.

I'm having a hard time understanding what you're getting at, from an
architectural POV.

A gateway isn't a "there", it's a functional component with a specific
characteristic, viz. it modifies messages (unlike MTAs, MDA, MUAs).
Reassembly requires (substantial) modification.

> as noted already, it is also fine to do it at the recipient site.

Again a gateway is a functional component; "recipient site" isn't.
 
> in fact, there are a number of scenarios that require it, both for internet 
> mail and for IP.

Intellectual Property?

To: "[email-masked]" <[email-masked]>
From: [email-masked]
Subject: architecture draft v04 , Message retrieval agent
Date: Sun, 10 Apr 2005 13:06:27 +0100
Sender: [email-masked]

Hello,

Still no responce at all to my idea of putting an MRA agent between the two message stores.

MRA (Mail Retrieval Agent)

Is it so far fetched? 
Or is it because the draft equals mail handling system (MHS) with SMTP?
(POP3, IMAP, ODMR and other Pull mechanisms do not really count)

Here are two reasons to split the rMUA up in a MRA and rMUA:

Architectionaly the rMUA is between the user and the localMS and the MRA between the server ans the local message stores.

An other reason is that if you have an MRA you can describe POP3-ODMR-or SMTP(ETRN)-mailservers as consisting of
MRA-MDA-MS systems.

So following some new texts.

4.6 sMS server Message Store

The sMS is where SMTP does final delivery
it is a message store as mentioned in RFC2821 section 2.3.3.
This store SHOULD always be accessible (local) to the MDA.
(NOT to the rMUA)
It is the end of the SMTP store-and-forward transfer.

4.7  Message Retrieval Agent (MRA) and lMS
The MRA and the lMS are to overcome tht what is called "the lacking of the resource known as "connectivity". (copied from RFC  1939 section 1 introduction)  
where this resource is not lacking (webmail and other always connected systems) the MRA and the lMS are not needed.

The MRA works on request of the receiving User, or automaticly by the MUA.
The MRA links the computer to the sMS and collects the messages.
There is no need for a connection between the MRA and the rMS if the MRA is not retrieving messages

The MRA message retrieval agent retrieves the mail from the server Message Store and stores it on the local machine of the receiver-user. this can be done by download protocols like  (pop3) (ODMR) (SMTP-ETRN) or with synchronising protocols like (IMAP4)
 While downloading in general implies that the message in  the sMS is deleted. 
With synchronising the message is kept in the server message store.

4.8 local message store lMS

The lMS is the final store for the message. 
This message store resides in the local computer of the MUA. and is available to the user for manipulating, reading etc.

4.9 receiver Mail User Agent  rMUA

(text copied from 4.2)
The Recipient-side rMUA works on behalf of the end-user Recipient to process
received mail. This includes generating user-level return control messages,
display and disposition of the received message, and closing or expanding
the user communication loop, by initiating replies and forwarding new
messages.

figure 5 should be changed to
         .              +------+                       |       |
         .              |      +-----------------------+       |
         .              | MDA  |                               |
         .              |      |<--------------------+         |
         .              +-+--+-+                     |         |
         .                V     (local)              |         |
         .             +------+                 /+===+===+\    |
         .             | sMS  |                 || sieve ||    |
         .             +-+--+-+                 \+=======+/    |
         .               |  |  {pop, imap ,odmr)     ^         |
         .               |  V                        |         |
         .               | +------+                  |         |
         .               | | MRA  |                  |         |
         .               | +------+                  |         |
         .               |    V   (local)            |         |
         .               | +------+                  |         |
         .               | | uMS  |                  |         |
         .               | +--+---+                  |         |
         .               V    V    {local)           |         |
         .              +------+                     |         |
         .              |      +---------------------+         |
         ..............>| rMUA |                               |
                        |      +-------------------------------+
                        +------+

(notice how nice local links are only one V long.
Maybe it is even nicer it link local parts together  then it becomes:

         .             +------+                       |       |
         .             |      +-----------------------+       |
         .             | MDA  |                               |
         .             |      |<---------------------+        |
         .             +------+                 /+===+===+\   |
         .             | sMS  |                 || sieve ||   |
         .             +-+--+-+                 \+=======+/   |
         .               |  |  (pop, imap ,odmr)     ^        |
                         |  |  (ODMR SMTP-ETRN)      |        |
         .               |  V                        |        |
         .               | +------+                  |        |
         .               | | MRA  |                  |        |
         .               | +------+                  |        |
         .               V | lMS  |                  |        |
         .              +--+--+---+                  |        |
         .              |         +------------------+        |
         ..............>|   rMUA  |                           |
                        |         +---------------------------+
                        +---------+

references

POP3       [RFC1939]  
SMTP-ETRN  [RFC1985]
ODMR       [RFC2645]
IMAP       [RFC3501]

note:
In this description the MRA can both use 
Host to Client protocols (POP3 and IMAP) as
Host to Host protocols (ODMR and SMTP-ETRN)

I rather see this as a benifit than as a shortcomming, but like everything in here open to discussion.

Hope on some replies

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
CC: Tony Finch <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 9 Apr 2005 12:34:49 -0700
Subject: reassembly
Sender: [email-masked]

>  Reassembly is architecturally a gateway function

although it is a perfectly fine thing, to be able to do reassembly in a 
gateway, there is nothing that requires it to be done there.

as noted already, it is also fine to do it at the recipient site.

in fact, there are a number of scenarios that require it, both for internet 
mail and for IP.  The simple description of the basis for this is having no 
part of the final path be shared through a common infrastructure device.  
hence the first point of commonality on the receive side is the receiving 
host. 

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Date: Sat, 9 Apr 2005 15:12:35 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Sat April 9 2005 14:25, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:

> > A description of the mail system architecture is incomplete
> > unless it discusses the gateway vs. message fragment
> > reassembly issues documented in RFC 1344, ignorance of which
> > has led to security problems.
> 
> We all have our pet peeves, and yours is message/partial.

No, it's developers who ignore the architectural constraints, resulting
in breaches of security.

Message/partial per se is not a problem, although I suspect that
message fragmentation and reassembly could be defined in a way that
is more amenable to handling extension fields without having to make
backwards-incompatible changes to the deployed infrastructure.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "addressing" comments on draft-crocker-email-arch-04.txt
Date: Sat, 9 Apr 2005 15:08:26 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Sat April 9 2005 14:07, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > The term "mailbox" has two uses (RFCs 822, 2822):
> >    o As an abstract term for an entity that receives email.
> 
> Or submits it (the 3rd occurence of "mailbox" in STD 11 is
> the "Sender" defined as "actual sumitter", later defined
> to be the responsible "bounces-to" address.  Pun intended.)

If you mean part of the EBNF or the phrase "The Sender mailbox
specification", that refers to the grammar production.

> > The message header Return-Path field is derived from an SMTP
> > command argument and is subject to the same restrictions.
> 
> Unlike an angle-addr it can be empty, not exactly the same.

Correct, the restrictions include no display name, no named groups, etc.

> > the Sender mailbox and the SMTP return path (for delivery
> > notifications) may in general be unrelated.
> 
> That's in fact the main problem of this draft, in general they
> start as not only related but as identical.

Not necessarily.  I might have a cron process which is the Sender
(see RFC 822 section 4.4.2 and RFC 3834), whereas I might wish
delivery notifications to go to a person, since the cron process is
unlikely to be able to handle notifications.  Note also that while
the syntax in Sender field for the case of an automated process must
match the "mailbox" grammar production, there is no requirement that
mail can be received via that specification (see RFC 3834 sect. 4).

> "MAIL FROM" is an entity responsible for the SMTP transmission
> incl. errors, "Sender" is a human responsible for the mail or
> news transmission incl. errors.

We've discussed MAIL FROM and it's origins.  Sender need not
reference a human.

> > List expanders SHOULD set the reverse path (MAIL FROM) to
> > point to the list administrator, and SHOULD NOT leave MAIL
> > FROM unaltered.
> 
> Not necessarily the human list admin, it can be also a mail-bot
> handling error messages for the admin.

It should be a mailbox (in the abstract sense) that can receive
delivery notifications, expressed in the path (a.k.a. angle-addr)
syntax required for the MAIL FROM command argument.

> Another case where the 
> Sender and the MAIL FROM could be different (the responsible
> Sender is always a human).

"[C]ould be different", yes; "always a human", no.

> > MAIL FROM path (angle-addr) might have to be transformed into
> > something comparable on the "foreign" side of the gateway,
> > but SHOULD NOT be changed to point to a gateway operator
> > mailbox except as a last resort (otherwise delivery
> > notifications will never reach the correct mailbox).
> 
> NAK, that depends on the nature of the gateway.  If it's for a
> list or newsgroup or similar cases (e.g. Fido echo) it SHOULD
> point to the gateway operator, normal list etc. users are not
> responsible for or interested in the problems behind a gateway.

In the specific case of a news-to-mail gateway, there is no
path to transform, since news has no corresponding "envelope". So
the "last resort" case applies.  Conversely, if I send a message
to a recipient via an SMTP-to-X.400 gateway, I expect to be
notified of delivery (esp. delivery success), whereas the gateway
operator probably couldn't care less.  Perhaps there is a need to
differentiate the different types of gateways; I believe that I
identified about a half-dozen types in comments on an earlier
version of the architecture draft...

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Date:  Sat, 09 Apr 2005 20:47:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 17
Sender: [email-masked]

Tony Finch wrote:

> Therefore I think it's legitimate for a modern description of
> the architecture to omit source-routed paths on the grounds
> that they are ana anomalous historical relic.

IBTD.  The literal meaning of "Return-Path" is unclear without
a proper understanding of the origial concept, and the rather
unstructured description of paths in 2821 is far from enough to
get this idea.

And there are different aspects of this issue.  AFAIK Bruce is
always interested in "who changes what when why".  So if I send
my MAIL FROM:<dcrocker@fqdn> (an appointed by me "bounces-to"
manager), and you get it as Return-Path: <@host:dcrocker@fqdn>,
then the @host could be a legal effect, no forgery.  Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Date:  Sat, 09 Apr 2005 20:25:58 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Bruce Lilly wrote:

> o aliasing and list expansion can only take place where the
>   local-part of the (SMTP envelope) path is interpreted;
>   architecturally that is at an MDA

Of course, and that's the fundamental problem in 1123 and with
so called "forwarders".

> A description of the mail system architecture is incomplete
> unless it discusses the gateway vs. message fragment
> reassembly issues documented in RFC 1344, ignorance of which
> has led to security problems.

We all have our pet peeves, and yours is message/partial.  IMHO
such MIME issues are out of scope for an RfC about "mail-arch",
it's too special.
                            Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: "addressing" comments on draft-crocker-email-arch-04.txt
Date:  Sat, 09 Apr 2005 20:07:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 65
Sender: [email-masked]

Bruce Lilly wrote:

> The term "mailbox" has two uses (RFCs 822, 2822):
>    o As an abstract term for an entity that receives email.

Or submits it (the 3rd occurence of "mailbox" in STD 11 is
the "Sender" defined as "actual sumitter", later defined
to be the responsible "bounces-to" address.  Pun intended.)

> The message header Return-Path field is derived from an SMTP
> command argument and is subject to the same restrictions.

Unlike an angle-addr it can be empty, not exactly the same.

> In general, Author(s) and Sender are distinct.

+1 (many more +1 skipped)

> the Sender mailbox and the SMTP return path (for delivery
> notifications) may in general be unrelated.

That's in fact the main problem of this draft, in general they
start as not only related but as identical.  Later if messages
are redistributed discrepancies might sneak in.  And of course
if a mail reaches SMTP transport via another system like UUCP,
a news2mail gateway, or an article for a moderated newsgroup.

"MAIL FROM" is an entity responsible for the SMTP transmission
incl. errors, "Sender" is a human responsible for the mail or
news transmission incl. errors.

Ideally (STD 10) "MAIL FROM" points to the sending host plus
a complete route back to the point of the SMTP injection or
redistribution.  Obsoleted by another STD, but still the idea.

> also note that routes in paths might be modified.

Of course, otherwise "Return-Path" would be a misnomer.  That's
essentially the same problem as the MAIL FROM vs. Sender issue.

> List expanders SHOULD set the reverse path (MAIL FROM) to
> point to the list administrator, and SHOULD NOT leave MAIL
> FROM unaltered.

Not necessarily the human list admin, it can be also a mail-bot
handling error messages for the admin.  Another case where the
Sender and the MAIL FROM could be different (the responsible
Sender is always a human).  Otherwise ACK.

> MAIL FROM path (angle-addr) might have to be transformed into
> something comparable on the "foreign" side of the gateway,
> but SHOULD NOT be changed to point to a gateway operator
> mailbox except as a last resort (otherwise delivery
> notifications will never reach the correct mailbox).

NAK, that depends on the nature of the gateway.  If it's for a
list or newsgroup or similar cases (e.g. Fido echo) it SHOULD
point to the gateway operator, normal list etc. users are not
responsible for or interested in the problems behind a gateway.

> I would recommend another draft revision review here before
> wider IETF review.

+1 (I completely lost track, several dozens of +1), bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Date: Sat, 9 Apr 2005 13:10:27 -0400
Sender: [email-masked]

On Sat April 9 2005 12:26, Bruce Lilly wrote:

> >    -  The ID field MAY contain an "@" as suggested in RFC 822, but this
> >       is not required.
> 
> That repeats the problem compounded by 1123 by copying the same text.

And (I forgot to note) by failing to address the mandatory angle brackets
required by RFC 822 and forbidden by RFC 821.  As well as other special
characters which typically appear in either the local-part or domain of
a msg-id, notably '.' required in domain names and '[' and ']' in domain
literals.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Date: Sat, 9 Apr 2005 13:06:39 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Sat April 9 2005 12:08, Tony Finch wrote:
> 
> On Fri, 8 Apr 2005, Bruce Lilly wrote:
> > On Fri April 8 2005 11:48, Tony Finch wrote:
> > > On Tue, 5 Apr 2005, Bruce Lilly wrote:
> > > >
> > > > Routes in paths are now somewhat uncommon, but are not obsolete and
> > > > should not be ignored in a description of the mail system architecture.
> > >
> > > They've been strongly deprecated since RFC 1123 (dated 1989) which states
> > > that this is for architectural reasons. Therefore I think it's legitimate
> > > for a modern description of the architecture to omit source-routed paths
> > > on the grounds that they are an anomalous historical relic.
> >
> > See section 5.2.6 of 1123.
> 
> Yes, that's what I'm referring to. It says that explicit source routes
> SHOULD NOT be used by SMTP clients and that they are unnecessary and will
> be abolished.

It also says:

         A receiver-SMTP MUST accept the explicit source route syntax in
         the envelope, but it MAY implement the relay function as
         defined in section 3.6 of RFC-821.  If it does not implement
         the relay function, it SHOULD attempt to deliver the message
         directly to the host to the right of the right-most "@" sign.

N.B. "MUST" indicates a mandatory requirement (yes, I'm being redundant,
for emphasis), whereas "SHOULD NOT" is a mere recommendation.

If, in accordance with that requirement, a route is received, the
envelope route WILL [*] be modified by a relay whether or not it ignores
the route.  That is why I noted that the draft statement that the
envelope is not modified is incorrect.

> > Also, routes are still sometimes necessary to work around temporary DNS
> > and related problems (I've had to use them several times in the past few
> > years).
> 
>               Some have suggested that source routing may be needed
>               occasionally for manually routing mail around failures;
>               however, the reality and importance of this need is
>               controversial.  The use of explicit SMTP mail relaying for
>               this purpose is discouraged, and in fact it may not be
>               successful, as many host systems do not support it.
> 
> I expect that is even more true 15 years later.

As I mentioned, I have found the facility both necessary and successful
recently.

* where "WILL" means that the specified operation takes place in all
RFC-conforming implementations, without exception.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Date: Sat, 9 Apr 2005 12:57:29 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Sat April 9 2005 11:54, Tony Finch wrote:

> That all addresses reassembly when gatewaying. I'm talking about a
> situation without filtering and using only Internet protocols, where the
> only place that needs to perform reassembly is the MUA, and there is
> nothing performing the architectural role of gateway.

Reassembly is architecturally a gateway function (and technically takes
place at the Application layer for reasons given earlier), regardless
of what sort of product implements that function.

If a hypothetical product implements that gateway functionality in an
rMUA with a local message store, then it is not possible for filtering
to take place other than in that rMUA or another rMUA that accesses the
same MS (local MS formats are typically non-interoperable and
product-specific), unless of course that product never "sees" fragment
messages because an "upstream" gateway performs reassembly first. In
particular, if there is a remote MS that stores only individual
fragments, no (reliable, arbitrary) filtering based on content can take
place, and no rMUA that does not also incorporate the gateway
functionality of reassembly will be able to present any complete
messages which were received at that MS as fragments (unless an RMUA
with said gateway functionality uploads the reassembled complete
message to the remote MS prior to such filtering).

Now a note that that architecture wasn't strictly necessary prior to
MIME might be appropriate.  As might be the case for a note that absent
filtering, searching, and sorting considerations it might not matter --
however, the fact is that almost all rMUAs have searching and sorting
functionality, most have filtering, and most moderately sized
organizations employ some sort of content filtering due to spam and
malware concerns.

The architectural principle is important given various schemes for
"remote filtering" whereby some party is contracted to perform content-
based filtering for a recipient.  That works only if
1. all MX records result in all messages passing through that filter
and
2. the "filter" properly implements message reassembly (so as to
   preclude the problems which occur when that doesn't happen, as noted
   in the CERT vulnerability notice previously cited).
I.e. the conditions stated apply (all messages pass through a gateway
(for reassembly) where that gateway catches all messages routed via MX
hosts, and where the reassembly performed by that gateway takes place
prior to content-based filtering).

> > Sieve continues to evolve; there is a recent proposal for
> > "vacation"-like functionality; would you really like to receive a dozen
> > notifications because a message was fragmented in transit?
> 
> Sieve requires that a correspondent does not receive multiple copies of
> the vacation notification within a reasonable period of a time (e.g. a
> week) which deals with that problem.

Not if the fragments are processed by separate implementations which
have no way of communication information about separately-sent
notifications.  Which might very well happen if messages are not
funneled through a single choke point as is required for reassembly.
I.e. in order for the (Sieve or similar) "vacation" restriction on
notifications, and for filtering for security issues, and for filtering
(by Sieve or other mechanisms) on arbitrary message header fields, it
is a necessary condition that fragmented message reassembly take place
before such filtering.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Date: Sat, 9 Apr 2005 12:26:48 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Sat April 9 2005 11:42, Tony Finch wrote:

> i.e. a queue ID not the value of the Message-ID field.

Yes, a different ID with the same syntax (msg-id).  I.e. an example
of multiple identifiers for the same message, which was the point made
w.r.t. the architecture draft.

> RFC 821 has a much more detailed specification of the syntax, which
> disagrees with the syntax in RFC 822 about what appears after id in a
> Received: field. The only example of a Received: field in either document
> is
>          Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
>                    id M12345 for [email-masked] ; 22 OCT 81 09:23:59 PDT

Yes, there is an incompatibility between 821 and 822.  RFC 1123
compounded the problem by stating that the explicit syntax clearly and
precisely specified by RFC 822 EBNF was merely "suggested".

> RFCs 2821 and 2822 fix the syntax confusion by making 2822 specify just
> the name/value item metasyntax and leaving the details of ordering and
> which names and values are valid to 2821. The latter says:
> 
>    -  The ID field MAY contain an "@" as suggested in RFC 822, but this
>       is not required.

That repeats the problem compounded by 1123 by copying the same text.

>    ID = "ID" FWS String / msg-id CFWS

No, it's not (yet) fixed; there are still 2821/2822 discrepancies. The
2821 and 2822 editors are aware of the discrepancies, but no errata
have been issued for the problems, and I have reason to believe that
that won't happen any time soon.  There is currently no cognizant IETF
WG working on advancing either document to Draft status, and while a
bit more than a year ago there was some talk about advancing both
documents, not much seems to have happened with either one.

The specific issue w.r.t. 2821/2822 Received field "id" component
discrepancies is that 2821 "String" corresponds to 2822 "atom" or
"quoted-string", whereas 2822 does not permit a "quoted-string" for
any Received field component "item-value".

The problem with both 821/822 and 2821/2822 discrepancies is that the
SMTP document specifies message content (in the form of a Received
field component) which does not conform to the specified Message Format
syntax.

Date: Sat, 9 Apr 2005 17:08:39 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Fri, 8 Apr 2005, Bruce Lilly wrote:
> On Fri April 8 2005 11:48, Tony Finch wrote:
> > On Tue, 5 Apr 2005, Bruce Lilly wrote:
> > >
> > > Routes in paths are now somewhat uncommon, but are not obsolete and
> > > should not be ignored in a description of the mail system architecture.
> >
> > They've been strongly deprecated since RFC 1123 (dated 1989) which states
> > that this is for architectural reasons. Therefore I think it's legitimate
> > for a modern description of the architecture to omit source-routed paths
> > on the grounds that they are an anomalous historical relic.
>
> See section 5.2.6 of 1123.

Yes, that's what I'm referring to. It says that explicit source routes
SHOULD NOT be used by SMTP clients and that they are unnecessary and will
be abolished.

> Also, routes are still sometimes necessary to work around temporary DNS
> and related problems (I've had to use them several times in the past few
> years).

              Some have suggested that source routing may be needed
              occasionally for manually routing mail around failures;
              however, the reality and importance of this need is
              controversial.  The use of explicit SMTP mail relaying for
              this purpose is discouraged, and in fact it may not be
              successful, as many host systems do not support it.

I expect that is even more true 15 years later.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Sat, 9 Apr 2005 16:54:23 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Fri, 8 Apr 2005, Bruce Lilly wrote:
> On Fri April 8 2005 11:30, Tony Finch wrote:
> > On Tue, 5 Apr 2005, Bruce Lilly wrote:
> > >    o Architecturally, all messages must pass through at least one
> > >      Gateway (which may be implemented in conjunction with an MTA, MDA,
> > >      or even MUA).  [this is necessary to accomplish MIME
> > >      message/partial reassembly as detailed in RFC 1344].
> >
> > I don't think it's helpful to describe the MIME functionality in an
> > MUA as something to do with gatewaying because the MUA is not a
> > transport-level entity. It's only necessary for gateways to implement
> > MIME in order for them to properly handle the mismatch between
> > Internet email and some other email system, so the MIME handling is a
> > secondary feature rather than something fundamental to gateways.
>
> Please see RFC 1344 sections "Fragmenting and Reassembling Large
> Messages" and "Using or Removing External-Body Pointers" and then
> look  at http://www.kb.cert.org/vuls/id/836088.  My initial response
> upon hearing of that supposed "new" "exploit" are recorded at
> http://lists.sans.org/pipermail/list/2002-September/054081.html
> and I stand by those remarks.

That all addresses reassembly when gatewaying. I'm talking about a
situation without filtering and using only Internet protocols, where the
only place that needs to perform reassembly is the MUA, and there is
nothing performing the architectural role of gateway.

> Sieve continues to evolve; there is a recent proposal for
> "vacation"-like functionality; would you really like to receive a dozen
> notifications because a message was fragmented in transit?

Sieve requires that a correspondent does not receive multiple copies of
the vacation notification within a reasonable period of a time (e.g. a
week) which deals with that problem.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Sat, 9 Apr 2005 16:42:37 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Fri, 8 Apr 2005, Bruce Lilly wrote:
> On Fri April 8 2005 10:47, Tony Finch wrote:
> > On Fri, 1 Apr 2005, Bruce Lilly wrote:
> > >
> > > Section 3.3 discusses message identifiers, but fails to note that the
> > > Message-ID message header field is optional.  It also alludes to
> > > multiple identifiers, but does not note that Received fields may
> > > incorporate a msg-id in the optional "id" component.
> >
> > Though the id item in Received: fields is not necessarily a Message-ID;
> > it may also be an MTA's queue ID.
>
> If we're talking about architecture as designed, the Received field as
> defined in RFC 822 absolutely requires a msg-id, complete with
> local-part, '@', domain, and angle brackets.

RFC 822 says:

        Some transport services queue mail; the internal message iden-
        tifier that is assigned to the message may be noted, using the
        "id" parameter.

i.e. a queue ID not the value of the Message-ID field.

RFC 821 has a much more detailed specification of the syntax, which
disagrees with the syntax in RFC 822 about what appears after id in a
Received: field. The only example of a Received: field in either document
is
         Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
                   id M12345 for [email-masked] ; 22 OCT 81 09:23:59 PDT

RFCs 2821 and 2822 fix the syntax confusion by making 2822 specify just
the name/value item metasyntax and leaving the details of ordering and
which names and values are valid to 2821. The latter says:

   -  The ID field MAY contain an "@" as suggested in RFC 822, but this
      is not required.

   ID = "ID" FWS String / msg-id CFWS

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Fri, 8 Apr 2005 20:14:54 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Sender: [email-masked]

> 
> On Tue, 5 Apr 2005, Bruce Lilly wrote:
> >
> > Routes in paths (forward and reverse) generally are modified in transit.
> > Routes in paths are now somewhat uncommon, but are not obsolete and
> > should not be ignored in a description of the mail system architecture.
> 
> They've been strongly deprecated since RFC 1123 (dated 1989) which states
> that this is for architectural reasons. Therefore I think it's legitimate
> for a modern description of the architecture to omit source-routed paths
> on the grounds that they are ana anomalous historical relic.

Strongly agree.   Actually I'd go a lot farther and say it's legitimate
for a description of the architecture to omit almost everything at that
level of detail, historic or not.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Date: Fri, 8 Apr 2005 19:04:06 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Fri April 8 2005 11:30, Tony Finch wrote:
> 
> On Tue, 5 Apr 2005, Bruce Lilly wrote:
> >    o Architecturally, all messages must pass through at least one
> >      Gateway (which may be implemented in conjunction with an MTA, MDA,
> >      or even MUA).  [this is necessary to accomplish MIME
> >      message/partial reassembly as detailed in RFC 1344].  As reassembly
> >      (RFC 2046) is a rather complex process that involves message
> >      modification, the operative unit is unquestionably a gateway [it
> >      might be useful to differentiate different types of gateways,
> >      though that is not done in the simple diagram above or in the
> >      draft]
> 
> I was under the impression that message/partial reassembly is often
> implemented by the rMUA rather than some transport-level entity between
> the sender and recipient. There's no requirement for a gateway. I don't
> think it's helpful to describe the MIME functionality in an MUA as
> something to do with gatewaying because the MUA is not a transport-level
> entity. It's only necessary for gateways to implement MIME in order for
> them to properly handle the mismatch between Internet email and some other
> email system, so the MIME handling is a secondary feature rather than
> something fundamental to gateways.

Please see RFC 1344 sections "Fragmenting and Reassembling Large
Messages" and "Using or Removing External-Body Pointers" and then
look  at http://www.kb.cert.org/vuls/id/836088.  My initial response
upon hearing of that supposed "new" "exploit" are recorded at
http://lists.sans.org/pipermail/list/2002-September/054081.html
and I stand by those remarks.

> >    o filtering operates at the Application layer rather than transport
> >      layer
> 
> Why? I presume you mean filtering implemented by Sieve or some equivalent,
> which can occur in the MDA or MUA. The boundary between transport and
> application becomes rather blurry here, so I'm interested in where you
> draw the line and why.

Filtering in general, not just Sieve implementations.  I say Application
layer because there is no transport involved in filtering per se (though
of course such filtering might be associated with an MTA, MDA, or
gateway). Also because filtering involves examination of message content
(unlike relays (architecturally; aberrant implementations are a separate
matter)).

> Note also that this kind of filtering can be used 
> to implement aliasing and mailing list expansion, which you later say is
> a transport level function implemented in the MDA (and I agree with this).

Aliasing and mailing list expansion operate by replacing the SMTP
envelope recipient path with one or more new paths.  Aside from
newfangled bumper stickers (List- fields), message content remains
unchanged and need not be examined.  It is not uncommon to have
(anti-spam, anti-virus, anti-HTML) filters associated with list
expansion, but the separate functions can be distinguished
architecturally.

> >    o filtering must occur after message reassembly (Again see RFC 1344
> >      and see also http://www.kb.cert.org/vuls/id/836088 to see what can
> >      happen when that architectural principle is ignored)
> 
> Not necessarily; this is only required if the filtering is performing some
> content-sensitive security function, which is not usually the case for
> sieve-style filters. I think it's important to distinguish between sieve
> filtering (on behalf of users) and security filtering performed within the
> MTS.

Note that Sieve can filter based on arbitrary message header fields;
also note that message/partial fragmentation and reassembly are such
that (unfragmented) message header fields may be buried within the
first fragment body until reassembled.  Therefore Sieve cannot operate
on those fields until the message is reassembled.  Sieve continues to
evolve; there is a recent proposal for "vacation"-like functionality;
would you really like to receive a dozen notifications because a
message was fragmented in transit?

I don't object to subdividing categories where it makes sense to do do,
but of course that's more effort, should probably be reviewed again,
and might not be beneficial.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Date: Fri, 8 Apr 2005 18:11:49 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Fri April 8 2005 11:48, Tony Finch wrote:
> 
> On Tue, 5 Apr 2005, Bruce Lilly wrote:
> >
> > Routes in paths (forward and reverse) generally are modified in transit.
> > Routes in paths are now somewhat uncommon, but are not obsolete and
> > should not be ignored in a description of the mail system architecture.
> 
> They've been strongly deprecated since RFC 1123 (dated 1989) which states
> that this is for architectural reasons. Therefore I think it's legitimate
> for a modern description of the architecture to omit source-routed paths
> on the grounds that they are ana anomalous historical relic.

See section 5.2.6 of 1123.  Also, routes are still sometimes necessary
to work around temporary DNS and related problems (I've had to use them
several times in the past few years).

Date: Fri, 08 Apr 2005 12:48:21 -0700
From: "Carl S. Gutekunst" <[email-masked]>
Organization: Alameth Systems Consulting Services
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Sender: [email-masked]

>>[Tony:] Though the id item in Received: fields is not necessarily a Message-ID; it may also be an MTA's queue ID.
>>    
>>
>[Bruce:] If we're talking about architecture as designed, the Received field as defined in RFC 822 absolutely requires a msg-id, complete with local-part, '@', domain, and angle brackets.
>
The syntax element in the Message-ID field and in the Received field is 
defined as a msg-id, but the msg-id in the Received field and the msg-id 
in the Message-ID field aren't the same value.

<csg>

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Date: Fri, 8 Apr 2005 15:26:07 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Fri April 8 2005 10:47, Tony Finch wrote:
> 
> On Fri, 1 Apr 2005, Bruce Lilly wrote:
> >
> > Section 3.3 discusses message identifiers, but fails to note that the
> > Message-ID message header field is optional.  It also alludes to
> > multiple identifiers, but does not note that Received fields may
> > incorporate a msg-id in the optional "id" component.
> 
> Though the id item in Received: fields is not necessarily a Message-ID;
> it may also be an MTA's queue ID.

If we're talking about architecture as designed, the Received field as
defined in RFC 822 absolutely requires a msg-id, complete with
local-part, '@', domain, and angle brackets.

If you're talking about (broken) implementations, that's another
matter.

Date: Fri, 8 Apr 2005 13:28:41 -0400
From: Keith Moore <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Sender: [email-masked]

> I was under the impression that message/partial reassembly is often
> implemented by the rMUA rather than some transport-level entity between
> the sender and recipient.

I would make an even stronger statement, to the effect that it is generally
inappropriate for a transport-level entity to perform such reassembly.
There are probably valid exceptions, but the norm should be that all
messages, including those with message/partial content, are delivered 
to the recipient's message store.

Keith

Date: Fri, 8 Apr 2005 16:48:28 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Tue, 5 Apr 2005, Bruce Lilly wrote:
>
> Routes in paths (forward and reverse) generally are modified in transit.
> Routes in paths are now somewhat uncommon, but are not obsolete and
> should not be ignored in a description of the mail system architecture.

They've been strongly deprecated since RFC 1123 (dated 1989) which states
that this is for architectural reasons. Therefore I think it's legitimate
for a modern description of the architecture to omit source-routed paths
on the grounds that they are ana anomalous historical relic.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Fri, 8 Apr 2005 16:30:51 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Tue, 5 Apr 2005, Bruce Lilly wrote:

Bruce's comments have been very carefully thought through, and I mostly
agree with what he says.

>    o Architecturally, all messages must pass through at least one
>      Gateway (which may be implemented in conjunction with an MTA, MDA,
>      or even MUA).  [this is necessary to accomplish MIME
>      message/partial reassembly as detailed in RFC 1344].  As reassembly
>      (RFC 2046) is a rather complex process that involves message
>      modification, the operative unit is unquestionably a gateway [it
>      might be useful to differentiate different types of gateways,
>      though that is not done in the simple diagram above or in the
>      draft]

I was under the impression that message/partial reassembly is often
implemented by the rMUA rather than some transport-level entity between
the sender and recipient. There's no requirement for a gateway. I don't
think it's helpful to describe the MIME functionality in an MUA as
something to do with gatewaying because the MUA is not a transport-level
entity. It's only necessary for gateways to implement MIME in order for
them to properly handle the mismatch between Internet email and some other
email system, so the MIME handling is a secondary feature rather than
something fundamental to gateways.

>    o filtering operates at the Application layer rather than transport
>      layer

Why? I presume you mean filtering implemented by Sieve or some equivalent,
which can occur in the MDA or MUA. The boundary between transport and
application becomes rather blurry here, so I'm interested in where you
draw the line and why. Note also that this kind of filtering can be used
to implement aliasing and mailing list expansion, which you later say is
a transport level function implemented in the MDA (and I agree with this).

>    o filtering must occur after message reassembly (Again see RFC 1344
>      and see also http://www.kb.cert.org/vuls/id/836088 to see what can
>      happen when that architectural principle is ignored)

Not necessarily; this is only required if the filtering is performing some
content-sensitive security function, which is not usually the case for
sieve-style filters. I think it's important to distinguish between sieve
filtering (on behalf of users) and security filtering performed within the
MTS.

>    o aliasing and list expansion (RFCs 822, 2822)

Don't forget 1123 :-)

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Date: Fri, 8 Apr 2005 17:27:36 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Cc: Arun Sankar <[email-masked]>, Keith Moore <[email-masked]>
Sender: [email-masked]

Two more problems.

1. I hate the UI implications. Suddenly there's an address field which 
means that the specified address may or may not have received this 
message. Creating a high-quality user interface to represent that well 
isn't easy.

Composition is hard too, since a good composer would need SMTP EXPN support.

2. I can't see how to specify ncc in such a way that it works both with 
case-sensitive localparts and case-insensitive ones.

This draft seems to have more problems than value...

Arnt

Date: Fri, 8 Apr 2005 15:47:52 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Fri, 1 Apr 2005, Bruce Lilly wrote:
>
> Section 3.3 discusses message identifiers, but fails to note that the
> Message-ID message header field is optional.  It also alludes to
> multiple identifiers, but does not note that Received fields may
> incorporate a msg-id in the optional "id" component.

Though the id item in Received: fields is not necessarily a Message-ID;
it may also be an MTA's queue ID.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

Cc: ietf-smtp <[email-masked]>
Reply-To: ietf-smtp <[email-masked]>, Keith Moore <[email-masked]>
From: Keith Moore <[email-masked]>
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Fri, 8 Apr 2005 09:16:44 -0400
To: Arun Sankar <[email-masked]>
Sender: [email-masked]

[followups redirected to [email-masked] list]

On Apr 8, 2005, at 5:25 AM, Arun Sankar wrote:

> It is definately backward compatiable as there is a Extended SMTP 
> header (NCC) that also needs to be in place for the NCC processing to 
> proceed.

no, it is not, in at least two ways:

1. with existing MUAs and other processors that don't display or take 
the Ncc field into account, it creates a mistaken impression that the 
message was sent to recipients that the message was not actually sent 
to

2. because not all systems will support Ncc (either because they 
predated it, or because they think it's not a desirable feature) 
senders might send a message with the mistaken expectation that it will 
not be delivered to particular recipients.

this extension seems of marginal value.  it can be used to attempt 
duplicate suppression, such as when a message arrives at a recipient's 
mailbox both directly and via a list - but it's better to just have 
duplicates suppressed at the recipient's message store.  the other use 
that comes to mind is that people will be tempted to use it as a way to 
implement "send to everyone on this mailing list except that 
troublemaker Joe".  while I sympathize with the desire to do that, it 
will work so unreliably in practice that it's better to not have the 
feature.

Date: Fri, 08 Apr 2005 14:55:45 +0530
From: Arun Sankar <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Sender: [email-masked]

Hi Keith,

It is definately backward compatiable as there is a Extended SMTP header 
(NCC) that also needs to be in place for the NCC processing to proceed.

Keith Moore wrote:

>>On Tue April 5 2005 15:30, [email-masked] wrote:
>>    
>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>	Title		: Ncc in Mail Header
>>>	Author(s)	: A. Sankar
>>>	Filename	: draft-arun-ncc-smtp-02.txt
>>>	Pages		: 4
>>>	Date		: 2005-4-5
>>>	
>>>This draft presents a mechanism to simplify one of the cumbersome 
>>>aspects of mailing, when one needs to send mails only to a subset of 
>>>mail-ids from an alias [ALIAS] . The basic intention is only to minimize 
>>>the complication and difficulty of a mail user when a mail needs to be 
>>>sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
>>>from the alias [ALIAS] list.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt
>>>      
>>>
>>As the draft lacks any indication of where discussion should take
>>place, I'm sending these comments to the author and the IETF discussion
>>list, with informational copies to the ietf-822 and ietf-smtp lists.
>>    
>>
>
>All of your comments miss the most important points - namely that this
>proposal breaks layering and it isn't backward compatible with the 
>installed base.    For those reasons alone there's no way that this
>proposal should be seriously considered.
>
>Keith
>
>
>  
>

-- 
Arun

Optimism: 
"Sir, we're surrounded!"
"Excellent. We can attack in any direction!"  --An Army Officer

Date: Thu, 7 Apr 2005 13:06:27 -0400
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Sender: [email-masked]

> On Tue April 5 2005 15:30, [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > 
> > 
> > 	Title		: Ncc in Mail Header
> > 	Author(s)	: A. Sankar
> > 	Filename	: draft-arun-ncc-smtp-02.txt
> > 	Pages		: 4
> > 	Date		: 2005-4-5
> > 	
> > This draft presents a mechanism to simplify one of the cumbersome 
> > aspects of mailing, when one needs to send mails only to a subset of 
> > mail-ids from an alias [ALIAS] . The basic intention is only to minimize 
> > the complication and difficulty of a mail user when a mail needs to be 
> > sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
> > from the alias [ALIAS] list.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt
> 
> As the draft lacks any indication of where discussion should take
> place, I'm sending these comments to the author and the IETF discussion
> list, with informational copies to the ietf-822 and ietf-smtp lists.

All of your comments miss the most important points - namely that this
proposal breaks layering and it isn't backward compatible with the 
installed base.    For those reasons alone there's no way that this
proposal should be seriously considered.

Keith

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date: Thu, 7 Apr 2005 12:52:49 -0400
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Tue April 5 2005 15:30, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Ncc in Mail Header
> 	Author(s)	: A. Sankar
> 	Filename	: draft-arun-ncc-smtp-02.txt
> 	Pages		: 4
> 	Date		: 2005-4-5
> 	
> This draft presents a mechanism to simplify one of the cumbersome 
> aspects of mailing, when one needs to send mails only to a subset of 
> mail-ids from an alias [ALIAS] . The basic intention is only to minimize 
> the complication and difficulty of a mail user when a mail needs to be 
> sent to n - m mail IDs i.e. send it to a group Id of n and exclude m
> from the alias [ALIAS] list.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-arun-ncc-smtp-02.txt

As the draft lacks any indication of where discussion should take
place, I'm sending these comments to the author and the IETF discussion
list, with informational copies to the ietf-822 and ietf-smtp lists.

General comments:

The "draft" fails to conform to requirements as specified in
http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html.  Among the problems
detected by "idnits" are:

  * The document seems to lack an IANA Considerations section.
  * The document seems to lack separate sections for Informative/Normative References.
    Checking conformance with RFC 3978/3979 boilerplate...
    the boilerplate looks good.
    (But only for now: the document uses RFC 3667 boilerplate instead of RFC 3978 boilerplate, and after 6 May 2005, submission of drafts with RFC 3667
    boilerplate will not be accepted.)
[...]
  * There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72.
  * There is 1 instance of lines with control characters in the document.
[...]
  - The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 59 lines
  - It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages

A spelling check would have proved beneficial; among spelling errors
detected are:

Implimentations
Updations
extention
implimented
recpect

The draft uses unconventional terminology, e.g. "a mail" rather than
"a message".

The draft conflates mailing lists and aliases, which are distinct [RFC
2821 sect. 3.10].

As far as I can tell, the draft topic seems related to a proposal
discussed some time ago on the ietf-822 mailing list:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12244
http://www.imc.org/ietf-822/mail-archive/msg04346.html
The author should probably review the content of that discussion.

The draft lacks ABNF, header field registration template (RFC 3864,
a.k.a. BCP 90), detailed discussion of what appears to be a proposal
for an ESMTP extension keyword, and (as noted by idnits) a mandatory
IANA Considerations section.  The author is referred to the following
for a treatise on the sort of items that should be addressed for the
message header field portion of his draft; the SMTP extension needs to
be given some thought also:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12673

Section 6 of the draft makes improper use of RFC 2119 terms:

    The Ncc option MAY not be implemented in all Mail Servers.
    This SHOULD not affect the servers that have implemented Ncc.

It is curious that the draft references RFC 2821 (the Standards Track
successor to RFC 821), but RFC 822 rather than 2822.

The most serious problems with the draft proposal result from confusing
message delivery with message content.  Message content -- including the
message header and particularly the Originator fields {RFC 2822 sect.
3.6.2] -- is not supposed to be modified except by gateways [RFC 2821
sect. 2.3.8]; even examination of message content is discouraged [RFC
2821 section 3.3] and modification is not permitted by relays.  The
draft seeks to require relays to modify message content in violation of
long-standing architectural principles.  The draft also implies
comparison of arbitrary mailboxes by hosts other then those which are
administrative for the mailbox domain; e.g. a mail relay at example.edu
is unable to determine whether or not [email-masked] is equivalent to
[email-masked] -- local parts may only be interpreted at hosts which
are authoritative for the domain.  The draft would also require relays
to alter the SMTP envelope (RCPT TO) based on message header field
content.  The draft suggests that message Originator fields [RFC 2822
sect. 3.6.2] should be modified by relays -- this is known as
"forgery" and is generally considered bad practice.

There is another work in progress that the draft author should be
acquainted with:
https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=11811

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Date: Tue, 5 Apr 2005 14:01:29 -0400
Sender: [email-masked]

On Tue April 5 2005 13:05, Dave Crocker wrote:

> >  My point is that (contrary to the draft implication) the MSs do not
> >  connect to each other, an rMUA connects to both MSs simultaneously and it
> >  is the rMUA that effects the synchronization.  
> 
> the discussion is about information relationship, not about connections.

The draft text "A remote MS and a local MS synchronize all or parts of
their contents, while connected.  The user may make changes while
disconnected, and the two stores are re-synchronized upon reconnection"
mentions connections several times, and implies that the MSs connect to
each other.  Of course you and I know better, but perhaps the situation
could be clarified for the benefit of readers who are not quite so
familiar with how things actually work.

From: Dave Crocker <[email-masked]>
To: <[email-masked]>, <[email-masked]>, Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 5 Apr 2005 13:05:50 -0400
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Sender: [email-masked]

> >  the problem with terminology, here, is matching existing practise, in
> >  particular finding a term that people will be comfortable with.  as
> >  nearly as i can tell, 'bounce' is a common term, in spite of the fact
> >  that it also applies to intermediate and successful delivery notices.
>
>  But "bounce" doesn't mean "delay" or "success"; it indicates failure only,

yeah.  established human practise can produce some interesting anomolies.

>  Incidentally, the draft doesn't discuss message tracking at all (RFCs 3885
>  through 3888).

right.  i could not think of anything about it that was 'architectural'.

>  My point is that (contrary to the draft implication) the MSs do not
>  connect to each other, an rMUA connects to both MSs simultaneously and it
>  is the rMUA that effects the synchronization.  

the discussion is about information relationship, not about connections.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Dave Crocker <[email-masked]>
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Date: Tue, 5 Apr 2005 11:55:31 -0400
Sender: [email-masked]

On Tue April 5 2005 10:13, Dave Crocker wrote:

> No, the first standardized architecture was the IFIP WG 6.5 effort, later, 
> that fed the X.400 work.  There was no public, standard "architecture" work 
> prior to that.

OK, if there is some document that can be referenced, a suitable
reference in the draft would help.

> Saying "core aspects" leaves all sorts of room for "other", and hardly 
> constitutes an implication that the changes you cite have not occurred.

IMO, one of the core aspects was the end-to-end Architectural nature
(as in Internet Architecture, hence the reference to RFC 1958) of the
service in the decade prior to insertion of transport markings into
that content starting with RFC 788.

One possible use of an architecture document may be in development of a
next-generation mail system.  It is in that case important to consider
not only how things are now, but also how they were and how the changes
have affected the mail system, for better and for worse.

Other possible uses include further extensions, and in that case also
it is important to differentiate those things which have turned out in
retrospect to have caused difficulties, so as to not compound the
problems by repeating past mistakes.

> the problem with terminology, here, is matching existing practise, in 
> particular finding a term that people will be comfortable with.  as nearly as 
> i can tell, 'bounce' is a common term, in spite of the fact that it also 
> applies to intermediate and successful delivery notices.

But "bounce" doesn't mean "delay" or "success"; it indicates failure
only, and that's the problem.  Specifically for delivery status
notifications, "delivery status notification" or "DSN" is a suitable
standardized term (which can be a noun when used alone to refer to a
DSN message -- though adding "message" removes ambiguity -- or it can
be a modifier for some noun, e.g. "path").  Alternatively, "delivery
status" alone could be used as a modifier, in the way that the noun
"notification" can be modified by "delivery status", message
disposition", and "message tracking status" to indicate distinct types
of notifications.

Incidentally, the draft doesn't discuss message tracking at all (RFCs
3885 through 3888).

> >  Section 2.2.3 states "A Relay may add information to the envelope, such as
> >  with trace information.  However it does not modify existing envelope
> >  information or the message content semantics".  Routes in paths (forward
> >  and reverse) generally are modified in transit. Routes in paths are now
> >  somewhat uncommon, but are not obsolete and should not be ignored in a
> >  description of the mail system architecture.
> 
> what specific changes are you saying are legal for an mta to do?  

If an MTA at host example.net receives a message with the forward path
<@example.net:[email-masked]> and a reverse path
<@example.org:[email-masked]>, both in the SMTP envelope, those may be
modified to <[email-masked]> and
<@example.net,@example.org:[email-masked]> respectively. 

> please cite the rfc2821 text that authorizes it.

Section 3.3:

   The <forward-path> can contain more than just a mailbox.
   Historically, the <forward-path> can be a source routing list of
   hosts and the destination mailbox, however, contemporary SMTP clients
   SHOULD NOT utilize source routes (see appendix C).  Servers MUST be
   prepared to encounter a list of source routes in the forward path,
   but SHOULD ignore the routes or MAY decline to support the relaying
   they imply.  Similarly, servers MAY decline to accept mail that is
   destined for other hosts or systems.

Note that the MUST is a requirement; SHOULD/SHOULD NOT are (mere)
recommendations.  Per that section, the reverse path in the example
above MAY be modified to simply <[email-masked]>.  See also section
5.2.6 of STD 3 (a.k.a. RFC 1123).

> yesthe rMUA take the actions that effect synchronization between the MSs.
> 
> however it is synchronization between the MSs that is of interest.

My point is that (contrary to the draft implication) the MSs do not
connect to each other, an rMUA connects to both MSs simultaneously and
it is the rMUA that effects the synchronization.  The operational
relationship is between the rMUA and each MS, not between two MSs. In
the description of Disconnected operation, "connected" and
"reconnected" should each be followed by "to a common rMUA" (connecting
two independent rMUAs, one to a local MS and the other to a remote MS
won't result in synchronization).

> >  Section 5.5 should explicitly caution against mangling of Originator
> >  fields (e.g. see draft-malamud-subject-line-04.txt).
> 
> You might have noticed that that section is rather short.  There are all sorts 
> of things one might put into such a section, but I most clearly was not 
> intending to make the section be any kind of thorough.

I have noticed that the other section 5 subsections have detailed
indications of which envelope/header fields may and may not be modified
and that such considerations are missing from section 5.5 only.

From: Dave Crocker <[email-masked]>
To: Bruce Lilly <[email-masked]>, <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Tue, 5 Apr 2005 10:13:39 -0400
Subject: Re: Miscellaneous comments on draft-crocker-email-arch-04.txt
Sender: [email-masked]

>  The Abstract and Introduction refer to "the first standardized
>  architecture for email".  That would be FTP (MAIL and MLFL commands). I
>  believe that the quoted phrase above should be replaced by "RFC 821".

No, the first standardized architecture was the IFIP WG 6.5 effort, later, 
that fed the X.400 work.  There was no public, standard "architecture" work 
prior to that.

Prior to that there was email *service* in a number of places -- and even 
significant *private* architecture work -- but nothing that could be called a 
"standardized architecture".

The UA-MTA model was derived from assessing 4 extant services, which had been 
independently developed, and detecting strong similarities among their 
high-level architectures.

For reference, there was no "standard" for arpanet mail content until RFC733, 
in 1977.  That was the word "standard" in the title of the document AND 
getting formal Arpa approval to use it.  (It happens that this was the first 
RFC to declare itself a formal standard, and it caused quite a firestorm.)

Please note:  "All RFCs are not standards".

>  The introduction also states "Core aspects of the service, such as address
>  and message style, have remained remarkably constant."  In fact there have
>  been significant changes, ... It is incorrect to imply
>  that these changes haven't happened; 

Saying "core aspects" leaves all sorts of room for "other", and hardly 
constitutes an implication that the changes you cite have not occurred.

>at minimum these changes should be
>  acknowledged,

The text is non-normative and is not intended to provide a history of email 
development.  That would be a delightful bit of text to read, no doubt, but it 
is not a goal of this document.

>  Section 1.3 and subsequent sections use the term "bounce", which implies
>  non-delivery whereas the term is used to cover cases that include positive
>  delivery notifications as well as informational notices about delayed
>  transmission. 

the problem with terminology, here, is matching existing practise, in 
particular finding a term that people will be comfortable with.  as nearly as 
i can tell, 'bounce' is a common term, in spite of the fact that it also 
applies to intermediate and successful delivery notices.

>  Figure 2 implies that a recipient can only respond to an originator if the
>  message passed through a mediator.

mumble.  grrr. yeah.

i had hoped to avoid having each recipient have a line going back, and i did 
worry about anyone drawing the implication you cite, but what the heck.  

i'll make the change.

>
>  Section 2.2.3 states "A Relay may add information to the envelope, such as
>  with trace information.  However it does not modify existing envelope
>  information or the message content semantics".  Routes in paths (forward
>  and reverse) generally are modified in transit. Routes in paths are now
>  somewhat uncommon, but are not obsolete and should not be ignored in a
>  description of the mail system architecture.

what specific changes are you saying are legal for an mta to do?  

please cite the rfc2821 text that authorizes it.

>  Section 4.6 refers to "relationship among two MSs".  The relationship is
>  between an MS and an rMUA (simply "MUA" in the draft as written).
>  Synchronization between "local" and "remote" MSs occurs when they are
>  connected to a common rMUA.

yesthe rMUA take the actions that effect synchronization between the MSs.

however it is synchronization between the MSs that is of interest.

>  Section 5.5 should explicitly caution against mangling of Originator
>  fields (e.g. see draft-malamud-subject-line-04.txt).

You might have noticed that that section is rather short.  There are all sorts 
of things one might put into such a section, but I most clearly was not 
intending to make the section be any kind of thorough.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Dave Crocker <[email-masked]>
Subject: Miscellaneous comments on draft-crocker-email-arch-04.txt
Date: Tue, 5 Apr 2005 08:29:17 -0400
Sender: [email-masked]

The Abstract and Introduction refer to "the first standardized
architecture for email".  That would be FTP (MAIL and MLFL commands).
I believe that the quoted phrase above should be replaced by "RFC 821".

The introduction also states "Core aspects of the service, such as
address and message style, have remained remarkably constant."  In fact
there have been significant changes, not all beneficial.  Initially
messages were completely unstructured; RFC 561 added structure by
separating message content into header and body.  Both header and body
were end-to-end (see RFC 1958) user-to-user communication until RFC 788
started insertion of transport markings into the message content.
Subsequent extensions (e.g. RFC 2919) have added more "bumper
stickers".  It is incorrect to imply that these changes haven't
happened; at minimum these changes should be acknowledged, ideally
mention would be made of the fact that mixing transport markings with
end-to-end content has caused (and continues to cause) problems (e.g.
it hampers straightforward digital signing of content, it has led to
improper modification of some Originator fields (e.g. Reply-To) by some
implementations, has led to incorrect use of mailboxes in the From
field for non-delivery (esp. "vacation"-like) notifications).

Section 1.3 and subsequent sections use the term "bounce", which
implies non-delivery whereas the term is used to cover cases that
include positive delivery notifications as well as informational
notices about delayed transmission.  The latter in particular are
often misinterpreted as non-delivery notifications, in spite of the
fact that many such delay notices contain explicit text IN SCREAMING
ALL CAPS that there is no need to resend.  The architecture document
should not contribute to the confusion by conflating the three
different types of notifications as "bounces". 

Figure 2 implies that a recipient can only respond to an originator if
the message passed through a mediator.

Section 2.2.3 states "A Relay may add information to the envelope, such
as with trace information.  However it does not modify existing
envelope information or the message content semantics".  Routes in
paths (forward and reverse) generally are modified in transit. Routes
in paths are now somewhat uncommon, but are not obsolete and should not
be ignored in a description of the mail system architecture.

Section 2.3, describing ISPs, states "It is not their job to perform
email functions, but to provide an environment in which those functions
can be performed".  Reality is that many (most?) ISPs provide an
environment in which mail transport functions cannot be performed
without using ISP-supplied mail services (terms of service that prevent
users from running SMTP servers or blocking outbound port 25, etc.).

Section 4.6 refers to "relationship among two MSs".  The relationship
is between an MS and an rMUA (simply "MUA" in the draft as written).
Synchronization between "local" and "remote" MSs occurs when they are
connected to a common rMUA.

Section 5.5 should explicitly caution against mangling of Originator
fields (e.g. see draft-malamud-subject-line-04.txt).

References may be amended by errata (
http://www.rfc-editor.org/cgi-bin/errata.pl
); that certainly applies to RFC 2821 and should be mentioned
prominently (many developers are apparently unaware of RFC errata).
There are also errors in some referenced RFCs (ibid.) which aren't
corrected by errata, but that's another matter.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Dave Crocker <[email-masked]>
Subject: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Date: Tue, 5 Apr 2005 07:38:27 -0400
Cc: ietf-smtp <[email-masked]>
Sender: [email-masked]

The email architecture draft uses the terms "User", "Mediator",
"Gateway", "Author", and "Originator" in ways which are quite confusing.

   o Section 2 lists Actors: user/MHS/AU

   o Section 2.1 subdivides User Actors as Originator/Recipient/Mediator
     (but doesn't mention resenders and respondents)

   o Section 2.1.1 equates Originator and Author (but as previously
     noted, fails to distinguish Author and Sender)

   o Section 2.1.3 says that list expansion software is a Mediator (i.e.
     a User)

   o Figure 3 (appropriately) shows Gateways as part of the MHS

   o Section 2.2.3 reclassifies (Administrative) Actors as "User
     Mediators"/"MHS Relays"/"Packet Switches" (confusing human users
     with list expansion software and classifying low-level Data
     Link/Physical layer hardware as Actors)

   o Section 2.2.4 says that Gateways are hybrids of Users (but not
     listed in other section 2 descriptions of users) and Relays

   o Section 4 is headed "Services" but discusses messages, agents, and
     stores.

   o Section 4.2 says Mediators (previously classified as Users) are
     MUAs (so in effect there is no distinction among a human user, a
     software MUA, and mailing list expansion software).

   o Section 5 reverses that and again classifies a Mediator as a User.

   o Section 5.1 says that aliasing is readdressing (which is also what
     list expansion is, as noted in RFCs 822/2822)

   o Section 5.1 also equates aliasing with MDAs (probably justifiable,
     but then the same applies to list expansion, which has previously
     (separately) been classified as MUA and as User)

   o Section 5.3 says that a mailing list is an Actor and is an
     elaboration of a redirector or resender (sect. 5.2)

   o Section 5.4 says that a Gateway (classified as part User by sect.
     2.2.4) is a type of relay or MTA.

Taken together, those sections say

   o list expander = mediator = MUA = user

   o list expander = actor ~ redirector = resender

   o aliasing = readdressing = redirecting = MDA

which further implies that an MUA and an MDA are very similar.

The draft also creates confusion between separate layers, conflating
human users (which are strictly not part of layering models) with
application layer UAs, while artifically separating list expansion
(really Transport-level redirection) from aliasing (also Transport-level
redirection).

There appears to be no mention of topological considerations, and
gateway architectural functionality appears to be shown as optional
(Figure 3) or missing (Figures 4, 5).

Consider the following simplified diagram for further discussion (view
with a monospaced font):

 +----------------------------------------+ (Mediate/Respond/Resend)
 v (Respond)     /(Mediate/Resend)        ^
user (Author)-->User (Sender)            User (Recipient)
   ____________/\                         ^
  /  /  ______/  \                        |    _______________
oMUA/  /   /      \            [Filter]~~rMUA
 |-(--+---+--------+--+        /^\    \   ^     Application
 |/   |   |           |       / | \    \  |    _______________
 v    v   v        _  v      /  v  \    \ v
MSA--MTA--Gateway-(_)-Gateway--MTA--MDA--[MS]  Transport (MHS)
  \__/|  /|    \____/\      \______/ |
   \__)__|_)_________/ \             |
      |____|____________+<-----------+ (Alias/list expansion)
 ^   [   Possible MX hosts  ]                (a.k.a. "mail exploder")
 |   [Possible recipient domain Administrative Unit]
  \[Sender Administrative Unit]

I believe the following statements to be accurate:

   o message author(s) and sender are architecturally distinct (RFCs
     822, 2822) but the sender may (by coincidence) be an author.

   o a message sender initiates message transport either by using an
     Application layer UA or by using Application layer software (e.g.
     telnet client) to connect to an MSA, MTA, or Gateway.  MSA
     connection is determined by local configuration.  If an MTA relay
     (or gateway) not affiliated with a recipient is used, that might
     also be determined by configuration.  MTA or Gateway affiliated
     with a recipient (by Sender, oMUA, MSA, relay, or gateway
     determination) is located via DNS MX records.

   o messages may transit zero or more non-Internet transport "clouds"
     connected by gateways

   o an MSA (when used) is operated by an Administrative Unit which is
     separate from the Recipient (except by coincidence), and may be
     associated with the Sender (as shown) or may be operated by a third
     party (e.g. an ISP)

   o MSA, MTA, Gateway, MDA operate architecturally at the Transport
     layer, i.e. below the Application layer and above low-level data
     transfer layers (details depend on whether one is using a 4-, 5-,
     or 7-layer model)

   o message delivery as directed by MX records points to hosts
     associated with an Administrative Unit which is not (except by
     coincidence) affiliated with the sender; that Unit may be
     affiliated with the recipient or with a third party (e.g. an ISP)

   o Architecturally, all messages must pass through at least one
     Gateway (which may be implemented in conjunction with an MTA, MDA,
     or even MUA).  [this is necessary to accomplish MIME
     message/partial reassembly as detailed in RFC 1344].  As reassembly
     (RFC 2046) is a rather complex process that involves message
     modification, the operative unit is unquestionably a gateway [it
     might be useful to differentiate different types of gateways,
     though that is not done in the simple diagram above or in the
     draft]

   o message/partial reassembly must occur on the recipient side of the
     all MX hosts for the recipient domain [all fragments must pass
     through a single gateway for reassembly]

   o filtering operates at the Application layer rather than transport
     layer

   o [N.B. no discussion here of intermediate layers such as transfer
     encoding (Presentation layer) or security wrapping
     (signing/encrypting)]

   o filtering must occur after message reassembly (Again see RFC 1344
     and see also http://www.kb.cert.org/vuls/id/836088 to see what can
     happen when that architectural principle is ignored)

   o filtering can be accomplished at several places

   o internally, gateways perform some operations at application level;
     that is where content is mangled (a.k.a. modified) [of course, mere
     relaying also involves application-level operations (e.g. DNS
     lookups); ditto for MSA and MDA tasks]

   o aliasing and list expansion (RFCs 822, 2822), also known as "mail
     exploder" (RFC 1208), takes place at Transport level, with
     additional "hops" as determined by MX records associated with the
     domain(s) of the (new) [SMTP envelope] paths resulting from
     aliasing or list expansion; as with initial injection into
     transport, those MX hosts might be classified as MTA or Gateway.
     These are automated Transport-level processes not requiring direct
     intervention of a (human) User.

   o aliasing and list expansion can only take place where the
     local-part of the (SMTP envelope) path is interpreted;
     architecturally that is at an MDA

   o (human) user operations such as resending, responding, and active
     mediation take place at (human) user level, interacting with
     Application layer software and some sort of UI.

   o the message store doesn't fit very well with this diagram; it can
     be envisioned as being part of the MDA or rMUA

Especially, the draft description of mailing list expanders as users is
highly confusing.  A description of the mail system architecture is
incomplete unless it discusses the gateway vs. message fragment
reassembly issues documented in RFC 1344, ignorance of which has led to
security problems.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Dave Crocker <[email-masked]>
Subject: "User" confusion and incomplete description of architecture in draft-crocker-email-arch-04.txt
Date: Tue, 5 Apr 2005 07:38:27 -0400
Cc: ietf-smtp <[email-masked]>
Sender: [email-masked]

The email architecture draft uses the terms "User", "Mediator",
"Gateway", "Author", and "Originator" in ways which are quite confusing.

   o Section 2 lists Actors: user/MHS/AU

   o Section 2.1 subdivides User Actors as Originator/Recipient/Mediator
     (but doesn't mention resenders and respondents)

   o Section 2.1.1 equates Originator and Author (but as previously
     noted, fails to distinguish Author and Sender)

   o Section 2.1.3 says that list expansion software is a Mediator (i.e.
     a User)

   o Figure 3 (appropriately) shows Gateways as part of the MHS

   o Section 2.2.3 reclassifies (Administrative) Actors as "User
     Mediators"/"MHS Relays"/"Packet Switches" (confusing human users
     with list expansion software and classifying low-level Data
     Link/Physical layer hardware as Actors)

   o Section 2.2.4 says that Gateways are hybrids of Users (but not
     listed in other section 2 descriptions of users) and Relays

   o Section 4 is headed "Services" but discusses messages, agents, and
     stores.

   o Section 4.2 says Mediators (previously classified as Users) are
     MUAs (so in effect there is no distinction among a human user, a
     software MUA, and mailing list expansion software).

   o Section 5 reverses that and again classifies a Mediator as a User.

   o Section 5.1 says that aliasing is readdressing (which is also what
     list expansion is, as noted in RFCs 822/2822)

   o Section 5.1 also equates aliasing with MDAs (probably justifiable,
     but then the same applies to list expansion, which has previously
     (separately) been classified as MUA and as User)

   o Section 5.3 says that a mailing list is an Actor and is an
     elaboration of a redirector or resender (sect. 5.2)

   o Section 5.4 says that a Gateway (classified as part User by sect.
     2.2.4) is a type of relay or MTA.

Taken together, those sections say

   o list expander = mediator = MUA = user

   o list expander = actor ~ redirector = resender

   o aliasing = readdressing = redirecting = MDA

which further implies that an MUA and an MDA are very similar.

The draft also creates confusion between separate layers, conflating
human users (which are strictly not part of layering models) with
application layer UAs, while artifically separating list expansion
(really Transport-level redirection) from aliasing (also Transport-level
redirection).

There appears to be no mention of topological considerations, and
gateway architectural functionality appears to be shown as optional
(Figure 3) or missing (Figures 4, 5).

Consider the following simplified diagram for further discussion (view
with a monospaced font):

 +----------------------------------------+ (Mediate/Respond/Resend)
 v (Respond)     /(Mediate/Resend)        ^
user (Author)-->User (Sender)            User (Recipient)
   ____________/\                         ^
  /  /  ______/  \                        |    _______________
oMUA/  /   /      \            [Filter]~~rMUA
 |-(--+---+--------+--+        /^\    \   ^     Application
 |/   |   |           |       / | \    \  |    _______________
 v    v   v        _  v      /  v  \    \ v
MSA--MTA--Gateway-(_)-Gateway--MTA--MDA--[MS]  Transport (MHS)
  \__/|  /|    \____/\      \______/ |
   \__)__|_)_________/ \             |
      |____|____________+<-----------+ (Alias/list expansion)
 ^   [   Possible MX hosts  ]                (a.k.a. "mail exploder")
 |   [Possible recipient domain Administrative Unit]
  \[Sender Administrative Unit]

I believe the following statements to be accurate:

   o message author(s) and sender are architecturally distinct (RFCs
     822, 2822) but the sender may (by coincidence) be an author.

   o a message sender initiates message transport either by using an
     Application layer UA or by using Application layer software (e.g.
     telnet client) to connect to an MSA, MTA, or Gateway.  MSA
     connection is determined by local configuration.  If an MTA relay
     (or gateway) not affiliated with a recipient is used, that might
     also be determined by configuration.  MTA or Gateway affiliated
     with a recipient (by Sender, oMUA, MSA, relay, or gateway
     determination) is located via DNS MX records.

   o messages may transit zero or more non-Internet transport "clouds"
     connected by gateways

   o an MSA (when used) is operated by an Administrative Unit which is
     separate from the Recipient (except by coincidence), and may be
     associated with the Sender (as shown) or may be operated by a third
     party (e.g. an ISP)

   o MSA, MTA, Gateway, MDA operate architecturally at the Transport
     layer, i.e. below the Application layer and above low-level data
     transfer layers (details depend on whether one is using a 4-, 5-,
     or 7-layer model)

   o message delivery as directed by MX records points to hosts
     associated with an Administrative Unit which is not (except by
     coincidence) affiliated with the sender; that Unit may be
     affiliated with the recipient or with a third party (e.g. an ISP)

   o Architecturally, all messages must pass through at least one
     Gateway (which may be implemented in conjunction with an MTA, MDA,
     or even MUA).  [this is necessary to accomplish MIME
     message/partial reassembly as detailed in RFC 1344].  As reassembly
     (RFC 2046) is a rather complex process that involves message
     modification, the operative unit is unquestionably a gateway [it
     might be useful to differentiate different types of gateways,
     though that is not done in the simple diagram above or in the
     draft]

   o message/partial reassembly must occur on the recipient side of the
     all MX hosts for the recipient domain [all fragments must pass
     through a single gateway for reassembly]

   o filtering operates at the Application layer rather than transport
     layer

   o [N.B. no discussion here of intermediate layers such as transfer
     encoding (Presentation layer) or security wrapping
     (signing/encrypting)]

   o filtering must occur after message reassembly (Again see RFC 1344
     and see also http://www.kb.cert.org/vuls/id/836088 to see what can
     happen when that architectural principle is ignored)

   o filtering can be accomplished at several places

   o internally, gateways perform some operations at application level;
     that is where content is mangled (a.k.a. modified) [of course, mere
     relaying also involves application-level operations (e.g. DNS
     lookups); ditto for MSA and MDA tasks]

   o aliasing and list expansion (RFCs 822, 2822), also known as "mail
     exploder" (RFC 1208), takes place at Transport level, with
     additional "hops" as determined by MX records associated with the
     domain(s) of the (new) [SMTP envelope] paths resulting from
     aliasing or list expansion; as with initial injection into
     transport, those MX hosts might be classified as MTA or Gateway.
     These are automated Transport-level processes not requiring direct
     intervention of a (human) User.

   o aliasing and list expansion can only take place where the
     local-part of the (SMTP envelope) path is interpreted;
     architecturally that is at an MDA

   o (human) user operations such as resending, responding, and active
     mediation take place at (human) user level, interacting with
     Application layer software and some sort of UI.

   o the message store doesn't fit very well with this diagram; it can
     be envisioned as being part of the MDA or rMUA

Especially, the draft description of mailing list expanders as users is
highly confusing.  A description of the mail system architecture is
incomplete unless it discusses the gateway vs. message fragment
reassembly issues documented in RFC 1344, ignorance of which has led to
security problems.

Date: Sat, 2 Apr 2005 12:15:46 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: list traffic in iso-8859-6?
Cc: Bruce Lilly <[email-masked]>, Keith Moore <[email-masked]>
Sender: [email-masked]

Bruce Lilly writes:
> On Fri April 1 2005 12:36, Keith Moore wrote:
>
>>  is there any particular reason why a couple of the messages that 
>>  have been posted here recently (one by Dave, one by Bruce) have 
>>  used charset iso-8859-6 (Arabic)?
>
> Mine was a response to Arnt's message.  I can't explain it.

It's mandated by RFC ٢١٢٨, isn't it? ;)

Seriously, I can't explain it either. My MUA cannot generate 8859-6 in 
the first place. This message ought to use UTF-8.

Arnt

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: list traffic in iso-8859-6?
Date: Fri, 1 Apr 2005 22:35:10 -0500
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

On Fri April 1 2005 12:36, Keith Moore wrote:
> 
> is there any particular reason why a couple of the messages that have 
> been posted here recently (one by Dave, one by Bruce) have used charset 
> iso-8859-6 (Arabic)?

Mine was a response to Arnt's message.  I can't explain it.

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Fri, 1 Apr 2005 15:40:23 -0800
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Sender: [email-masked]

>  Formally, I'd say "notification address" or some such, because the address
>  is where various kinds of notifications (nondelivery, delivery, delay,
>  receipt/read, and responses from robots) get sent by default.
>
>  Informally, I'd say "bounces".  It's not as precise but it has a higher
>  recognition factor.

i've tried the formal/informal distinction.

as nearly as i can tell, there is no willingness of the community to support 
multiple terms, so we need to choose exactly one.  

  d/

ps. I should respond to Carl's implied question about the intended audience 
for the email-arch document.  It is not merely the world of standards 
participants.  I am hoping the document is useful for anyone and everyone who 
needs to engage in any degree of technical discussion about Internet Mail.

  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Dave Crocker <[email-masked]>
To: Keith Moore <[email-masked]>, ietf-smtp <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Fri, 1 Apr 2005 15:37:55 -0800
Subject: Re: list traffic in iso-8859-6?
Sender: [email-masked]

>  is there any particular reason why a couple of the messages that have been
>  posted here recently (one by Dave, one by Bruce) have used charset iso-
>  8859-6 (Arabic)?

my mua (pocomail) is set to use us-ascii and i've enabled QP in headers.  

sometimes the mua screws up, but i haven't been able to determine when or why.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Date: Fri, 1 Apr 2005 17:11:33 -0500
From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Sender: [email-masked]

> Finding the best, single term to describe the rfc2821.mailfrom address
> has  been a challenge.  In the latest round of the document, I latched
> onto  'bounces' because that seems to be a term preferred by the
> community. 

Formally, I'd say "notification address" or some such, because the
address is where various kinds of notifications (nondelivery, delivery, 
delay, receipt/read, and responses from robots) get sent by default.

Informally, I'd say "bounces".  It's not as precise but it has a higher
recognition factor.

It's like the difference between "receipt notification" and
"return receipt".  The latter term is meaningless, but everyone seems
to (think they) know what it means anyway.

Keith

Date: Fri, 01 Apr 2005 10:06:54 -0800
From: "Carl S. Gutekunst" <[email-masked]>
To: [email-masked]
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Sender: [email-masked]

>given the rfc2821 language, it is tempting to change the document to use the 
>term "errors".  the problem, then, is that it might be confused with 
>"errors-to".
>
>but, as I say about all the content of the email-arch document, the deciding 
>factor is any indication of community preference.
>
"Community preference" for a standards track document should be the 
community of people who read and implement standards, of course; and I'm 
reluctant to speak to that. I live in the world of operations staff and 
highly educated end users, even the best of whom are uncertain about 
which parts of the message are contained in the header and which in the 
envelope. For many years I've tried -- and failed -- to craft language 
that would allow these people to reliably verbalize "RFC2821 MAIL FROM" 
or "RFC 2822 From." Six months ago, we (at Habeas) started using the 
term "bounce address" and the result has been amazing. No one ever needs 
the term exaplained more than once; and from then on the dialog 
continues with no confusion or ambiguity. For the first time in 15 
years, ordinary people can say what they mean and have it understood.

If the architecture doc does not standardize on the term "bounce 
address," it should at least acknowledge that the term is very useful 
for its clarity in ordinary human conversation.

<csg>

//

From: Keith Moore <[email-masked]>
Subject: list traffic in iso-8859-6?
Date: Fri, 1 Apr 2005 12:36:24 -0500
To: ietf-smtp <[email-masked]>
Sender: [email-masked]

is there any particular reason why a couple of the messages that have 
been posted here recently (one by Dave, one by Bruce) have used charset 
iso-8859-6 (Arabic)?

reason I ask is, my Mac Mail client displays the digits in Arabic (e.g. 
"rfc٢٨٢١" rather than "rfc2821").  I'm not sure whether that's 
consistent with iso-8859-6 or not, but it does make the messages 
difficult for me to read.

Keith

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Fri, 1 Apr 2005 07:37:34 -0800
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Sender: [email-masked]

>  N.B. "used to report errors"

Finding the best, single term to describe the rfc2821.mailfrom address has 
been a challenge.  In the latest round of the document, I latched onto 
'bounces' because that seems to be a term preferred by the community.  I have 
been more concerned about having the term move usage away from 'sender' or the 
like than i have about precise conformance to rfc2821 vocabulary.

since my concern has been problematic, established terminology, one other 
benefit of the term 'bounces' is that there is no ambiguity at all.  no one 
can think the references is to any other place that has an address.

given the rfc2821 language, it is tempting to change the document to use the 
term "errors".  the problem, then, is that it might be confused with 
"errors-to".

but, as I say about all the content of the email-arch document, the deciding 
factor is any indication of community preference.  

If folks have a preference, they need to voice it.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Date: Fri, 1 Apr 2005 10:19:17 -0500
Sender: [email-masked]

On Thu March 31 2005 06:11, Arnt Gulbrandsen wrote:

> 2) isn't "bounces-to" a fairly good description of how most running code 
> treats the MAIL FROM address?

It's not only a description of how (RFC-compliant) running code
operates, it's specified in the relevant RFCs:

RFC 2821, section 3.3:

      MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>

   This command tells the SMTP-receiver that a new mail transaction is
   starting and to reset all its state tables and buffers, including any
   recipients or mail data.  The <reverse-path> portion of the first or
   only argument contains the source mailbox (between "<" and ">"
   brackets), which can be used to report errors (see section 4.2 for a
   discussion of error reporting).

N.B. "used to report errors"

RFC 821, section 3.3:

           MAIL <SP> FROM:<reverse-path> <CRLF>

         This command tells the SMTP-receiver that a new mail
         transaction is starting and to reset all its state tables and
         buffers, including any recipients or mail data.  It gives the
         reverse-path which can be used to report errors.

N.B. the same wording "used to report errors"

RFC 788, section 3.1:

            MAIL <SP> FROM:<reverse-path> <CRLF>

         This command tells the the SMTP-receiver that a new mail
         transaction is starting and to reset all its state tables and
         buffers including any recipients or mail data.  It gives the
         reverse-path which can be used to report errors.

N.B. same wording.  RFC 788 was the original SMTP specification, dated
November 1981.  I.e., from its inception nearly a quarter century ago,
the semantics of SMTP MAIL FROM have been, and remain, the path by
which delivery errors are reported (with a minor evolutionary note that
routing is now discouraged as a normal feature, being reserved for
working around temporary DNS failures).

SMTP was preceded by MTP (the not-so-simple Mail Transfer Protocol) as
defined in RFCs 780 and 772.  The same concept existed in MTP:

RFC 780, section 2:

   The arguments to the MAIL command are a FROM path and a TO path.  The
   TO path is a source route while the FROM path is a return route
   (which may be used to return a message to the sender when an error
   occurs with a relayed message).

RFC 772 was a bit different:

      MAIL <SP> "FROM:" <sender> [<SP> "TO:" <path>] <CRLF>

         <sender> is a mailbox and <path> is a source routing list of
         hosts and destination mailbox.  If accepted, it returns a 354
         reply and considers all succeeding lines to be the message
         text.

RFC 722 was issued September 1980 and obsoleted by 780 in May 1981.

Frank, you seem to be living in MTP-land, stuck in late 1980.  We in
the 21st century are talking about SMTP as it has existed since 1981.
I realize that you're trying to make a point about joe jobs, but we're
discussing the mail architecture as designed and implemented:
1. we need to accurately describe SMTP, not an early, long-obsolete,
   short-lived version of MTP (except possibly as a[n] historic note).
2. it is a fact that the mail system has been abused, however we should
   not let such abuse (dis)color the description of the mail system
   architecture [*]
3. suggestions for something different from SMTP as it was in the
   beginning and is now should rightly take place on the mail-ng
   mailing list or in some IRTF venue, or at minimum in a separate
   discussion from the description of the long-standing mail
   architecture.

* You are welcome to author a draft describing which aspects of the
mail architecture are abused by spammers, but it is first desirable to
have a standardized description of that architecture, and that is the
topic of the current discussion.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Date: Fri, 1 Apr 2005 09:33:49 -0500
Cc: Dave Crocker <[email-masked]>
Sender: [email-masked]

P.S. draft section 5.2 also has a "new message" (for resending, which
retains the original Message-ID field and is therefore not in fact a
new message).

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: Dave Crocker <[email-masked]>
Subject: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Date: Fri, 1 Apr 2005 09:06:57 -0500
Cc: ietf-smtp <[email-masked]>
Sender: [email-masked]

The email architecture draft discusses"new" messages and message-ids in
several places.  Some of that discussion contradicts the core email RFCs
(822, 2822) and may cause confusion.

Here's what RFC 2822 has to say:

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.

   Note: There are many instances when messages are "changed", but those
   changes do not constitute a new instantiation of that message, and
   therefore the message would not get a new message identifier.  For
   example, when messages are introduced into the transport system, they
   are often prepended with additional header fields such as trace
   fields (described in section 3.6.7) and resent fields (described in
   section 3.6.6).  The addition of such header fields does not change
   the identity of the message and therefore the original "Message-ID:"
   field is retained.  In all cases, it is the meaning that the sender
   of the message wishes to convey (i.e., whether this is the same
   message or a different message) that determines whether or not the
   "Message-ID:" field changes, not any particular syntactic difference
   that appears (or does not appear) in the message.

Draft section 2.1.3 refers to a "new message" several times, and states
that list expanders provide an example.  But list expanders do not
generally elide/replace message-ids, and therefore -- using standard
terminology from the core email RFCs -- there is in fact no "new
message"; a list expander redistributes the *same* message (with
unchanged message-id).  The section also states that a list expander
originates messages, which in general is not the case; a list expander
redistributes existing messages.

Section 3.3 discusses message identifiers, but fails to note that the
Message-ID message header field is optional.  It also alludes to
multiple identifiers, but does not note that Received fields may
incorporate a msg-id in the optional "id" component.

Section 5.3 also mentions "new message" in the context of mailing list
expansion; as noted above, there is in fact no "new message".