[Top] [All Lists]

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

2005-04-14 04:12:01

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.

----- Original Message -----
From: "Arun Sankar" <arun(_at_)india(_dot_)hp(_dot_)com>
To: "ietf-smtp" <ietf-smtp(_at_)imc(_dot_)org>; "Keith Moore" 
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

Keith Moore wrote:

[followups redirected to ietf-smtp(_at_)imc(_dot_)org 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
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


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


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