Subject: Re: I-D ACTION:draft-lilly-legacy-fields-00.txt
From: Bruce Lilly <[email-masked]>
To: ietf-822 <[email-masked]>
Cc: Keith Moore <[email-masked]>, Frank Ellermann <[email-masked]>
Date: Fri, 22 Apr 2005 10:51:10 -0400
List-Id: <ietf-822.imc.org>

On Thu April 21 2005 22:49, Keith Moore wrote:

> would that be like fighting useless sarcasm with more useless sarcasm?

The question is really off-topic for the mailing list, but the answer
is "no".

Now, if you know of any unregistered but RFC-documented message header
fields which aren't included in RFC 4021 registration forms or the
draft, contrary to the requirement of section 3 of BCP 90, that might
be a useful topic for either this mailing list or the ones mentioned in
BCP 90.

Cc: [email-masked]
From: Keith Moore <[email-masked]>
Subject: Re: I-D ACTION:draft-lilly-legacy-fields-00.txt
Date: Thu, 21 Apr 2005 22:49:31 -0400
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> Good idea, here fighting spam with more spam might work.  Bye.

would that be like fighting useless sarcasm with more useless sarcasm?

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-lilly-legacy-fields-00.txt
Date:  Thu, 21 Apr 2005 23:30:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

[email-masked] wrote:

> http://www.ietf.org/internet-drafts/draft-lilly-legacy-fields-00.txt

JFTR, my UA still has an "Fcc", I didn't know that this was
documented in RfC 724, tnx for info.

| Appendix B. Disclaimer
|
|   The author is male; any reference to "or she" or "/SHE" in
|   boilerplate of this document is irrelevant.

Good idea, here fighting spam with more spam might work.  Bye.

Date: Fri, 15 Apr 2005 10:49:20 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Addressing  "Out of office" Vacation accounts
Sender: [email-masked]

> 
> If there any standard, past proposal, effort or otherwise for detecting
> auto-reply "vacation" or "out of office" messages?

I don't know of a good way to _detect_ autoresponses, however there are some
tricks that can be used to discourage autoresponses.

some autoresponders will not respond when they see
"Precedence: junk" or "Precdence: list" in the message header.

another trick is to use a unique MAIL FROM address (different from the 
list address) and to filter mail that is sent to that MAIL FROM address.  
this tends to catch most bounces and some automatic responses.
All mailing lists should be doing this.

of course I recommend testing for RFC 3834's Auto-Submitted field and
also for the Auto: prefix, but that's based on an assumption that people
will actually implement RFC 3834.   It's too early to tell, but I've had
a lot of positive feedback.  And of course part of the reason for writing
this RFC was to encourage more uniformity and thereby enable separate
processing of such notices.  At any rate I don't think it will hurt to
check for these in addition to OOF and other tokens.

Keith

Date: Fri, 15 Apr 2005 10:54:37 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Addressing "Out of office" Vacation accounts
Cc: Hector Santos <[email-masked]>
Sender: [email-masked]

Hector Santos writes:
> If there any standard, past proposal, effort or otherwise for 
> detecting auto-reply "vacation" or "out of office" messages?

RFC 3834 suggests one, which won't help you much yet.

You also need a bit of hackery to handle old software. Look for X-Loop 
and Vacation header fields, and some more fields. I don't really 
remember which - it's been a while since I did this.

Arnt

From: "Hector Santos" <[email-masked]>
To: "IETF-822" <[email-masked]>
Subject: Addressing  "Out of office" Vacation accounts
Date: Thu, 14 Apr 2005 22:36:34 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

If there any standard, past proposal, effort or otherwise for detecting
auto-reply "vacation" or "out of office" messages?

I understand these two terms:  "vacation" or "out of office" (OOF) is
probably the closet  thing to implementing a partial filter solution.

I am thinking of adding some logic into our list server  but before I do I
would like to know the issues that I can come across.

Besides the obvious of automated disabling of list mail accounts false
positive), what other things would make this unreasonable?

Other questions:

What existing MUA products/software offer built OOF auto-reply features?

What existing list servers have features to support the disabling or making
inactive the list member on vacation?

Is there a past proposal, if not, why having there been a effort to write
one?  It seems like a reasonable consideration.  I would not mind writing a
draft if enough people are interested to pursue it, but I would not care if
anyone wrote it too. I would eagerly anticipate it and support it.

Thanks

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-arun-ncc-smtp-02.txt
Date:  Fri, 08 Apr 2005 23:43:03 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Cc: Keith Moore <[email-masked]>
Sender: [email-masked]

Keith Moore wrote:

> it will work so unreliably in practice that it's better to
> not have the feature.

Indeed.  If a relay supports it, but the next hop doesn't, what
should it do, send me a Potential Unintended Delivery Message ?

                        Bye, Frank

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

To: [email-masked]
Xref: clerew local.mime:4613
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Message with no From at all (6)
Date: Fri, 1 Apr 2005 10:45:41 GMT
Lines: 50
Sender: [email-masked]

In <[email-masked]> "Charles Lindsey" <[email-masked]> writes:

>So we have so far established that "From: <>" gets through to most people
>(except Bruce, who claims he never received his) but we need more evidence
>as to what systems allow completely absent Froms to pass through
>unscathed.

So, having failed to get my test messages (other than From: <>) through
the mail expander at imc, I sent test messages with no From header at all
directly to 12 people on this list who had replied to my earlier <> tests.

I have 9 replies, of which 6 reported that their local Delivery agent, or
an MTA close to that, had manufactured a From header out of the envelope
from (which was readily identifiable, being
[email-masked]). Two of these were Sendmail, two were
Postfix, and one was PMDF/JESMS (the other didn't say). It was reported
that Exim, Gmail and Qmail were happy to pass the message without
alteration.

Although Sendmail can be configured not to make this change, it is the
default and few sites change it (though one recipient had done so on his
own system). There was quite some discussion amongst some of these 12
recipients afterwards in which some of them expressed the opinion that the
current behaviour of Sendmail et al was actually a Good Thing, especially
for large ISPs. It was also reported that some IMAPs might not take kindly
to a missing From, although apparently Cyrus is OK.

So it looks like maybe 50% of existing systems would do unsuitable things
with Bruce's proposal, either by giving away the envelope From address
(thus defeating the ourpose of the proposal) or, in the case of messages
which had made it through a mailing list, putting the address of the
mailing list expander in the From header, which could cause much
confusion.

OTOH, it appears that From: <> will propagate pretty well on the existing
network. The only reported problem has been from Bruce, who claimed not to
have seen the test message to this list (though most others seem to have
seen it). I also sent a test with From: <> direct to Bruce's MX, but he
has not yet reported whether or not it arrived.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5