Subject: Re: I-D ACTION:draft-arun-ncc-smtp-02.txt

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Apr 2005 12:52:49 -0400

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 7 Apr 2005 13:06:27 -0400

> 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: Keith Moore <[email-masked]>
Date: Fri, 8 Apr 2005 09:16:44 -0400

[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.

---

From: Arun Sankar <[email-masked]>
Date: Fri, 08 Apr 2005 14:55:45 +0530

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.

-- 
Arun

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