Subject: Re: text/html an abomination
From: "WJCarpenter" <[email-masked]>
To: <[email-masked]>
Date: Sat, 22 Jun 2002 13:27:11 -0700 (PDT)
List-Id: <ietf-822.imc.org>

> It doesn't require supporting active content in the mail reader.  (And
> HTML *is* active content; anything that results in any sort of outgoing
> network connection, such as <img> tags, is inherently active content.
> If you disable all of that, you get a stripped version of HTML that may
> possibly be mostly safe unless you use Microsoft's HTML rendering
> engine, but almost no one does that.)

You can disallow (or restrict in various ways) going outside the message
to follow links.  Graphics get referenced as other body parts inside
a multipart/related bundle.  After all, if you're just using HTML as a
handy way to bundle links to external content (and you don't care that
much about formatting graces), it's not much of an advantage over using
text and saying "come look at the picture of my dog at
<http://www.example.com/mydoggie.html>".

(For an example of a webmail interface that does that pretty reasonably,
see <http://www.squirrelmail.org>.)
-- 
[email-masked] (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

To: [email-masked]
Subject: Re: text/html an abomination
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Sat, 22 Jun 2002 11:43:25 -0700
Lines: 9
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> The advantage with separating the quoted text as a separate body part is
> that you can send it exactly as is, not cut in your own way.

That's a significant drawback, not a feature, IMO.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Sat, 22 Jun 2002 15:33:39 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: text/html an abomination
Sender: [email-masked]

At 11:10 -0600 02-06-20, Lyndon Nerenberg wrote:
>or are you talking about intermixing quoted text with reply text
>(as I'm doing here), but with individual MIME parts for each
>chunk of quoted text and reply?
>
>If the former, it hasn't been accepted because it almost always
>presents the quoted text in a useless manner. Appending a large
>blob like that doesn't give any context to the reply, and without
>the context, the quoted text serves no useful purpose.
>
>The Plan 9 MUA (the one built on acme) appends the message being
>replied to as a message/rfc822, and IMO doing so is just a waste of
>disk space and bandwidth.

The advantage with separating the quoted text as a separate
body part is that you can send it exactly as is, not cut
in your own way. It also allows digital seals and signatures,
but digital seals and signatures are also something the
market does not seem to want.

References between a reply and the text it replies to could
be done by references into the body of the quoted text,
but that is maybe a too complex solution for a task done
simpler as it is done today.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked]
Xref: clerew local.mime:1727
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: text/html an abomination
Date: Fri, 21 Jun 2002 19:48:12 GMT
Lines: 21
Sender: [email-masked]

In <p05100303b937439f036f@[192.168.100.102]> Jacob Palme <[email-masked]> writes:

>Another usage of a series of body parts, which I think would
>be very natural, would be to include the message you are
>replying to in one body part, and putting your reply in another
>body part. But this, also, has not been accepted by the market.

Arrrgh! That would just encourage the loons who quote the whole of a
lengthy message, just so they can add their "me too" in reply.

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

Organization: ACI Worldwide - Advanced Technology Group
To: Jacob Palme <[email-masked]>
cc: [email-masked]
Subject: Re: text/html an abomination 
Date: Thu, 20 Jun 2002 11:10:22 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> Yes, a series of body parts with Content-Disposition: Inline
> could give a similar effect. But why is it better than HTML?

Because it gives you the pretty pictures without exposing you to the
risk of active HTML content.

> Few existing mailers give good support for producing a series
> of body parts. You could of course try to get mail software
> developers to support sending of a series of body parts
> with Content-Disposition: Inline better. But will you succeed?

Given enough education? Probably. To have a realistic chance
though we would need volunteers to fix this in a couple of
popular open-source GUI mail clients in order to expose the
concept to the masses.

> Another usage of a series of body parts, which I think would
> be very natural, would be to include the message you are
> replying to in one body part, and putting your reply in another
> body part. But this, also, has not been accepted by the market.

Do you mean:

   multipart/mixed
      text/plain  (my reply to the message)
      message/rfc822 (what I am replying to)

or are you talking about intermixing quoted text with reply text
(as I'm doing here), but with individual MIME parts for each
chunk of quoted text and reply?

If the former, it hasn't been accepted because it almost always
presents the quoted text in a useless manner. Appending a large
blob like that doesn't give any context to the reply, and without
the context, the quoted text serves no useful purpose.

The Plan 9 MUA (the one built on acme) appends the message being
replied to as a message/rfc822, and IMO doing so is just a waste of
disk space and bandwidth.

--lyndon

To: [email-masked]
Subject: Re: text/html an abomination
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 20 Jun 2002 09:47:08 -0700
Lines: 14
Sender: [email-masked]

Jacob Palme <[email-masked]> writes:

> Yes, a series of body parts with Content-Disposition: Inline could give
> a similar effect. But why is it better than HTML?

It doesn't require supporting active content in the mail reader.  (And
HTML *is* active content; anything that results in any sort of outgoing
network connection, such as <img> tags, is inherently active content.  If
you disable all of that, you get a stripped version of HTML that may
possibly be mostly safe unless you use Microsoft's HTML rendering engine,
but almost no one does that.)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Thu, 20 Jun 2002 14:45:15 +0200
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: text/html an abomination
Sender: [email-masked]

At 20:47 -0600 02-06-19, Lyndon Nerenberg wrote:
>  > I often embed pictures in e-mail.
>
>MIME allows for this. Unfortunately most MUAs don't properly handle
>the display of multipart MIME messages properly, making it almost
>impossible to use the native MIME capabilities in this manner.  If
>we could educate MUA authors that "MIME section" != attachment we
>could make a lot of progress towards reducing the gratuitous use
>of HTML.

Yes, a series of body parts with Content-Disposition: Inline
could give a similar effect. But why is it better than HTML?
Few existing mailers give good support for producing a series
of body parts. You could of course try to get mail software
developers to support sending of a series of body parts
with Content-Disposition: Inline better. But will you succeed?

Another usage of a series of body parts, which I think would
be very natural, would be to include the message you are
replying to in one body part, and putting your reply in another
body part. But this, also, has not been accepted by the market.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Thu, 20 Jun 2002 10:57:49 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Jacob Palme <[email-masked]>
Cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: text/html an abomination
Sender: [email-masked]

Jacob Palme <[email-masked]>
> Writing a neatly formatted text will cause more time for
> the sender, but reduce time for the reader. Thus, the
> larger the number of recipients is, the more advantageous
> it is to format them nicely using HTML.
...

The same argument can be used to explain why spam is so much better
written than regular mail: Impeccable spelling, immaculate punctuation,
faultless grammar, words and sentences always beautifully crafted.

--Arnt

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: text/html an abomination 
Date: Thu, 20 Jun 2002 03:28:19 -0400
Sender: [email-masked]

> Spam messages are intended for millions of readers. That is
> why such messages are often in HTML format.

no, spam messages are advertising, and the purpose of advertising
is to get your attention (often it works better if it's annoying).
so advertisers find HTML more effective than plain text.

of course, spammers should be fed to pirhana for other reasons 
anyway; their use of HTML to annoy us just makes the case clearer.

Keith

Organization: ACI Worldwide - Advanced Technology Group
To: Jacob Palme <[email-masked]>
cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: text/html an abomination 
Date: Wed, 19 Jun 2002 20:47:21 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> I often embed pictures in e-mail.

MIME allows for this. Unfortunately most MUAs don't properly handle
the display of multipart MIME messages properly, making it almost
impossible to use the native MIME capabilities in this manner.  If
we could educate MUA authors that "MIME section" != attachment we
could make a lot of progress towards reducing the gratuitous use
of HTML.

--lyndon

When you're a teenager, "but everyone else does it" isn't an
excuse for doing something stupid; when you're a manager, it's
the perfect excuse for buying Microsoft.

Date: Wed, 19 Jun 2002 21:09:00 +0200
To: Russ Allbery <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: text/html an abomination
Cc: [email-masked]
Sender: [email-masked]

At 19:31 -0700 02-05-06, Russ Allbery wrote:
>It does make sense to recognize that most e-mail is written quickly
>without a lot of attention paid to design, and that therefore complex
>visual layout languages are frequently inappropriate for e-mail in the
>same way that one doesn't generally use FrameMaker to maintain one's
>shopping list.  Trying to shoehorn normal e-mail into a page design
>paradigm seems very wrong to me, and the cause of a lot of the worst of
>the brokenness of multipart/alternative as it's seen in the wild.

Writing a neatly formatted text will cause more time for
the sender, but reduce time for the reader. Thus, the
larger the number of recipients is, the more advantageous
it is to format them nicely using HTML.

Many mail messages have only one recipient. In that case,
it is often not worth the effort to format it nicely using
HTML.

Spam messages are intended for millions of readers. That is
why such messages are often in HTML format.

However, also ordinary mail sometimes has more than one
recipient. In such a case, HTML may be suitable. Another
case where HTML is useful is if you want to show something
which cannot be shown in ordinary textual mail, for example
embedded pictures.

I often embed pictures in e-mail. The pictures are copies
of how some web pages looked on my screen, when I am
writing to people trying to get them to modify their user
interfaces.

One case where HTML is useful is for tables. There was a
time, a long time ago, when you could assume that plain
text e-mail was rendered with monospaced fonts. Not any
more. When I send tables requiring monospaced fonts, I mark
it with HTML markup to indicate that it must be monospaced.
I would prefer to use the <pre> tag but the mailer I use
(Macintosh Eudora) does not allow <pre> tags, but it does
allow <font type=Courier> so I use that when I want to send
text which will not look right unless it is shown with a
monospace font.

(Sending HTML tables does not work for many receiving
mailers, so that is not an option yet.)
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Tue, 18 Jun 2002 21:00:23 -0400
Sender: [email-masked]

> Agreed.  However, NNTP is for me an excellent example of why it's good to
> write at least *one* implementation before publishing the standard

it wouldn't bother me if that were reqiured for Proposed status.

Keith

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 18 Jun 2002 17:05:12 -0700
Lines: 20
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> Not NNTP.  The NNTP RFC was published before there were any real
>> implementations, which is one of the reasons why it has so many flaws
>> that later had to be corrected in practice.

> thanks for correcting my mis-impression.  

> though it's certainly possible for protocols that are widely deployed
> prior to being published to have large numbers of flaws also ...

Agreed.  However, NNTP is for me an excellent example of why it's good to
write at least *one* implementation before publishing the standard
(incidentally, the author of the NNTP standard agrees wholeheartedly with
me on that and would do it differently in retrospect).  There were ideas
in there that sounded good on paper but in practice simply didn't work,
like SLAVE.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Tue, 18 Jun 2002 19:57:27 -0400
Sender: [email-masked]

> Not NNTP.  The NNTP RFC was published before there were any real
> implementations, which is one of the reasons why it has so many flaws that
> later had to be corrected in practice.

thanks for correcting my mis-impression.  

though it's certainly possible for protocols that are widely deployed prior 
to being published to have large numbers of flaws also ...

Keith

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 18 Jun 2002 11:28:29 -0700
Lines: 17
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> Indeed so. If some non-standardized protocol is out in the wild, and
>> acquiring new features in a haphazard manner, and if it contains at least
>> some features of merit, then standardizing it may well enable some control
>> of the situation (e.g. by deprecating the worst features, clarifying
>> intentions, resolving inconsistencies, discouraging competitive protocols,
>> etc.).

> and sometimes we do this.  HTTP, NNTP, SSL -> TLS all come to mind.

Not NNTP.  The NNTP RFC was published before there were any real
implementations, which is one of the reasons why it has so many flaws that
later had to be corrected in practice.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Tue, 18 Jun 2002 09:41:39 -0400
Sender: [email-masked]

> Indeed so. If some non-standardized protocol is out in the wild, and
> acquiring new features in a haphazard manner, and if it contains at least
> some features of merit, then standardizing it may well enable some control
> of the situation (e.g. by deprecating the worst features, clarifying
> intentions, resolving inconsistencies, discouraging competitive protocols,
> etc.).

and sometimes we do this.  HTTP, NNTP, SSL -> TLS all come to mind.
 
it sort of depends on how close the protocol or feature is in practice
to the behavior that is desirable.  naturally if you can make the standard
sane while still making it more-or-less compatible with existing practice,
that's very useful in getting the standard deployed without significant
transition pain.

mainly what I disagree with is the idea that *because* something is in
widespread use then it should be standardized, and the notion that widespread 
deployment of a protocol before standardization is an inherently good idea.

Keith

To: [email-masked]
Xref: clerew local.mime:1714
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Tue, 18 Jun 2002 09:31:14 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>Keith Moore <[email-masked]>
>> sounds more like: if you can't manage to do things well, standardize the 
>> stupidity and claim that you like it that way.

>Or "if you can't manage to do things well, standardize the best you can".
>"the least bad", if you wish.

Indeed so. If some non-standardized protocol is out in the wild, and
acquiring new features in a haphazard manner, and if it contains at least
some features of merit, then standardizing it may well enable some control
of the situation (e.g. by deprecating the worst features, clarifying
intentions, resolving inconsistencies, discouraging competitive protocols,
etc.).

Whether Precedence comes into this I don't know, but it is at least
arguable.

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

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Mon, 17 Jun 2002 10:39:58 -0700
Lines: 10
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> my current plan is to document the possible use of Precedence to
> suppress vacation-style autoresponses, without making it part of the
> standard.

I think that sounds like a good plan.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Keith Moore <[email-masked]>, Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Mon, 17 Jun 2002 08:32:32 -0400
Sender: [email-masked]

> Keith Moore <[email-masked]>
> > sounds more like: if you can't manage to do things well, standardize the
> > stupidity and claim that you like it that way.
> 
> Or "if you can't manage to do things well, standardize the best you can".
> "the least bad", if you wish.
> 
> I think it's safe to assume that if the document doesn't say anything
> about precedence, setting precedence will remain the best way to be
> ignored by bots, and the best-behaved bots will continue to use it.
> 
> That is, the options seem to be:
> 
>  1. Describe something better. (I'm at a loss as to what.)
>  2. Describe some relatively tasteful form of Precedence.
>  3. Silently accept the current state of things.

my current plan is to document the possible use of Precedence to suppress 
vacation-style autoresponses, without making it part of the standard.

Keith

Date: Mon, 17 Jun 2002 13:32:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Charles Lindsey <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore <[email-masked]>
> sounds more like: if you can't manage to do things well, standardize the 
> stupidity and claim that you like it that way.

Or "if you can't manage to do things well, standardize the best you can".
"the least bad", if you wish.

I think it's safe to assume that if the document doesn't say anything
about precedence, setting precedence will remain the best way to be
ignored by bots, and the best-behaved bots will continue to use it.

That is, the options seem to be:

 1. Describe something better. (I'm at a loss as to what.)
 2. Describe some relatively tasteful form of Precedence.
 3. Silently accept the current state of things.

--Arnt

To: "Eric A. Hall" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D on automatic responses
From: Florian Weimer <[email-masked]>
Mail-Followup-To: "Eric A. Hall" <[email-masked]>, [email-masked]
Date: Mon, 17 Jun 2002 11:50:01 +0200
Lines: 14
Sender: [email-masked]

"Eric A. Hall" <[email-masked]> writes:

>> Can you give me some idea of what additional content you think would be
>> useful to include in all autogenerated replies?
>
> Original-Recipient, at least. (I know you said that you think VERP is
> required for this, but the common usage is already there, and at least
> some systems conform to it).
>
> Original-Message-ID would also be particularly useful if the generic
> notifications were used for things like virus notifications.

And the Received: headers of the triggering message, to enable abuse
tracking.

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Sun, 16 Jun 2002 18:11:12 -0400
Sender: [email-masked]

> >Well, what are the specific problems with the precedence? Often knowing
> >the problem better leads to finding a solution.
> 
> >All I know about precedence is that it has bad karma. It smells of
> >unreliability. Nothing unusual for responders, that.
> 
> But if someone were to write it up as a standards track RFC that more or
> less encompassed the present usages, there would be some chance that usage
> would move in the direction of conforming to it, and other applications
> might take it up. But it is already too widely used to ignore it and hope
> it will go away. If you can't beat 'em, join 'em.

sounds more like: if you can't manage to do things well, standardize the 
stupidity and claim that you like it that way.
 
> We had a similar experience in Usefor with Mail-Copies-To. We would never
> have given it that name if starting from scratch, and we might have made
> the semantics a little different. But it was already widely deployed and
> more or less consistently used. By including it in our standard, we hoped
> to establish what seemed to be the current usage, at the same time
> officially deprecating some usages that were already around but frowned on
> in the real world.

sometimes you can do this.  but in most cases there's a fairly fundamental
conflict between trying to document existing behavior and trying to define
what behavior should be in the standard - people keep getting confused
about what they're doing.  so standardizing current practice is often a bad
idea.  not always, but often.

Keith

To: [email-masked]
Xref: clerew local.mime:1708
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Fri, 14 Jun 2002 11:36:00 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>Well, what are the specific problems with the precedence? Often knowing
>the problem better leads to finding a solution.

>All I know about precedence is that it has bad karma. It smells of
>unreliability. Nothing unusual for responders, that.

But if someone were to write it up as a standards track RFC that more or
less encompassed the present usages, there would be some chance that usage
would move in the direction of conforming to it, and other applications
might take it up. But it is already too widely used to ignore it and hope
it will go away. If you can't beat 'em, join 'em.

You might need to add to the list of keywords (junk, bulk, etc) and you
would certainly have to define what each is good for. Though I think most
of the usages in Keith's list would be legitimate.

We had a similar experience in Usefor with Mail-Copies-To. We would never
have given it that name if starting from scratch, and we might have made
the semantics a little different. But it was already widely deployed and
more or less consistently used. By including it in our standard, we hoped
to establish what seemed to be the current usage, at the same time
officially deprecating some usages that were already around but frowned on
in the real world.

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

To: [email-masked]
Xref: clerew local.mime:1707
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard
Date: Fri, 14 Jun 2002 11:25:32 GMT
Lines: 31
Sender: [email-masked]

In <[email-masked]> Keith Moore <[email-masked]> writes:

>To me the real challenges are these:

>- to discourage people from lifting a protocol extension from one protocol 
>  and placing it in another without adequate regard for the differences
>  in use cases between the two protocols

A good example is User-Agent, which we lifted from HTTP for use in Usefor.
It is similar enough that you are unlikely to notice the difference, but
they are there (e.g. HTTP has a different list of 'tspecials').

>- to get people to understand that an extension named X in protocol A isn't
>  necessarily the same as a similar extension named X in protocol B - 
>  the semantics may be slightly different, they may evolve in different ways,
>  different options and use cases may apply

Which is where Graham Klyne's IANA register of headers would be useful
(yes it has gone quiet, but I intend to get back to commenting on his
draft register RSN).

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

Date: Thu, 13 Jun 2002 14:30:38 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
To: Keith Moore <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, Keith Moore <[email-masked]>, Russ Allbery <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > but I do understand that, currently, setting precedence is probably the
> > > most effective way to get 'bots to not respond to your message.
> >
> > Well, what are the specific problems with the precedence? Often knowing
> > the problem better leads to finding a solution.

> Precedence has been overloaded for so many different things that occasionally
> they've actually conflicted with one another - so assertion of a Precedence
> field could cause your mail to bounce or fail to be delivered.

> things Precedence has been used for:

> queueing priority in sendmail
> whether to return content in nondelivery reports
> "do not respond" flag for vacation
> flag used to prevent loops among peered mailing lists
> 	(the assumption here was that Precedence is only set by lists,
> 	so if a mesage arrives at a list with Precedence set, it must
> 	have been forwarded back to the list by a subscriber of some
> 	list or another - so don't forward it back to the list because
> 	that might create a loop)
> indication of message priority gatewayed to/from other mail systems
> 	(one gateway would not forward a message if it didn't like the
> 	precedence value - fortunately this one is probably extinct)

> and probably a few more that I don't recall at the moment.

You're missing at least two:

whether or not to return delayed nondelivery reports
indication of message importance (in the X.400 sense)

The other problem is that the values used to get the various functions
vary considerably.

				Ned

From: "Dan Wing" <[email-masked]>
To: "Arnt Gulbrandsen" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: "Russ Allbery" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Thu, 13 Jun 2002 08:59:33 -0700
Importance: Normal
Sender: [email-masked]

> Keith Moore <[email-masked]>
> > not quite: a lot of 'bots aren't using it.
> 
> A lot of bots are broken and are likely to remain so ;) All your document
> does for them is specify in usable detail how they theoretically could be
> fixed. (I'm feeling pessimistic today, I guess.)

Keith's document describes best current practices -- what we can best
do today.  Defining broken things is okay, and may have a place, but
it doesn't mean those broken things should persist.  Appropriate wording
so that folks with these broken things can't point at Keith's document
and say:  "see, I'm using Precedence correctly because RFCsuch-and-so
says this is a common use of Precedence".

> > but I do understand that, currently, setting precedence is probably the
> > most effective way to get 'bots to not respond to your message.
> 
> Well, what are the specific problems with the precedence? Often knowing
> the problem better leads to finding a solution.
> 
> All I know about precedence is that it has bad karma. It smells of
> unreliability. Nothing unusual for responders, that.

:-)

-d

From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Keith Moore <[email-masked]>, Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 13 Jun 2002 08:30:56 -0400
Sender: [email-masked]

> > but I do understand that, currently, setting precedence is probably the
> > most effective way to get 'bots to not respond to your message.
> 
> Well, what are the specific problems with the precedence? Often knowing
> the problem better leads to finding a solution.

Precedence has been overloaded for so many different things that occasionally
they've actually conflicted with one another - so assertion of a Precedence
field could cause your mail to bounce or fail to be delivered.

things Precedence has been used for:

queueing priority in sendmail
whether to return content in nondelivery reports
"do not respond" flag for vacation 
flag used to prevent loops among peered mailing lists 
	(the assumption here was that Precedence is only set by lists,
	so if a mesage arrives at a list with Precedence set, it must
	have been forwarded back to the list by a subscriber of some
	list or another - so don't forward it back to the list because
	that might create a loop)
indication of message priority gatewayed to/from other mail systems 
	(one gateway would not forward a message if it didn't like the
	precedence value - fortunately this one is probably extinct)

and probably a few more that I don't recall at the moment.

Keith

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard 
Date: Thu, 13 Jun 2002 08:22:48 -0400
Sender: [email-masked]

> In this particular case we already have content-disposition in use in both
> places. Given this I think there are greater risks with trying to maintain
> separate but overlapping parameters attached to the same basic mechanism than
> there are with trying to cleanly define a single parameter that spans
> both.

To me the real challenges are these:

- to discourage people from lifting a protocol extension from one protocol 
  and placing it in another without adequate regard for the differences
  in use cases between the two protocols

- to get people to understand that an extension named X in protocol A isn't
  necessarily the same as a similar extension named X in protocol B - 
  the semantics may be slightly different, they may evolve in different ways,
  different options and use cases may apply

I'm thinking of writing Yet Another I-D titled something like:
Internet Mail, News, HTTP, and SIP are Not The Same Protocol

Keith

Date: Thu, 13 Jun 2002 14:05:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Russ Allbery <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore <[email-masked]>
> not quite: a lot of 'bots aren't using it.

A lot of bots are broken and are likely to remain so ;) All your document
does for them is specify in usable detail how they theoretically could be
fixed. (I'm feeling pessimistic today, I guess.)

> but I do understand that, currently, setting precedence is probably the
> most effective way to get 'bots to not respond to your message.

Well, what are the specific problems with the precedence? Often knowing
the problem better leads to finding a solution.

All I know about precedence is that it has bad karma. It smells of
unreliability. Nothing unusual for responders, that.

--Arnt

Date: Wed, 12 Jun 2002 22:32:04 -0700 (PDT)
From: [email-masked]
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard
To: Keith Moore <[email-masked]>
Cc: [email-masked], Keith Moore <[email-masked]>, [email-masked]
Sender: [email-masked]

> > > Since this document attempts to update the MIME content-disposition field,
> >
> > Actually it doesn't do that. That was already done in RFC 3204. All this
> > document does is to try and insure that definition is consistent across
> > multiple applications of content-disposition.

> Sigh.  IMHO it's a Bad Idea to try to extend multiple protocols with
> different semantics and use cases using something that looks like the
> same mechanism.  Content-disposition was designed for email, not SIP.
> Trying to conflate the two just invites confusion. I suppose RFC 3204
> is really to blame for this, but I don't think it's a good idea to
> try to propagate that error.

I think this very much depends on the mechanism and protocols involved.
Sometimes it makes sense, sometimes not. I definitely don't think it
should be ruled out.

In this particular case we already have content-disposition in use in both
places. Given this I think there are greater risks with trying to maintain
separate but overlapping parameters attached to the same basic mechanism than
there are with trying to cleanly define a single parameter that spans
both.

> ...

> > That's why we have IETF last calls. The document title clearly indicates that
> > it is a general MIME mechanism. Frankly, if you want to be upset about
> > something, be upset about RFC 3204, where neither the title nor the abstract
> > indicate that a parameter has been added to content-disposition.

> RFC 3204 definitely does upset me more; I just wasn't aware of it until
> reading this document.

> Actually the thing that bugs me the most (so far) is the reuse of
> Content-disposition in a SIP environment, because the entire point of
> content-disposition was to deal with the unique properties of email where
> there's no good feedback loop between sender and recipient.
> It's not the fault of this document that 3204 reused content-disposition,
> but this document seems likely to increase the confusion.

IMO not if it is done right.
> as I said in another message, I'm working on detailed comments.
> sometimes I find that I have fewer complaints once I'm done
> making a detailed pass over the document than I did on the first
> reading.  (sometimes not).

I look forward to seeing your comments.

				Ned

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Wed, 12 Jun 2002 13:19:20 -0400
Sender: [email-masked]

> > it's a good idea in general, but the last thing I want to do is
> > legitimize Precedence.  maybe there's a better way?
> 
> The problem is that while you understandably don't want to legitimize
> Precedence, it's what everyone is already using.  

not quite: a lot of 'bots aren't using it.

but I do understand that, currently, setting precedence is probably the
most effective way to get 'bots to not respond to your message.

Keith

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 12 Jun 2002 08:52:06 -0700
Lines: 13
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> it's a good idea in general, but the last thing I want to do is
> legitimize Precedence.  maybe there's a better way?

The problem is that while you understandably don't want to legitimize
Precedence, it's what everyone is already using.  So any new solution
would be significantly less useful than just using Precedence (there are a
bunch of autoresponders out there that aren't going to be upgraded any
time soon).

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Wed, 12 Jun 2002 09:00:28 -0400
Sender: [email-masked]

> Keith, could you add a paragraph specifying some way for "regular" mail to
> avoid auto-acks?  Maybe:
> 
>         Personal and Group Responders SHOULD NOT issue replies to
>         messages with Precedence: list/bulk/junk.
> 
> 

it's a good idea in general, but the last thing I want to do is legitimize
Precedence.   maybe there's a better way?

Date: Wed, 12 Jun 2002 13:45:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith, could you add a paragraph specifying some way for "regular" mail to
avoid auto-acks?  Maybe:

	Personal and Group Responders SHOULD NOT issue replies to
	messages with Precedence: list/bulk/junk.

--Arnt

To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard
From: Florian Weimer <[email-masked]>
Mail-Followup-To: Keith Moore <[email-masked]>, [email-masked]
Date: Wed, 12 Jun 2002 00:09:03 +0200
Lines: 8
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> Since this document attempts to update the MIME content-disposition field,
> not to mention the handling of DSNs, MDNs, and SIP (?!), it seems like a 
> good idea if folks on this list take a look at it.

If I read it correctly, this document requires that almost all
existing mail gateways bounce RFC 3156 messages. :-(

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard 
Date: Mon, 10 Jun 2002 15:51:44 -0400
Sender: [email-masked]

> > Since this document attempts to update the MIME content-disposition field,
> 
> Actually it doesn't do that. That was already done in RFC 3204. All this
> document does is to try and insure that definition is consistent across
> multiple applications of content-disposition.

Sigh.  IMHO it's a Bad Idea to try to extend multiple protocols with
different semantics and use cases using something that looks like the 
same mechanism.  Content-disposition was designed for email, not SIP.
Trying to conflate the two just invites confusion. I suppose RFC 3204 
is really to blame for this, but I don't think it's a good idea to
try to propagate that error.

> > Personally, I think it's a mess.
> 
> Care to be more specific? This document is about to be last called for the
> second time. It has been openly discussed in the working group on numerous
> occasions. The SIP document was last called, approved, and published some 
> time ago. I don't recall receiving a single message from you expressing 
> concern about any of this.

It had been awhile since I looked at the document.  Last time I looked at
it, I had a favorable impression of it. So I thought it was fine until I 
read the latest version just now.

> > (there's something terribly wrong if the VPIM working group can make updates
> > to mainstream email protocols without explicit review from the mainstream
> > folks)
> 
> That's why we have IETF last calls. The document title clearly indicates that
> it is a general MIME mechanism. Frankly, if you want to be upset about
> something, be upset about RFC 3204, where neither the title nor the abstract
> indicate that a parameter has been added to content-disposition.

RFC 3204 definitely does upset me more; I just wasn't aware of it until 
reading this document.  

Actually the thing that bugs me the most (so far) is the reuse of 
Content-disposition in a SIP environment, because the entire point of 
content-disposition was to deal with the unique properties of email where
there's no good feedback loop between sender and recipient.  
It's not the fault of this document that 3204 reused content-disposition, 
but this document seems likely to increase the confusion.

as I said in another message, I'm working on detailed comments.
sometimes I find that I have fewer complaints once I'm done 
making a detailed pass over the document than I did on the first 
reading.  (sometimes not).

in the meantime, it seemed like a good idea to bring this to the 
attention of other mainstream MIME folks.

Keith

Date: Mon, 10 Jun 2002 12:29:28 -0700 (PDT)
From: [email-masked]
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> Since this document attempts to update the MIME content-disposition field,

Actually it doesn't do that. That was already done in RFC 3204. All this
document does is to try and insure that definition is consistent across
multiple applications of content-disposition.

> not to mention the handling of DSNs, MDNs, and SIP (?!), it seems like a
> good idea if folks on this list take a look at it.

Seems reasonable to me.

> Personally, I think it's a mess.

Care to be more specific? This document is about to be last called for the
second time. It has been openly discussed in the working group on numerous
occasions. The SIP document was last called, approved, and published some time
ago. I don't recall receiving a single message from you expressing concern
about any of this.

> (there's something terribly wrong if the VPIM working group can make updates
> to mainstream email protocols without explicit review from the mainstream
> folks)

That's why we have IETF last calls. The document title clearly indicates that
it is a general MIME mechanism. Frankly, if you want to be upset about
something, be upset about RFC 3204, where neither the title nor the abstract
indicate that a parameter has been added to content-disposition.

				Ned

From: Keith Moore <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard 
Date: Mon, 10 Jun 2002 15:35:44 -0400
Sender: [email-masked]

> >Personally, I think it's a mess.
> 
> Care to elaborate on this? 

That's just a first reaction.  I'm working on detailed comments.

> Uh...what makes you think it's not getting explicit review? 

there are so many Last Calls that it's easy for something to get lost.
and there can be a difference between putting out a general Last Call 
and asking a particular group of people to look at the document.

of course, that is why I forwarded the LC message to this list.

Keith

Date: Mon, 10 Jun 2002 14:29:07 -0500
To: Keith Moore <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard
Cc: [email-masked]
Sender: [email-masked]

On 6/10/02 at 3:13 PM -0400, Keith Moore wrote:

>Personally, I think it's a mess.

Care to elaborate on this? I've been at least peeking in on this work 
and it seems relatively innocuous to me: Most MUAs will ignore this 
stuff, and it provides a piece of information to a specialized set of 
gateways and MUAs. What's the problem?

>(there's something terribly wrong if the VPIM working group can make 
>updates to mainstream email protocols without explicit review from 
>the mainstream folks)

Uh...what makes you think it's not getting explicit review? It got a 
last call. VPIM is no big secret.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Subject: [fwd] Last Call: Critical Content MIME Parameter to Proposed Standard
Date: Mon, 10 Jun 2002 15:13:47 -0400
From: Keith Moore <[email-masked]>
Sender: [email-masked]

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>

Since this document attempts to update the MIME content-disposition field,
not to mention the handling of DSNs, MDNs, and SIP (?!), it seems like a 
good idea if folks on this list take a look at it.

Personally, I think it's a mess.

(there's something terribly wrong if the VPIM working group can make updates
to mainstream email protocols without explicit review from the mainstream
folks)

Keith

------- =_aaaaaaaaaa0
Content-Type: message/rfc822
Content-ID: <[email-masked]>
Content-Description: forwarded message

Delivery-Date: Mon, 10 Jun 2002 14:06:54 -0400
To: IETF-Announce:;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Critical Content MIME Parameter to Proposed 
	   Standard
Reply-to: [email-masked]
Date: Mon, 10 Jun 2002 13:35:14 -0400
Sender: [email-masked]

The IESG has received a request from the Voice Profile for Internet 
Mail Working Group to consider Critical Content MIME Parameter 
<draft-ietf-vpim-cc-07.txt> as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
[email-masked] or [email-masked] mailing lists by June 24, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-vpim-cc-07.txt

------- =_aaaaaaaaaa0--

Date: Sun, 09 Jun 2002 23:45:26 -0400
From: Tony Hansen <[email-masked]>
To: Charles Lindsey <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Call me a pedant, but I did some more digging. The root word in latin is 
"res"; "re" is the ablative (relational) form. The word itself means 
"thing". The phrase "in re" means "in the matter of". Evidently the 
legal beagles have been using the phrase "in re" for a long time.

RFC 2822 says "res". The word is correct, but the definition is slightly 
incorrect. From 2822, section 3.6.5:

    When used in a reply, the field body MAY start with the string
    "Re: " (from the Latin "res", in the matter of) followed by the
    contents of the "Subject:" field body of the original message.

Usefor says re is from "in re", then uses the same definition as above. 
 From section 5.4:

    NOTE: "Re" is an abbreviation for the Latin "In re", meaning "in
    the matter of", and not an abbreviation of "Reference" as is
    sometimes erroneously supposed.

Note though, that re is NOT an abbreviation, but is just a shortend form.

A better description of "Re" would be:

     "Re" is the ablative (relational) case for the latin word "res"
     meaning "thing", often used in the phrase "in re", meaning "in the
     matter of". It is not an abbreviation for "Reference", "Reply" or
     "Response", as is sometimes erroneously supposed.

BTW, I'm leaning towards "Auto:" as the best prefix.

	Tony Hansen
	[email-masked]

Charles Lindsey wrote:
> In <[email-masked]> "Dan Kohn" <[email-masked]> writes:
> 
>>I would instead recommend:
> 
>>NOTE: The string "Re: " (from the Latin "res", in the matter of) in the
>                                           ^^^
> Actually, it it from the Latin "in re".
> 
> There are texts on this in both RFC 2822 and in the Usefor draft. These
> might be useful here.

From: Keith Moore <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail - Auto-Re: 
Date: Sun, 09 Jun 2002 19:10:25 -0400
Sender: [email-masked]

I like Auto: better also.

-Keith

To: [email-masked]
Xref: clerew local.mime:1685
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Sat, 8 Jun 2002 20:19:58 GMT
Lines: 22
Sender: [email-masked]

In <[email-masked]> "Dan Kohn" <[email-masked]> writes:

>I would instead recommend:

>NOTE: The string "Re: " (from the Latin "res", in the matter of) in the
                                          ^^^
Actually, it it from the Latin "in re".

There are texts on this in both RFC 2822 and in the Usefor draft. These
might be useful here.

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

From: [email-masked] (Andrew Church)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: authenticating the source of mail
Date: Sun, 09 Jun 2002 04:05:50 JST
Sender: [email-masked]

     On the MS record issue: would it be more workable to add a record
with some sort of authentication information, and have the receiving SMTP
server force the sending side to authenticate itself if such a record
existed?  It seems to me this would solve the concerns about limiting
sender IPs and changing hostnames without introducing any new problems.  (I
think there's something else--DNSSEC?--that uses a similar system, but it's
4am and I can't bring it to mind at the moment.)

  --Andrew Church
    [email-masked]
    http://achurch.org/

Date: Sat, 8 Jun 2002 16:54:30 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Russ Allbery <[email-masked]>
> Requiring that an autoresponder handle RFC 2047 decoding and MIME
> disassembly and reassembly of the original message is a pretty hefty
> requirement for a poor little autoresponder.

An e-mail responder which sees a 2047-encoded header field has three
possibilities:

 1. Don't include that header field in the reply's body.
 2. Include it properly decoded.
 3. Include it in raw form.

IMO it's reasonable for forbid option 3. That mandates detection of
2047/mime, but it makes decoding and encoding optional.

> And it really isn't the end of the world if a Subject line shows up in the
> body of the text RFC 2047 encoded.

It also isn't the end of the world to leave the subject line out if it
can't be shown in a human-readable format. IMO it's better to say nothing
than to say =?big5?b?637826478367487647682132637836363?=.

--Arnt

Date: Sat, 8 Jun 2002 17:02:53 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail - Auto-Re:
Sender: [email-masked]

Bart Schaefer <[email-masked]>
> On Thu, 6 Jun 2002, Tony Hansen wrote:
> 
> > Is anyone else bothered by "Auto-Re" being mixed Greek and Latin?

(Yes.)

> > Anyone else care? Anyone have better suggestions?
> 
> Shorter is generally better.  Given that this is a newly invented
> convention anyway, how about just "Auto:"?

Wild guess 1: "Auto:" has the additional benefit that more current-day
MUAs might see it as a "Re:"-like prefix, since it matches "^[a-zA-Z]*:".

Wild guess 2: "Auto" is loaned into many languages, so there'll be less
pressure to translate the word than there's been for "Re:".

--Arnt

Date: Fri, 07 Jun 2002 12:25:06 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore wrote:

> I'm afraid there are at least as many exceptions to these as in the
> current taxonomy. 

such as...

> That, and your set of categories doesn't cover
> all bases, and it also overlaps.

Agree that it doesn't cover all of the bases (nothing can do that;
app-specific rules like mailing list posts and file-robot dumps are
app-specific and not generic responses).

I'm not sure I see where it overlaps.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Dan Kohn" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 13:18:08 -0400
Sender: [email-masked]

> They are commercial reasons.  In exchange for a free account, Hotmail wants 
> some branding.  But they are willing to let you get replies to a different account.

The IETF is not obligated to endorse hotmail's business model.

Keith

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 13:12:19 -0400
Sender: [email-masked]

> It makes defining generic rules simpler, in that you don't have to provide
> escape-clauses for every rule. EG:
> 
> notifications:
> 
>   should use <> as the reverse-path
> 
> confirmation:
> 
>   must use the process mailbox as the reverse-path, to trap malformed
>   confirmation targets
> 
> thank-you:
> 
>   may use any mailbox address in the reverse-path

I'm afraid there are at least as many exceptions to these as in the
current taxonomy.  That, and your set of categories doesn't cover
all bases, and it also overlaps.

Keith

content-class: urn:content-classes:message
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Fri, 7 Jun 2002 10:10:57 -0700
From: "Dan Kohn" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

They are commercial reasons.  In exchange for a free account, Hotmail wants some branding.  But they are willing to let you get replies to a different account.

	-----Original Message----- 
	From: Keith Moore [mailto:[email-masked]] 
	Sent: Fri 2002-06-07 9:08 
	To: Dan Kohn 
	Cc: [email-masked] 
	Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 

	> Hotmail falls under this category, for basically understandable reasons.
	
	well, hotmail does seem fundamentally broken to me, in several ways,
	so I guess my initial assessment is confirmed.
	
	what are the "basically understandable reasons" for hotmail not allowing
	From to be set?

Date: Fri, 07 Jun 2002 11:54:51 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore wrote:

> I don't see how your proposed taxonomy helps.

It makes defining generic rules simpler, in that you don't have to provide
escape-clauses for every rule. EG:

notifications:

  should use <> as the reverse-path

confirmation:

  must use the process mailbox as the reverse-path, to trap malformed
  confirmation targets

thank-you:

  may use any mailbox address in the reverse-path

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 12:13:29 -0400
Sender: [email-masked]

> I've been thinking about the taxonomy. I'm wondering if it would be more
> useful to describe automated messages in terms of:

I don't see how your proposed taxonomy helps.  as far as I can tell,
sender expectations (e.g. did the sender set reply-to anticipating
that a human would respond?) and whether the responder configuration
is under control of the recipient (i.e. who is responsible for 
maintaining this responder?) should govern the responder's behavior,
not the nature of the content in the response.

Keith

From: Keith Moore <[email-masked]>
To: "Dan Kohn" <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 12:08:46 -0400
Sender: [email-masked]

> Hotmail falls under this category, for basically understandable reasons.

well, hotmail does seem fundamentally broken to me, in several ways,
so I guess my initial assessment is confirmed.

what are the "basically understandable reasons" for hotmail not allowing
>From to be set?

From: Keith Moore <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail - Auto-Re: 
Date: Fri, 07 Jun 2002 12:06:54 -0400
Sender: [email-masked]

> Is anyone else bothered by "Auto-Re" being mixed Greek and Latin?

yes, this actually does bother me.  but I don't know enough of either
Latin or Greek to know what might be better.

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 12:03:42 -0400
Sender: [email-masked]

> > again, the goal here is to avoid being used to transmit spam or viruses.
> 
> Given that DSNs can already be used for this purpose (you almost always
> want to include the entire original message in a bounce because otherwise
> it may be lost), are we really gaining much by preventing autoresponders
> from being used for that?

two things:

1. autoresponders are inherently more varied than DSNs.  DSNs specify 
with a fair degree of precision the format of the response, and the 
conditions under which it gets sent.  

2. the world has changed a bit since the DSN spec was written.  if the
DSN spec were being written today I might want a similar provision
for limiting the amount of content returned.  and it wouldn't
bother me for the revised DSN spec to say that DSNs should somehow limit
the amount of the subject message that is returned.

> This strikes me as a flaw inherent in the nature of e-mail bounces.
> 
> > I once got called in as a consultant for a bank that was using a piece
> > of software, whose auto-responder would respond with only a brief
> > annotation, and include the entire subject message in the response.  (it
> > also copied everyone in the to and cc fields)
> 
> Copying everyone in the To and Cc fields is obviously wrong.

There were so many things wrong with that setup that fixing only one or
two of them would not have solved the problem.

Keith

Date: Fri, 07 Jun 2002 10:58:18 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore wrote:

> draft-moore-auto-email-response-00.txt

I've been thinking about the taxonomy. I'm wondering if it would be more
useful to describe automated messages in terms of:

  notifications -- informs of issues related to transfer, delivery and
     processing, such as hotword rejections, virus alerts, vacation,
     and so forth

  confirmations -- informs of intermediate success and requests 
     additional information, such as file-robot and mailing list
     confirmation messages

  thank-you -- informs of successful processing, requires no additional
     input or processing

we can describe the various return addressing rules, structure and so
forth in the context of the type. "thank-you messages and their replies
can be freely discarded" for example.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 11:54:33 -0400
Sender: [email-masked]

> > well, I have often seen people trying to reply to service responders.
> 
> You'll get that with Auto-Re as well.

sure, but will Auto-Re minimize it?  or is it enough of a problem to worry
about?

I'm happy to drop Auto-Re if nobody else thinks it's useful.

Keith

From: Keith Moore <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Fri, 07 Jun 2002 11:30:36 -0400
Sender: [email-masked]

> > > Doing so directly
> > > sanctions the sort of behaviour that has created the need for this
> > > document to begin with.
> >
> > that's a silly statement.  it's one thing to insist that mail responders
> > minimize potential harm, quite another to insist that they use one
> > particular mechanism which is known to not work adequately in practice.
> 
> Why doesn't it work? Because people have caved in to those who violate
> the standard. If those people (the violators) will let their ignorance
> turn <> into something useless, how could you possibly think they
> won't do the same to any other facility we come up with? 

<> is less useful than it should be because people hate spam so much
that they'll try anything to stop it, including blocking mail from <>.
yes, this is ignorant.  but there's a lot of ignorance out there.

however, I don't imagine that there will be nearly as much pressure
to abuse the mechanisms we define for mail autoresponders. 

> This isn't a silly issue, it's a practical one. 

Indeed.  Under current circumstances it's impractical to insist that
autoresponders use <> for a return-path.  

> And it's symptomatic of the
> prevailing attitude that has led us to be in the situation we are in
> today. 

on the contrary, people are refusing mail from <> despite what the
standards say, not because the standards permit this.  

> Now you can write the most wonderful ID imaginable, but if we
> chose to not enforce it in the way we've not enforced other aspects of
> the protocol, we'll simply be having this conversation all over again
> in a couple of years.

no, "we" won't be having this conversation, because I won't consider
it worth my time.  standards are only valuable if they make useful
recommendations that work in practice. if you think we can "enforce" 
anything, you're seriously deluded.

I don't see any need to debate this subject further.

Keith

Date: Fri, 7 Jun 2002 11:04:13 -0400
From: Lawrence Greenfield <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

   Date: Thu, 06 Jun 2002 16:17:13 -0500
   From: "Eric A. Hall" <[email-masked]>

   Lawrence Greenfield wrote:

   > Some people actually want to know if their auto-response message got
   > bounced.  (I'm not sure what they do with that information, but I've
   > heard the request.)

   They add them to blacklists: http://www.rfc-ignorant.org/policy-dsn.html

No, this isn't it at all.  There are cases when legitimate addresses
will bounce auto-responses.  One obvious one is when the user is over
quota.  (I think this is the case that our help center is most
interested in---but in general, they want to know if their auto-reply
wasn't received by the user if possible.)

Larry

content-class: urn:content-classes:message
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 6 Jun 2002 22:30:26 -0700
From: "Dan Kohn" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Keith said:

>A UA that
>can't set From but can set Reply-To just seems fundamentally
>broken to me, though I'll grant that RFC 822 never said 
>"UAs MUST allow users to set the From field".

Hotmail falls under this category, for basically understandable reasons.

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

Date: Thu, 6 Jun 2002 20:19:51 -0700 (PDT)
From: Bart Schaefer <[email-masked]>
To: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail - Auto-Re:
Sender: [email-masked]

On Thu, 6 Jun 2002, Tony Hansen wrote:

> Is anyone else bothered by "Auto-Re" being mixed Greek and Latin?

"Auto-Submitted" is mixed Greek and Latin, too, for that matter.  I don't
think any English speaker, particularly American English, can legitimately
get very worked up about the mixing of root languages.

> Anyone else care? Anyone have better suggestions?

Shorter is generally better.  Given that this is a newly invented
convention anyway, how about just "Auto:"?

From: "Dan Wing" <[email-masked]>
To: "Russ Allbery" <[email-masked]>, <[email-masked]>
Subject: RE: I-D  Recommendations for Automatic Responses to Electronic Mail
Date: Thu, 6 Jun 2002 19:58:04 -0700
Importance: Normal
Sender: [email-masked]

> > Section 2.2 says:
> 
> >     Response messages SHOULD NOT include significant content from the
> >     subject message.  In particular responses SHOULD NOT contain
> >     non-text/plain attachments from the subject message.
> 
> > This requires further discussion in the I-D.  For example, if the
> > subject message contains only text/html, what's the autoresponder
> > supposed to do (I would advise not including any portion of the
> > message).
> 
> > By the way, I have noticed some autoresponders don't decode
> > RFC2047-encoded subject lines correctly when they include the Subject of
> > the "subject message" in the body of the response.  It might be good to
> > point out RFC2047-encoded Subjects as a case that needs to be properly
> > handled by autoresponders.
> 
> Requiring that an autoresponder handle RFC 2047 decoding and MIME
> disassembly and reassembly of the original message is a pretty hefty
> requirement for a poor little autoresponder.  That's probably an order of
> magnitude complexity above what a lot of autoresponders are now, for what
> seems to me to be a fairly minimal gain.

Agreed; the simple solution is that an autoresponder shouldn't try
to put the contents of the original message's Subject into the body
of the response.  Using the original Subject in the Subject of the
response works without any problems (as it'll still be RFC2047-
encoded).

> Bounces already routinely include the entire original message for good
> reason, since otherwise it might be lost.  I'm not sure this is actually
> preventing any attack which isn't just as easy to perform another way.

I wasn't suggesting that autoresponders send the entire message back
to the originator - I was only commenting that Keith should include
a reminder that RFC2047-encoded subjects exist (especially outside
languages using the US-ASCII charset), and autoresponders need to 
handle RFC2047-encoded subjects properly (by the methods I described
above).

> And it really isn't the end of the world if a Subject line shows up in the
> body of the text RFC 2047 encoded. 

Yeah, well, I haven't yet encountered a discussion in the IETF which
causes the end of the world!

But showing users RFC2047-encoded junk is akin to showing users
Quoted-Printable, and I think we're all well aware of how much users
enjoy seeing "=" at the end of lines and other QP cruft.  Implementors
need a reminder of RFC2047, is all I'm saying.

> Note that trying to include the
> decoded form in free-form text may require a MIME multipart to set a
> different character set from the rest of the surrounding message, which is
> approaching a rather excessive degree of complexity.
> 
> If the Subject is included as part of the headers of the message in a
> message/rfc822 or equivalent attachment, there's no need to decode the
> Subject header, which is a reasonable argument in favor of using
> multipart/report.

Using multipart/report for 'vacation'-like autoresponders is 
arguably a Best _Future_ Practice, but isn't a Best _Current_ 
Practice.

I'd like to get things to conform to best current practice -- which
they don't today -- and then move on to more optimal solutions.

-d

Date: Thu, 06 Jun 2002 22:16:31 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail - Auto-Re:
Sender: [email-masked]

Is anyone else bothered by "Auto-Re" being mixed Greek and Latin?

Re comes from the latin res, for "in the matter of".

Auto is greek for "self". Besides being greek, this doesn't seem to be 
quite the correct prefix.

The closest latin possibilities I could come up with were:

	"mech-re"	("mechanical, in the matter of")
	"sponte-re"	("automatically in the matter of")
	"ipse-re"	(ok, ok, "self, in the matter of")

Anyone else care? Anyone have better suggestions?

	Tony Hansen
	[email-masked]

Date: Thu, 06 Jun 2002 16:17:13 -0500
From: "Eric A. Hall" <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
CC: Keith Moore <[email-masked]>, Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Lawrence Greenfield wrote:

> Some people actually want to know if their auto-response message got
> bounced.  (I'm not sure what they do with that information, but I've
> heard the request.)

They add them to blacklists: http://www.rfc-ignorant.org/policy-dsn.html

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Thu, 6 Jun 2002 16:32:17 -0400
From: Lawrence Greenfield <[email-masked]>
To: Keith Moore <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Sender: [email-masked]

   Date: Thu, 06 Jun 2002 13:38:33 -0600
   From: Lyndon Nerenberg <[email-masked]>
[...]
   I cannot agree with relaxing the <> requirement. Doing so directly
   sanctions the sort of behaviour that has created the need for this
   document to begin with.

Some people actually want to know if their auto-response message got
bounced.  (I'm not sure what they do with that information, but I've
heard the request.)

Larry

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 06 Jun 2002 13:17:04 -0700
Lines: 17
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> What is the problem this is trying to solve?  I've yet to talk to
>> anyone who was confused about the sort of response they've gotten.

> well, I have often seen people trying to reply to service responders.

You'll get that with Auto-Re as well.

I don't have a strong opinion other than to say that I guarantee that
people who implement Auto-Re will eventually end up dealing with messages
whose subjects start with stuff like:

    Re: Auto-Re: Re: Auto-Re: Re: Auto-Re: hi!

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 06 Jun 2002 13:15:57 -0700
Lines: 23
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> Also, the SHOULD use "in-reply-to" and MAY use "References" is silly.
>> In-Reply-To fields are enormously varied and hard to parse;
>> "References" fields are much better.  We should definitely encourage
>> people to support References over In-Reply-To.

> Seems like in-reply-to is more widely supported, though.  I'm curious to
> hear what other people think about this.  It wouldn't bother me too much
> to make both of them SHOULD.

References is definitely more widely supported than In-Reply-To for actual
practical purposes.  Many, if not most, In-Reply-To headers contain so
much unstructured, extraneous information that they're essentially only
informational to humans and cannot be effectively used by software.
References has never had this problem, and is therefore clearly superior
technically.

I wholeheartedly agree that we should be recommending References over
In-Reply-To at every opportunity.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 06 Jun 2002 13:12:57 -0700
Lines: 42
Sender: [email-masked]

Dan Wing <[email-masked]> writes:

> Section 2.2 says:

>     Response messages SHOULD NOT include significant content from the
>     subject message.  In particular responses SHOULD NOT contain
>     non-text/plain attachments from the subject message.

> This requires further discussion in the I-D.  For example, if the
> subject message contains only text/html, what's the autoresponder
> supposed to do (I would advise not including any portion of the
> message).

> By the way, I have noticed some autoresponders don't decode
> RFC2047-encoded subject lines correctly when they include the Subject of
> the "subject message" in the body of the response.  It might be good to
> point out RFC2047-encoded Subjects as a case that needs to be properly
> handled by autoresponders.

Requiring that an autoresponder handle RFC 2047 decoding and MIME
disassembly and reassembly of the original message is a pretty hefty
requirement for a poor little autoresponder.  That's probably an order of
magnitude complexity above what a lot of autoresponders are now, for what
seems to me to be a fairly minimal gain.

Bounces already routinely include the entire original message for good
reason, since otherwise it might be lost.  I'm not sure this is actually
preventing any attack which isn't just as easy to perform another way.

And it really isn't the end of the world if a Subject line shows up in the
body of the text RFC 2047 encoded.  Note that trying to include the
decoded form in free-form text may require a MIME multipart to set a
different character set from the rest of the surrounding message, which is
approaching a rather excessive degree of complexity.

If the Subject is included as part of the headers of the message in a
message/rfc822 or equivalent attachment, there's no need to decode the
Subject header, which is a reasonable argument in favor of using
multipart/report.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Thu, 06 Jun 2002 15:08:57 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore wrote:

> > Doing so directly
> > sanctions the sort of behaviour that has created the need for this
> > document to begin with.
> 
> that's a silly statement.  it's one thing to insist that mail responders
> minimize potential harm, quite another to insist that they use one
> particular mechanism which is known to not work adequately in practice.

Two wrongs, and all of that.

The kind of people who reject <> are not going to comply with this
specification anyway. They're neither the intended nor expected audience.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 06 Jun 2002 13:06:55 -0700
Lines: 29
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> one reason I didn't just insist that MAIL FROM be <> is that too many
> mailers categorically reject MAIL FROM:<>.  yes, they're broken, but
> there's so much of this kind of brokenness in the world that a feature
> that depends on it not being broken is doomed to failure...

> there are also things that rewrite <> to MAILER-DAEMON or some such,
> presumably because mailers don't accept <>.

The other reason not to use <> is because if you use <>, the mail system
will generally believe that the message is a bounce, and if it then
bounces itself, it will send the message to the local postmaster as a
double-bounce.  Even worse, if the message is relayed through other hosts
before it bounces, it will often end up in the postmaster box of some
random mail system not run by the same person as the autoresponder.

For many autoresponders, no one cares or wants to know if the autoresponse
bounces; they want that bounce to silently disappear.

Now, one can send autoresponses from a system specially configured to
discard double-bounces, but one doesn't always have that degree of freedom
to bring up a separate system for ones autoresponder needs.

I use nobody@<host>.stanford.edu as an envelope sender for autoreplies,
generally, where nobody is configured to silently discard all mail.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Organization: ACI Worldwide - Advanced Technology Group
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 14:04:24 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> > Doing so directly 
> > sanctions the sort of behaviour that has created the need for this 
> > document to begin with.
> 
> that's a silly statement.  it's one thing to insist that mail responders
> minimize potential harm, quite another to insist that they use one 
> particular mechanism which is known to not work adequately in practice.

Why doesn't it work? Because people have caved in to those who violate
the standard. If those people (the violators) will let their ignorance
turn <> into something useless, how could you possibly think they
won't do the same to any other facility we come up with? This isn't a
silly issue, it's a practical one. And it's symptomatic of the
prevailing attitude that has led us to be in the situation we are in
today. Now you can write the most wonderful ID imaginable, but if we
chose to not enforce it in the way we've not enforced other aspects of
the protocol, we'll simply be having this conversation all over again
in a couple of years. 

--lyndon

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Thu, 06 Jun 2002 13:01:22 -0700
Lines: 20
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> again, the goal here is to avoid being used to transmit spam or viruses.

Given that DSNs can already be used for this purpose (you almost always
want to include the entire original message in a bounce because otherwise
it may be lost), are we really gaining much by preventing autoresponders
from being used for that?

This strikes me as a flaw inherent in the nature of e-mail bounces.

> I once got called in as a consultant for a bank that was using a piece
> of software, whose auto-responder would respond with only a brief
> annotation, and include the entire subject message in the response.  (it
> also copied everyone in the to and cc fields)

Copying everyone in the To and Cc fields is obviously wrong.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 15:46:24 -0400
Sender: [email-masked]

> > one reason I didn't just insist that MAIL FROM be <>  is that too
> > many mailers categorically reject MAIL FROM:<>.  yes, they're broken,
> > but there's so much of this kind of brokenness in the world that a
> > feature that depends on it not being broken is doomed to failure...
> 
> Is that really the case today? 

as far as I can tell, it's getting worse.  I see this literally every 
day.  (well, every day that I read postmaster mail, which is most days)

> I cannot agree with relaxing the <> requirement. 

well, I can't agree with insisting on it.

> Doing so directly 
> sanctions the sort of behaviour that has created the need for this 
> document to begin with.

that's a silly statement.  it's one thing to insist that mail responders
minimize potential harm, quite another to insist that they use one 
particular mechanism which is known to not work adequately in practice.

Keith

Organization: ACI Worldwide - Advanced Technology Group
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 13:38:33 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> one reason I didn't just insist that MAIL FROM be <>  is that too
> many mailers categorically reject MAIL FROM:<>.  yes, they're broken,
> but there's so much of this kind of brokenness in the world that a 
> feature that depends on it not being broken is doomed to failure...

Is that really the case today? A year ago I still used to run into a
lot of this, but it really seems to have dried up since then.  I
suspect what happened is the clueless people who implemented the
broken policies ended up self-selecting themselves out of business.

I cannot agree with relaxing the <> requirement. Doing so directly
sanctions the sort of behaviour that has created the need for this
document to begin with.

--lyndon

From: Keith Moore <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 15:28:13 -0400
Sender: [email-masked]

> What is the problem this is trying to solve?  I've yet to talk to
> anyone who was confused about the sort of response they've gotten.

well, I have often seen people trying to reply to service responders.

Keith

Date: Thu, 6 Jun 2002 15:10:58 -0400
From: Lawrence Greenfield <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Sender: [email-masked]

   From: Keith Moore <[email-masked]>
   Date: Thu, 06 Jun 2002 14:59:49 -0400
[...]
   okay, which part of the idea is horrible:

   - trying to provide a uniform, visible indication for human users of 
     existing mail clients that this message is an automatic response, or

What is the problem this is trying to solve?  I've yet to talk to
anyone who was confused about the sort of response they've gotten.

Larry

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 6 Jun 2002 12:02:28 -0700
Importance: Normal
Sender: [email-masked]

> that's the nice thing about just prepending "Auto-Re: " - there's no need
> for a user agent that just does that to do any parsing or decoding
> of encoded-words.  

Agreed.  Some text explaining that benefit of auto-re would
be helpful to guide implementors into using auto-re.

-d

From: Keith Moore <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked], Keith Moore <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 14:59:49 -0400
Sender: [email-masked]

> I think "Auto-Re" is a horrible idea.  It isn't supported by current
> e-mail clients for localization, nor with they strip it out when they
> generate replies.  It isn't supported by current e-mail processing
> software, and it's encoding distinction between automatic replies and
> manual ones that's already encoded in the "Auto-submitted" header.
> 
> I couldn't see our help center using it in replies to users to our
> help address (trouble-ticket system) and I don't see other sites using
> it either.  It's biggest impact would be to make message displays more
> ugly.

okay, which part of the idea is horrible:

- trying to provide a uniform, visible indication for human users of 
  existing mail clients that this message is an automatic response, or

- the specific string Auto-Re:

I'm not entirely happy with Auto-Re, but it seemed better to have
some uniform kind of visibile indication than to have none.  

> Also, the SHOULD use "in-reply-to" and MAY use "References" is silly.
> In-Reply-To fields are enormously varied and hard to parse;
> "References" fields are much better.  We should definitely encourage
> people to support References over In-Reply-To.

Seems like in-reply-to is more widely supported, though.
I'm curious to hear what other people think about this.
It wouldn't bother me too much to make both of them SHOULD. 

Keith

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 14:55:11 -0400
Sender: [email-masked]

> > Dan,
> >
> > thanks for your comments. I agree with most of them.
> >
> > > In 1.1, the description of Group Responders should include an
> > > example of a service address ([email-masked]), which you
> > > mentioned in some email threads but isn't described directly
> > > here in the I-D itself.  The virus scanner is one example,
> > > but the autoresponder for service addresses is a better (and
> > > more common) example.
> >
> > I'm not sure what you mean here.  How is an autoresponder for
> > service addresses an example of a Group Responder, unless
> > it answers on behalf of several different recipients in a
> > way over which those recipients don't have control?
> >
> > (or do I need to tweak my definition of Group Repsonder?
> > IMHO, recipient control over the response is the primary
> > thing that distinguishes Group from Personal responses)
> 
> My employer, and many others, have both externally-visible
> addresses which run scripts that assign a case number
> to your email and usually attempt to route the message (based
> on its content or key words) into a problem-tracking system
> or routes the message via email to groups of technical-
> support or product-information specialists.  For example,
> if you email Canon and include in the message body the word
> Camera, your email will be routed to product-information
> specialists who know Canon's photography products.  Instead,
> if you had included the word "copier", your message would
> have been routed differently.
> 
> In both cases, however, you send your message to [email-masked]
> and receive back one message indicating a tracking number,
> a phone number you can call to check on your question (if so
> desired), and an indication that 'your message has been routed
> to the appropriate group to respond to your question'.
> 
> Many companys utilize autoresponders for their support@
> and info@ addresses.
> 
> The recipients of the messages (which are routed and forwarded
> by the autoresponders, typically with the tracking number
> now included in the Subject line for easy coorelation by
> the same autoresponder software), have no control over the
> autoresponder -- thus, it's a "Group Autoresponder" per your
> definition.

it sounds like I do need to tweak my definition then -
this kind of autoresponder is apparently not intercepting
mail that was addressed to large numbers of people
at the company, it's taking mail that was sent to specific
addresses and forwarding it to people at the company.

so I need to figure out where it best fits into the taxonomy
 
> I'm only asking that you include an example of the above in
> addition to your virus-scanner example.

it sounds reasonable to include this as an example, though
perhaps not of a Group Responder.  maybe it's better treated
as something else.

> and your autoresponder responds with:
> 
>   Return-Path: <[email-masked]>
>   To: [email-masked]
>   From: [email-masked]
>   Subject: Keith is out of the office
>   auto-submitted: auto-replied
> 
>   Keith has received your message with subject:
>     =?encoded-word?=
>   and will read it when he returns.
 
oh that.  yes, I agree that these need to be decoded.

>   <END OF MESSAGE>
> 
> when it should do something different with the Subject -- either it needs to use
> the same charset as the RFC2047-encoded subject (unlikely), or it should omit
> the Subject entirely if the Subject's charset isn't the same charset as the
> autoreply.

that's the nice thing about just prepending "Auto-Re: " - there's no need
for a user agent that just does that to do any parsing or decoding
of encoded-words.  

> > > Section 3 says:
> > >
> > >     An automatic responder MUST NOT send a response
> > >     for every message received.
> > >
> > > This requirement will break all mailing list software
> > > (majordomo, LISTSERV, etc.), as they're supposed to
> > > send a response for every message received.
> >
> > are they really supposed to send a response to spam or viruses?
> > that's why I say that in practice every responder needs some
> > filtering to make sure the input is valid.
> 
> Then:
> 
>     An automatic responder MUST include mechanisms which
>     prevent or reduce the effects of responding to malicious
>     use or spam.  Such mechanisms ard described in this
>     section.

maybe.  I still think it's valid to say that all responders need 
to decide whether to respond - it's just something you need to 
think about when you're writing a responder.  but it could certanly
use some clarification.
 
Keith

Date: Thu, 6 Jun 2002 14:48:22 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Keith Moore <[email-masked]>
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

I think "Auto-Re" is a horrible idea.  It isn't supported by current
e-mail clients for localization, nor with they strip it out when they
generate replies.  It isn't supported by current e-mail processing
software, and it's encoding distinction between automatic replies and
manual ones that's already encoded in the "Auto-submitted" header.

I couldn't see our help center using it in replies to users to our
help address (trouble-ticket system) and I don't see other sites using
it either.  It's biggest impact would be to make message displays more
ugly.

Also, the SHOULD use "in-reply-to" and MAY use "References" is silly.
In-Reply-To fields are enormously varied and hard to parse;
"References" fields are much better.  We should definitely encourage
people to support References over In-Reply-To.

Larry

From: "Dan Wing" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 6 Jun 2002 11:21:50 -0700
Importance: Normal
Sender: [email-masked]

> Dan,
>
> thanks for your comments. I agree with most of them.
>
> > In 1.1, the description of Group Responders should include an
> > example of a service address ([email-masked]), which you
> > mentioned in some email threads but isn't described directly
> > here in the I-D itself.  The virus scanner is one example,
> > but the autoresponder for service addresses is a better (and
> > more common) example.
>
> I'm not sure what you mean here.  How is an autoresponder for
> service addresses an example of a Group Responder, unless
> it answers on behalf of several different recipients in a
> way over which those recipients don't have control?
>
> (or do I need to tweak my definition of Group Repsonder?
> IMHO, recipient control over the response is the primary
> thing that distinguishes Group from Personal responses)

My employer, and many others, have both externally-visible
addresses which run scripts that assign a case number
to your email and usually attempt to route the message (based
on its content or key words) into a problem-tracking system
or routes the message via email to groups of technical-
support or product-information specialists.  For example,
if you email Canon and include in the message body the word
Camera, your email will be routed to product-information
specialists who know Canon's photography products.  Instead,
if you had included the word "copier", your message would
have been routed differently.

In both cases, however, you send your message to [email-masked]
and receive back one message indicating a tracking number,
a phone number you can call to check on your question (if so
desired), and an indication that 'your message has been routed
to the appropriate group to respond to your question'.

Many companys utilize autoresponders for their support@
and info@ addresses.

The recipients of the messages (which are routed and forwarded
by the autoresponders, typically with the tracking number
now included in the Subject line for easy coorelation by
the same autoresponder software), have no control over the
autoresponder -- thus, it's a "Group Autoresponder" per your
definition.

I'm only asking that you include an example of the above in
addition to your virus-scanner example.

> > Section 2.2 mentions multipart/alternative for multi-language
> > response, but also says multiple charsets?
>
> multiple language often requires multiple charsets, at least until
> the whole world adopts UTF-8 (I'm not holding my breath.)

Yes, they often do, but as written it's confusing.

> OTOH, if you can put text in several languages in a single body part,
> multipart/alternative might be overkill.  current UAs don't seem to be
> good at handling language differences in mp/alternative anyway.

Agreed.

> But I can try to clarify the text.

Thanks.

> > By the way, I have noticed some autoresponders don't decode
> > RFC2047-encoded subject lines correctly when they include
> > the Subject of the "subject message" in the body of the
> > response.
>
> hmmm.
>
> Subject: Auto-Re: =?encoded-word?=
>
> is perfectly valid (as long as there's a space after "Auto-Re:")

No, I mean the Subject Message is:

  Return-Path: <[email-masked]>
  From: [email-masked]
  Subject: =?encoded-word?=
  To: [email-masked]

  Hi, Keith.
  -dan
  <END OF MESSAGE>

and your autoresponder responds with:

  Return-Path: <[email-masked]>
  To: [email-masked]
  From: [email-masked]
  Subject: Keith is out of the office
  auto-submitted: auto-replied

  Keith has received your message with subject:
    =?encoded-word?=
  and will read it when he returns.

  <END OF MESSAGE>

when it should do something different with the Subject -- either it needs to use
the same charset as the RFC2047-encoded subject (unlikely), or it should omit
the Subject entirely if the Subject's charset isn't the same charset as the
autoreply.

> > Section 3 says:
> >
> >     An automatic responder MUST NOT send a response
> >     for every message received.
> >
> > This requirement will break all mailing list software
> > (majordomo, LISTSERV, etc.), as they're supposed to
> > send a response for every message received.
>
> are they really supposed to send a response to spam or viruses?
> that's why I say that in practice every responder needs some
> filtering to make sure the input is valid.

Then:

    An automatic responder MUST include mechanisms which
    prevent or reduce the effects of responding to malicious
    use or spam.  Such mechanisms ard described in this
    section.

> > Later, it says:
> >
> >      Responders SHOULD check the destination
> >      address for validity before generating the
> >      response, to avoid cluttering up the local
> >      mail queues with messages that cannot be
> >      delivered or are unlikely to be useful.
> >
> > I don't quite think this responsibility falls directly
> > on the responder, but rather on the local mail system
> > to validate RCPT TO addresses for syntactic validity
> > before accepting the message from an application such
> > as mail or an autoresponder.
>
> the point is to avoid burdening the mail system with things
> it shouldn't have to deal with.  early detection wins.
>
> the downside, I suppose, is that by giving this burden
> to the responder then the risk is greater that at least
> one component will impose inappropriate restrictions - like
> those web sites that won't let me type in [email-masked]
> as an email address because they think it's invalid.
>
> I'll think about this some more.

Where that detection/validation takes place is quite site-
specific.  The responder could be overly-anal in its interpretation
of that requirement, for example, and might want to try connecting
to port 25 of the MX record for the domain, when such outgoing
connections aren't permitted by the site's security policy.  Thus
the connection will fail, the autoresponder will decide the
address isn't valid, and won't submit it to the local mailer.
I agree this is an extreme example, but others are equally
valid (bang and percent-hack addresses, for example, could be
rejected by the autoresponder unnecessarily.  Likewise, bang
and percent-hack could be validated by the responder but may
be undeliverable by the site's mailer due to purposeful configuration
to prevent such addressing in another misguided attempt to block
spam).

> > As pointed out on
> > the mailing list, many group responders currently use
> > Reply-To because in many UAs, From isn't rewritable
> > (and MAIL FROM is even more unlikely to be rewritable),
> > and users might have legitimate reasons to specify
> > a different Reply-To, and users like that group
> > autoresponders use that specific Reply-To.  I know
> > back in days that BITNET hosts had filestores, I
> > liked the ability to use Reply-To to direct file
> > requests to another mailbox for example.
>
> I understand that such UAs exist (though I don't think
> they're nearly so common anymore).    I'm not sure how
> much we should do to try to accomodate them.  A UA that
> can't set From but can set Reply-To just seems fundamentally
> broken to me, though I'll grant that RFC 822 never said
> "UAs MUST allow users to set the From field".
>
> It's clearly wrong for a Personal or Group responder to
> use Reply-To.  It *might* be reasonable for a Service
> repsonder to use Reply-To, because presumably the
> sender expects an automatic response from a Service
> responder and has set Reply-To.  I tried to leave more
> wiggle room for Service responders than Personal or
> Group responders in this regard.

Okay.

Thanks,
-d

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 14:01:54 -0400
Sender: [email-masked]

Dan,

thanks for your comments. I agree with most of them.
 
> In 1.1, the description of Group Responders should include an
> example of a service address ([email-masked]), which you
> mentioned in some email threads but isn't described directly
> here in the I-D itself.  The virus scanner is one example,
> but the autoresponder for service addresses is a better (and
> more common) example.

I'm not sure what you mean here.  How is an autoresponder for
service addresses an example of a Group Responder, unless
it answers on behalf of several different recipients in a
way over which those recipients don't have control?

(or do I need to tweak my definition of Group Repsonder?
IMHO, recipient control over the response is the primary
thing that distinguishes Group from Personal responses)

> Section 2.2 mentions multipart/alternative for multi-language 
> response, but also says multiple charsets?

multiple language often requires multiple charsets, at least until
the whole world adopts UTF-8 (I'm not holding my breath.)  

OTOH, if you can put text in several languages in a single body part,
multipart/alternative might be overkill.  current UAs don't seem to be
good at handling language differences in mp/alternative anyway.

But I can try to clarify the text.

> By the way, I have noticed some autoresponders don't decode
> RFC2047-encoded subject lines correctly when they include
> the Subject of the "subject message" in the body of the
> response.  

hmmm.

Subject: Auto-Re: =?encoded-word?=

is perfectly valid (as long as there's a space after "Auto-Re:")

> Section 3 says:
> 
>     An automatic responder MUST NOT send a response
>     for every message received.
> 
> This requirement will break all mailing list software
> (majordomo, LISTSERV, etc.), as they're supposed to
> send a response for every message received.  

are they really supposed to send a response to spam or viruses?
that's why I say that in practice every responder needs some 
filtering to make sure the input is valid.

> Later, it says:
> 
>      Responders SHOULD check the destination 
>      address for validity before generating the 
>      response, to avoid cluttering up the local 
>      mail queues with messages that cannot be 
>      delivered or are unlikely to be useful.
> 
> I don't quite think this responsibility falls directly
> on the responder, but rather on the local mail system
> to validate RCPT TO addresses for syntactic validity
> before accepting the message from an application such
> as mail or an autoresponder.

the point is to avoid burdening the mail system with things
it shouldn't have to deal with.  early detection wins.

the downside, I suppose, is that by giving this burden
to the responder then the risk is greater that at least
one component will impose inappropriate restrictions - like
those web sites that won't let me type in [email-masked]
as an email address because they think it's invalid.

I'll think about this some more.

> In section 4, where you're describing Reply-To, it's
> unclear in the I-D how
> 
>     Sending automatic responses to Reply-To 
>     addresses can thus result in a large number 
>     of people receiving a useless or unwanted
>     message; it can also contribute to mail loops.
> 
> could occur.  It's obvious to me where the person
> accidentally (or on purpose) puts a mailing list name
> in the Reply-To, but it may not be obvious to the
> readers of the I-D how a "large number of people" could
> receive the autoresponders message.  

I can certainly elaborate on how this can happen.

> As pointed out on
> the mailing list, many group responders currently use
> Reply-To because in many UAs, From isn't rewritable 
> (and MAIL FROM is even more unlikely to be rewritable), 
> and users might have legitimate reasons to specify
> a different Reply-To, and users like that group
> autoresponders use that specific Reply-To.  I know
> back in days that BITNET hosts had filestores, I 
> liked the ability to use Reply-To to direct file 
> requests to another mailbox for example.

I understand that such UAs exist (though I don't think
they're nearly so common anymore).    I'm not sure how
much we should do to try to accomodate them.  A UA that
can't set From but can set Reply-To just seems fundamentally
broken to me, though I'll grant that RFC 822 never said 
"UAs MUST allow users to set the From field".

It's clearly wrong for a Personal or Group responder to 
use Reply-To.  It *might* be reasonable for a Service 
repsonder to use Reply-To, because presumably the 
sender expects an automatic response from a Service 
responder and has set Reply-To.  I tried to leave more 
wiggle room for Service responders than Personal or
Group responders in this regard.  

> Section 5 defines new protocol elements, and as such
> should be a separate standards-track document.

It could be split out if the ADs think that's the way to go,
and that's why it's in a separate section.  But I'd like to 
keep it in the current document as long as it's feasable to 
do that.  Maintaining two documents would require more work  :)

> Section 5.2 says:
> 
>     Such a field MAY be supplied for a manually 
>     sent message that is intended to test the 
>     response of other mail system components to 
>     the presence of an Auto-Submitted field in a
>     message.
> 
> During debugging and testing, there are lots of things that
> users, developers, postmasters, and system administrators
> will do, some of which purposefully violate MUSTs.  I think
> you can safely strike the sentence above.

actually in rereading the document I had decided to move it
elsewhere.  the main purpose here is to discourage UAs from
preventing humans from setting auto-submitted, but that could
be made clearer.

> Is your I-D intended to be a BCP document?

either that or standards-track.  whatever the ADs want.

Keith

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Keith Moore" <[email-masked]>, "Eric A. Hall" <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 13:42:11 -0400
Sender: [email-masked]

> > I wouldn't have put in auto-submitted except that some uniform means
> > of marking automatic responses is necessary to prevent loops.  There
> > are heuristics that could be used instead, but they don't work as well.
> 
> Using a MAIL FROM of <> for autoresponses meets the requirement to
> prevent loops.  Auto-submitted is only useful (to meet the 'prevent
> loops' requirement) when the MAIL FROM isn't null.  For other reasons
> there is some additional value in including auto-submitted even if
> MAIL FROM is <>.

one reason I didn't just insist that MAIL FROM be <>  is that too
many mailers categorically reject MAIL FROM:<>.  yes, they're broken,
but there's so much of this kind of brokenness in the world that a 
feature that depends on it not being broken is doomed to failure...

there are also things that rewrite <> to MAILER-DAEMON or some such,
presumably because mailers don't accept <>.

Keith

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Eric A. Hall" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 6 Jun 2002 10:38:17 -0700
Importance: Normal
Sender: [email-masked]

> I wouldn't have put in auto-submitted except that some uniform means
> of marking automatic responses is necessary to prevent loops.  There
> are heuristics that could be used instead, but they don't work as well.

Using a MAIL FROM of <> for autoresponses meets the requirement to 
prevent loops.  Auto-submitted is only useful (to meet the 'prevent
loops' requirement) when the MAIL FROM isn't null.  For other reasons
there is some additional value in including auto-submitted even if
MAIL FROM is <>.

-d

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 13:28:17 -0400
Sender: [email-masked]

> > I think the scope of the document is about right - one of the things
> > I've constantly seen every time the subject has come up in the past
> > 10 years or so is that arguments about how one kind of responder should
> > work keep getting applied to other kinds of responders, whether
> > it makes sense or not.  the point of having the scope as broad as it
> > is is to make it clear that different kinds of responders should have
> > different behavior.   and if those different behaviors aren't adequately
> > distinguished in the current document, well it's just a -00 version.
> 
> The behavior is so different for every potential application that you
> rapidly run into the exception-for-every-rule problem, especially in the
> context of universal auto-responder rules. All rules need to be prefaced
> with "unless the app needs X, don't do X"

not when you're talking about security.  poorly-designed applications 
(or poorly-written implementations) can be threats to the network.
the fact that an app "needs" to do X is no excuse for doing X if that
creates a security threat.

now I'd agree that the rules need to be carefully written, but saying
"unless the app needs X, don't do X" is giving too much rope.

of course, nothing forces apps to comply with this document - the
penalty for failure to meet at MUST or failure to meet a SHOULD without
a good reason is that your app doesn't comply with the spec.
but the spec is only useful if it specifies what is needed for 
responders to behave well.  letting insecure responders off the
hook doesn't serve anybody's interest.
 
> I would also think that a universal spec needs to be targetted towards
> BCP, with no mandatory rules, no new on-the-wire formats (eg, new header
> fields or mime types), and very generic recommendations such as "use
> Return-Path when possible" and "avoid exposing unnecessary information".

You might think that, but frankly I'd call such thinking naive.  Part of 
the problem is that any address can be forged, and there's nothing to
stop someone from putting a victim's address in the return-path field
of a message that's sent to a robot.  

I wouldn't have put in auto-submitted except that some uniform means
of marking automatic responses is necessary to prevent loops.  There
are heuristics that could be used instead, but they don't work as well.

Keith

Date: Thu, 06 Jun 2002 11:56:35 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dan Wing <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Dan Wing wrote:
> 
> > One comment with file-robots is that the recipient needs to be verified
> > with a confirmation message before the data-dump begins (which is also
> > unique from other auto-response apps).
> 
> A lot of mailing list software (majordomo/LISTSERV, to cite specific
> examples) do this, too, before subscribing the user -- so this isn't
> completely specific to file robots.  And some active mailing lists will
> cause a larger data-dump than most file robots!

Well, if we want to get detailed, those are permanent permissions while
file-robots need to be temporary (oops, resent a request from last week).
Regardless, these are both different from vacation/virus notifications
("can I send you a vacation message?").

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Recommendations for Automatic Responses to Electronic Mail
Date: Thu, 6 Jun 2002 09:32:00 -0700
Importance: Normal
Sender: [email-masked]

> One comment with file-robots is that the recipient needs to be verified
> with a confirmation message before the data-dump begins (which is also
> unique from other auto-response apps).

A lot of mailing list software (majordomo/LISTSERV, to cite specific
examples) do this, too, before subscribing the user -- so this isn't
completely specific to file robots.  And some active mailing lists will
cause a larger data-dump than most file robots!

-d

From: "Dan Wing" <[email-masked]>
To: "Keith Moore" <[email-masked]>, <[email-masked]>
Subject: RE: I-D  Recommendations for Automatic Responses to Electronic Mail
Date: Thu, 6 Jun 2002 09:29:44 -0700
Importance: Normal
Sender: [email-masked]

> I have just sent the document to internet-drafts.  It should be in the
> repositories in a day or two.  In the meantime, you can download it from
> http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-re
> sponse-00.txt

Great document, Keith.

I noticed inconsistent terms used to describe the message which 
elicited the automatic response -- some places it was "subject 
message" or "message resulting in the response".  This is somewhat
confusing with all of the messages flying around.  It would be
good to pick a term, define it, and use it throughout the doc.
Capitalization, which you used elsewhere to assist in understanding,
would be useful for this term.

The Abstract, which is all that most folks read on the I-D
announcements, should probably include the word 'vacation'.

In 1.1, in the item describing the spam-prevention system which
requires the sender to demonstrate signs of intelligent life,
the wording is complex and could perhaps be reduced to something
like:
  
    Responders designed to filter spam by quarantining a message,
    requesting the sender to perform some (supposedly non-
    automatable) action, after which the message is removed from
    quarantine and relayed to the original recipient.

In 1.1, the description of Group Responders should include an
example of a service address ([email-masked]), which you
mentioned in some email threads but isn't described directly
here in the I-D itself.  The virus scanner is one example,
but the autoresponder for service addresses is a better (and
more common) example.

I think the order of section 2, 3, and 4 could be improved.
Currently, the order is "what to send", "when to send",
and "where to send".  A more natural order seems to be
"when to send", "what to send", and "where to send".

Section 2.1.0 says SHOULD for the entire section, but section
2.1.1 contains a MUST.  I'm not sure the interpretation of
this conflict is clear.

The I-D contains the text:

     The human-readable portion of the From address (the 
     phrase before the address) SHOULD contain an indication 
     of the function performed by the Group Responder and 
     on whose behalf it operates (e.g. "Example Agency 
     virus filter")

Instead of "the phrase before the address", you should cite the ABNF
in RFC2822 ("phrase").

Section 2.2 mentions multipart/alternative for multi-language 
response, but also says multiple charsets?

Section 2.2 says:

    Response messages SHOULD NOT include significant 
    content from the subject message.  In particular 
    responses SHOULD NOT contain non-text/plain 
    attachments from the subject message.

This requires further discussion in the I-D.  For example,
if the subject message contains only text/html, what's the
autoresponder supposed to do (I would advise not including
any portion of the message).

By the way, I have noticed some autoresponders don't decode
RFC2047-encoded subject lines correctly when they include
the Subject of the "subject message" in the body of the
response.  It might be good to point out RFC2047-encoded
Subjects as a case that needs to be properly handled by
autoresponders.

In 2.2.1, the I-D says:

    An MDN SHOULD NOT be issued as an automatic 
    response unless the subject message contains 
    a Disposition-Notification-To field.  

This isn't a new requirement, but rather a repeat of an
existing RFC2298 requirement.  Your I-D should say 
something like:

    As required by [2], an MDN SHOULD NOT ...

Section 3 says:

    An automatic responder MUST NOT send a response
    for every message received.

This requirement will break all mailing list software
(majordomo, LISTSERV, etc.), as they're supposed to
send a response for every message received.  I think
you really want to restrict this MUST to personal 
responders, or otherwise soften this MUST if you did
intend it to cover majordomo-/LISTSERV-like responders.

In section 3, the I-D says:

    ... for the recipient is explicitly included in
    the To, CC, or Bcc field of the subject message.

change to:

    ... for the recipient is explicitly included in
    the To, CC, or Bcc field (where present) of the
    subject message.

In the same section, the I-D says:

    Responders SHOULD NOT generate responses for 
    any null address.

I know you mean where MAIL FROM is "<>", but the I-D
should be clearer.

Later, it says:

     Responders SHOULD check the destination 
     address for validity before generating the 
     response, to avoid cluttering up the local 
     mail queues with messages that cannot be 
     delivered or are unlikely to be useful.

I don't quite think this responsibility falls directly
on the responder, but rather on the local mail system
to validate RCPT TO addresses for syntactic validity
before accepting the message from an application such
as mail or an autoresponder.

I'm not sure how the autoresponder can decide if
a message is "unlikely to be useful" by examining
the rcpt to address (beyond the examination of 
MAILER-DAEMON, owner-*, *-request, etc.).

In section 4, the I-D says:

    If the Return-Path field is not present
    in the subject message, there is bug 
    in the SMTP server that delivered the 
    message, or that SMTP server is 
    improperly configured. 

Note that autoresponders which are implemented in the
transport (as opposed to at the UA layer) won't see
the Return-Path.  The text needs to be exapanded in
scope to include transport-based autoresponders which
legitimately won't see Return-Path, but will see the
same thing in another field (perhaps via an internal
datastructure which contains the same text as Return-
Path _would_ contain).

In section 4, where you're describing Reply-To, it's
unclear in the I-D how

    Sending automatic responses to Reply-To 
    addresses can thus result in a large number 
    of people receiving a useless or unwanted
    message; it can also contribute to mail loops.

could occur.  It's obvious to me where the person
accidentally (or on purpose) puts a mailing list name
in the Reply-To, but it may not be obvious to the
readers of the I-D how a "large number of people" could
receive the autoresponders message.  As pointed out on
the mailing list, many group responders currently use
Reply-To because in many UAs, From isn't rewritable 
(and MAIL FROM is even more unlikely to be rewritable), 
and users might have legitimate reasons to specify
a different Reply-To, and users like that group
autoresponders use that specific Reply-To.  I know
back in days that BITNET hosts had filestores, I 
liked the ability to use Reply-To to direct file 
requests to another mailbox for example.

In section 4, the paragraph on From doesn't directly
say SHOULD NOT.

Section 5 defines new protocol elements, and as such
should be a separate standards-track document.

Section 5.2 says:

    Such a field MAY be supplied for a manually 
    sent message that is intended to test the 
    response of other mail system components to 
    the presence of an Auto-Submitted field in a
    message.

During debugging and testing, there are lots of things that
users, developers, postmasters, and system administrators
will do, some of which purposefully violate MUSTs.  I think
you can safely strike the sentence above.

At the end of section 5.2, it says:

    The "comment" syntactical construct can be used to 
    indicate a reason why this message was auto-submitted.

The ABNF from RFC2822 should be cited.

In security considerations, perhaps we should strongly advise
autoresponders to include sufficient information to allow
tracing the source of attacks, such as the headers of the
message which triggered the autoresponse?  Perhaps this by
itself is a reason to standardize a multipart for 
autoresponders.  The inclusion In-Reply-To in the response
is good, but only if in conjunction the autoresponder 
retains headers.  Or perhaps "retain headers for auditing"
should be a recommendation in the security considerations
section?

Is your I-D intended to be a BCP document?

-d

Date: Thu, 06 Jun 2002 11:01:44 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore wrote:

> I think the scope of the document is about right - one of the things
> I've constantly seen every time the subject has come up in the past
> 10 years or so is that arguments about how one kind of responder should
> work keep getting applied to other kinds of responders, whether
> it makes sense or not.  the point of having the scope as broad as it
> is is to make it clear that different kinds of responders should have
> different behavior.   and if those different behaviors aren't adequately
> distinguished in the current document, well it's just a -00 version.

The behavior is so different for every potential application that you
rapidly run into the exception-for-every-rule problem, especially in the
context of universal auto-responder rules. All rules need to be prefaced
with "unless the app needs X, don't do X"

I would also think that a universal spec needs to be targetted towards
BCP, with no mandatory rules, no new on-the-wire formats (eg, new header
fields or mime types), and very generic recommendations such as "use
Return-Path when possible" and "avoid exposing unnecessary information".
You will also need to disclaim that any of the recommendations might be
overridden by type-specific documents.

I'll give specific feedback later today.

One comment with file-robots is that the recipient needs to be verified
with a confirmation message before the data-dump begins (which is also
unique from other auto-response apps).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 09:22:49 -0400
Sender: [email-masked]

> Keith Moore wrote:
> 
> > draft-moore-auto-email-response-00.txt
> 
> First blush is that this is a *lot* broader in scope than what we have
> been discussing. That's fine, but it's an important distinction. Nowhere
> did your outline mention anything about mailing list subscription messages
> or file robots, for example, and we didn't talk about those. The necessary
> behaviors for those are a *lot* different than auto-responses from
> vacation and virus programs.

I think the scope of the document is about right - one of the things
I've constantly seen every time the subject has come up in the past
10 years or so is that arguments about how one kind of responder should 
work keep getting applied to other kinds of responders, whether
it makes sense or not.  the point of having the scope as broad as it
is is to make it clear that different kinds of responders should have
different behavior.   and if those different behaviors aren't adequately
distinguished in the current document, well it's just a -00 version.

> The result is that a lot of the stuff that's defined doesn't really apply
> to some of the message types. I see no need to define how mailing list
> managers should format subscription confirmation messages, for example.

In general I think it's reasonable to say something on the order of
messages intended for humans should be simple and easily read, try not 
to be annoying, etc., and potentially harmful attachments shouldn't 
be included, etc.  I won't argue that I have every detail right.  
Hey, I wrote this thing in a day, and I suppose it shows.

> What kind of interoperability challenges are being encountered from
> subscription confirmation messages?
> 
> Another example:
> 
>  | Response messages SHOULD NOT include significant content from the
>  | subject message.
> 
> Automatic transfers of group edits on a shared document depend on
> "significant content" from the original message.

again, the goal here is to avoid being used to transmit spam or viruses.

I once got called in as a consultant for a bank that was using a piece
of software, whose auto-responder would respond with only a brief
annotation, and include the entire subject message in the response.
(it also copied everyone in the to and cc fields) spammers were using it 
as an open relay.  it's bad enough that the bank's facilities were being
used, what was even worse is that the porn spam was sent out with a
>From address from the bank's domain...
  
I don't wish to exclude 'automatic transfers of group edits on a shared
document' from being able to use email as a transfer mechanism.  however 
I do think that automatic responders have responsibilities similar
to SMTP relays in that they need to take effective measures to avoid being 
used as amplifiers  or launderers of messages from unauthorized parties.

> And so forth. I guess I am saying that I would be more comfortable if this
> were scaled down to "human responder agents." We could probably be more
> syntactically precise with a tighter scope. It's fine to go broader but
> there will probably need to be a lot less rules (and even suggestions).

Again, I think the scope is about right.  Maybe the solution is not to
have fewer rules but to rephrase the rules in terms of the problems 
that they're meant to address.    (e.g. 'responders SHOULD (or MUST)
ensure that they cannot be used to relay significant content from
unauthorized parties to destinations chosen by the message originator', 
rather than 'SHOULD NOT include significant content...')  

Keith

Date: Thu, 06 Jun 2002 01:01:34 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Keith Moore wrote:

> draft-moore-auto-email-response-00.txt

First blush is that this is a *lot* broader in scope than what we have
been discussing. That's fine, but it's an important distinction. Nowhere
did your outline mention anything about mailing list subscription messages
or file robots, for example, and we didn't talk about those. The necessary
behaviors for those are a *lot* different than auto-responses from
vacation and virus programs.

The result is that a lot of the stuff that's defined doesn't really apply
to some of the message types. I see no need to define how mailing list
managers should format subscription confirmation messages, for example.
What kind of interoperability challenges are being encountered from
subscription confirmation messages?

Another example:

 | Response messages SHOULD NOT include significant content from the
 | subject message.

Automatic transfers of group edits on a shared document depend on
"significant content" from the original message.

And so forth. I guess I am saying that I would be more comfortable if this
were scaled down to "human responder agents." We could probably be more
syntactically precise with a tighter scope. It's fine to go broader but
there will probably need to be a lot less rules (and even suggestions).

Either way is fine with me.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

content-class: urn:content-classes:message
Subject: RE: I-D  Recommendations for Automatic Responses to Electronic Mail
Date: Wed, 5 Jun 2002 22:56:40 -0700
From: "Dan Kohn" <[email-masked]>
To: "Keith Moore" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Very nice job, Keith.

In section 1, after ""sorcerer's apprentice" syndrome" I would add these
sentences:

(sorcerer's apprentice mode: n. [from Goethe's "Der Zauberlehrling" via
Paul Dukas's "L'apprenti sorcier" the film "Fantasia"] A bug in a
protocol where, under some circumstances, the receipt of a message
causes multiple messages to be sent, each of which, when received,
triggers the same bug.)

And provide a non-normative reference to
<http://www.jargon.net/jargonfile/s/sorcerersapprenticemode.html>

In section 2.1.4, you have:

NOTE: Just as the prefix "Re:" (presumably an abbreviation of the
English word "reply") is sometimes translated to other languages by mail
readers, or otherwise interpreted by mail readers as indication that the
message is a reply, so the prefix "Auto-Re:" may also be translated or
used as a generic indication that the message is an automatic response.
However the "Auto-Re:" indication is intended only as an aid to humans
in processing the message.  The validity of "Auto-Re:" SHOULD NOT be
assumed by mail processing software.

I would instead recommend:

NOTE: The string "Re: " (from the Latin "res", in the matter of) in the
Subject is often translated by mail readers to the user's native
languages before display.  It is important to note that the phrases "Re:
" and "Auto-Re: " are both protocol elements, and so SHOULD always be
sent on the wire in their native English form, not as a translation.  If
this were not the case, n languages would require n*(n-1) equivalence
mappings, with (n-1) mappings on each MUA.  By treating the prefixes as
protocol elements, only n equivalence mappings are needed, and each MUA
need only be able to translate from the English phrases to that user's
language.

I don't really see what you're getting at in the final sentence of your
original text, since every aspect of RFC 2822 mail is so eminently
forgeable.

In section 5, I think you need to specify that any use of an extension
token should be interpreted as the message being automatically
generated, and so an automatic response MUST NOT be sent to it.  I.e.,
if the Auto-Submitted: field is present AND it does not contain "no",
then the message was automatically generated.

Section 3 then changes from:

-    Automatic responses SHOULD NOT be issued in response to any message
     which contains an Auto-Submitted header field with a value of
     "auto-replied" or "auto-generated".

To:

-    Automatic responses SHOULD NOT be issued in response to any message
     which contains an Auto-Submitted header field and in which that
field
     has any value other than "no".

In Section 7, s/paramters/parameters

          - dan
--
Dan Kohn <mailto:[email-masked]>
<http://www.dankohn.com/>  <tel:+1-650-327-2600>
Essays announced on <mailto:[email-masked]>

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2002 17:04
To: [email-masked]
Cc: [email-masked]
Subject: I-D Recommendations for Automatic Responses to Electronic Mail

I have just sent the document to internet-drafts.  It should be in the
repositories in a day or two.  In the meantime, you can download it from
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-resp
onse-00.txt

or in alternate versions for the ASCII-impaired:

http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-resp
onse-00.ps
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-resp
onse-00.pdf

Keith

To: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 05 Jun 2002 21:59:45 -0700
Lines: 55
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>> It's been one of my long-running gripes with the DSN standard that the
>> from address should be a deliverable e-mail address.

> I suppose the alternative is to provide no feedback path in case the
> DSN was issued in error?  I'm not sure this is better than the current
> situation.

I can't say that I remember getting a useful mail problem report from
someone external to the institution rather than having the user who's mail
is having trouble notice it first.

> Personally I don't see many human-originated replies to DSNs;

Lucky....

I don't see any or hardly any for the little domains I run for myself, but
[email-masked] gets quite a few of them even without a repliable
address on our bounces.  Before I made that change, we got lots, enough
that the people who were handling the address before I started fiddling
with it were complaining about it.

I think this may be one of those small site / large site discrepencies,
where once your mail volume hits a knee in the curve, you suddenly start
seeing a lot more of something.

> I do see occasional replies/responses to DSNs from broken mail robots,

Yup, get those too.  Some of them here in fact.  I need to track a few of
those down and offer our central autoresponder service instead.

> and *lots* of bounced DSNs resulting from spam that was sent to my mail
> system, forwarded to another address, bounced, and couldn't be returned
> to the original return address because it wasn't valid.

*sigh*  Yeah.  I'm tempted to filter all of those out, but occasionally
they point out problems like open relays that really need to be dealt with
right away.

> I'm tempted to put in code that insists that all mail forwarded to
> another system have a return address that appears to be capable of
> receiving bounced mail - on seeing a RCPT to a forwarded address, it
> will send HELO/MAIL FROM:<>/RCPT TO:<return-path> back to the MX for the
> return-path address.  If that gives me a 5xx response, then the response
> to RCPT on the incoming message will also be 5xx - invalid return
> address.

There are places where I'd definitely *not* want this (systems that are
mostly leaf nodes and forward their administrative mail to other systems
including their double bounces, for instance), but in general it's not
that bad of an idea.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Thu, 06 Jun 2002 00:12:07 -0400
Sender: [email-masked]

> ned <[email-masked]> writes:
> 
> > One type of responder that's missing from your first list is the "change
> > of address" agent that reports that a given recipient address has
> > changed and senders should update their address lists.
> 
> That one's kind of interesting in that there's an opportunity to provide
> data in a way that can be acted on automatically.

indeed.  provided, of course, you can authenticate it.

> Would all cases in which no response to the auto-generated message is
> desired or will be read essentially be classified as DSNs (bounce
> messages, in essence)?  

no, not at all.  DSNs report on the delivery status of a message, 
and are originated by the email system.  this is a completely different 
thing than a response from the recipient of the subject message that
might even be based on the content of that message.  If you get a
failure DSN you should not get any response from the recipient 
(or his responder); if you get a success DSN then you might still get 
such a response.  so I think trying to shoehorn such responses into
DSN format would be a really poor fit.

> The examples that occur to me are basically bounce
> messages, such as an autoreply put on an old address that is no longer in
> service, giving new contact information that isn't via e-mail.

even that isn't necessarily a DSN if it's issued by the recipient.
(e.g. if I change addresses and leave a vacation program running
at the old address that says "please use this new address instead"
then strictly speaking, that really shouldn't be a DSN)

> It's been one of my long-running gripes with the DSN standard that the
> from address should be a deliverable e-mail address.  

I suppose the alternative is to provide no feedback path in case the
DSN was issued in error?  I'm not sure this is better than the current
situation.  Personally I don't see many human-originated replies
to DSNs; I do see occasional replies/responses to DSNs from broken
mail robots, and *lots* of bounced DSNs resulting from spam that was 
sent to my mail system, forwarded to another address, bounced, and 
couldn't be returned to the original return address because it wasn't valid.

I'm tempted to put in code that insists that all mail forwarded
to another system have a return address that appears to be capable 
of receiving bounced mail - on seeing a RCPT to a forwarded address,
it will send HELO/MAIL FROM:<>/RCPT TO:<return-path> back to the MX
for the return-path address.  If that gives me a 5xx response, then 
the response to RCPT on the incoming message will also be 5xx -
invalid return address.  

> > Section 3 (when to send an automatic response) doesn't seem to deal with
> > the case of a service responder. It isn't entirely clear to me that your
> > blanket "In practice there are always reasons to refuse to respond to
> > requests" necessarily applies to service responders.
> 
> You may also want to include a note about Precedence: bulk and Precedence:
> junk; in practice, they're even better than checks for things like
> *-request in avoiding sending mail back in response to mailing list
> traffic.  (Auto-Submitted doesn't serve quite the same purpose.)

Precedence is so over-loaded and its use is so varied that I hesitate 
to recommend it for anything.  Maybe I'll make that a MAY...
 
> Saying that service responders shouldn't use Reply-To is a definite
> departure from current best practice as I understand it for mailing list
> management daemons.  I don't think that's a good recommendation, and I
> also don't agree with your description of what Reply-To is for; that's
> not, in practice, what I see it used for.  I see it much more frequently
> used to work around a mail system that fixes the From header at a
> particular value, in which case using Reply-To is the right thing to do.

I see Reply-to used for that purpose also.  But  I think it's sheer 
insanity to recommend that Reply-To be diluted from its distinct purpose 
because some UAs failed to implement another feature of the mail protocol.
Rather than try to make Reply-To be a replacement for From when the
sender wants replies to go back to him or her, at, why not just make From 
settable?  It's clear from 822 that From is supposed to be settable, how 
else could sender specify multiple From addresses, the boss's address, etc...? 
And for various reasons, when the alternate From address really does 
identify the message author, making From settable is a lot more reliable
than setting reply-to.

Keith

To: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 05 Jun 2002 19:53:42 -0700
Lines: 64
Sender: [email-masked]

ned <[email-masked]> writes:

> One type of responder that's missing from your first list is the "change
> of address" agent that reports that a given recipient address has
> changed and senders should update their address lists.

That one's kind of interesting in that there's an opportunity to provide
data in a way that can be acted on automatically.

> An interesting wrinkle that comes up in the case of setting the from
> address for a service responder is the desire to conduct a sort of
> "dialogue" with such an agent. For example, a mailing list maintenance
> service may send requests for confirmations that the original sender
> then replies to. I don't believe this case changes your general
> recommendation that the from address in this case should be one
> associated with the service maintainer. However, you may want to mention
> this case, and point out the potential for mail loops that exists when
> the responder does put its own address in the from field.

A good example here is a mail message sent to confirm a subscription that
includes information about how to unsubscribe (by replying to that
message).  This is common for mailing list managers.

Would all cases in which no response to the auto-generated message is
desired or will be read essentially be classified as DSNs (bounce
messages, in essence)?  The examples that occur to me are basically bounce
messages, such as an autoreply put on an old address that is no longer in
service, giving new contact information that isn't via e-mail.

It's been one of my long-running gripes with the DSN standard that the
from address should be a deliverable e-mail address.  It's a good idea in
theory; in practice, that address gets so much complete junk from people
who didn't read the bounce or have no real understanding of mail at all
that it never gets read and it may as well go to /dev/null.  I made the
choice of violating the DSN standard in only that respect with bounces
generated by @stanford.edu, instead sending the mail out from an address
that silently discards all responses, saying that explicitly in the
bounce, and giving alternate contact information in the event of an
emergency in the bounce.

Before I did that, we got tons of mail every day from people just
forwarding the bounce back to its From address, as if that would somehow
magically make their mail go through.

> Section 3 (when to send an automatic response) doesn't seem to deal with
> the case of a service responder. It isn't entirely clear to me that your
> blanket "In practice there are always reasons to refuse to respond to
> requests" necessarily applies to service responders.

You may also want to include a note about Precedence: bulk and Precedence:
junk; in practice, they're even better than checks for things like
*-request in avoiding sending mail back in response to mailing list
traffic.  (Auto-Submitted doesn't serve quite the same purpose.)

Saying that service responders shouldn't use Reply-To is a definite
departure from current best practice as I understand it for mailing list
management daemons.  I don't think that's a good recommendation, and I
also don't agree with your description of what Reply-To is for; that's
not, in practice, what I see it used for.  I see it much more frequently
used to work around a mail system that fixes the From header at a
particular value, in which case using Reply-To is the right thing to do.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 05 Jun 2002 17:57:13 -0700 (PDT)
From: [email-masked]
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
To: Keith Moore <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> I have just sent the document to internet-drafts.  It should be in the
> repositories in a day or two.  In the meantime, you can download it from
> http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-response-00.txt

Very nice first cut. I particularly like your use of a responder taxonomy.

Some initial comments:

One type of responder that's missing from your first list is the "change of
address" agent that reports that a given recipient address has changed and
senders should update their address lists.

An interesting wrinkle that comes up in the case of setting the from address
for a service responder is the desire to conduct a sort of "dialogue" with such
an agent. For example, a mailing list maintenance service may send requests for
confirmations that the original sender then replies to. I don't believe this
case changes your general recommendation that the from address in this case
should be one associated with the service maintainer. However, you may want to
mention this case, and point out the potential for mail loops that exists when
the responder does put its own address in the from field.

Section 3 (when to send an automatic response) doesn't seem to deal with the
case of a service responder. It isn't entirely clear to me that your
blanket "In practice there are always reasons to refuse to respond to
requests" necessarily applies to service responders.

You probably should explain what you mean by "Responders SHOULD NOT generate
responses for any null address." in more detail.

I also have to agree that "sorcerer's apprentice" needs to be explained.

Again, a good start on a much-needed document.

				Ned

To: [email-masked]
Subject: Re: I-D on automatic responses
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 05 Jun 2002 17:58:11 -0700
Lines: 33
Sender: [email-masked]

Eric A Hall <[email-masked]> writes:

> Original-Recipient, at least. (I know you said that you think VERP is
> required for this, but the common usage is already there, and at least
> some systems conform to it).

I've never understood the use of this field.  Could you explain more about
how you think this would be helpful to include?

> Original-Message-ID would also be particularly useful if the generic
> notifications were used for things like virus notifications.

Virus notifications are a class of autoresponse that I think should be
full-blown multipart/report; I agree with you there.

I'm thinking more in terms of a typical use for an autoreply (at least in
my experience), something like "thank you for your message, we're really
busy, we'll write back to you in 2147" or "here's a ticket tracking number
for your message; no one here will have any idea what you're talking about
if you refer to it in your later e-mail, but they make great sock
warmers."

> I would also expect that specific applications would want to tailor
> their own, as we already have with DSNs and MDNs. Vacation and virus
> notifications would be obvious candidates.

I agree on virus notifications, at least, yes.  I can see an argument for
vacation messages maybe if we can convince MUA authors to actually do
something reasonable with structured content, but so far it seems like
we've mostly failed on that battle with DSNs.  :/

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: [email-masked], Keith Moore <[email-masked]>
Subject: Re: I-D Recommendations for Automatic Responses to Electronic Mail 
Date: Wed, 05 Jun 2002 20:51:16 -0400
Sender: [email-masked]

> Use of the phrase "sorcerer's apprentice syndrome" in a document
> intended for a wide variety of people really doesn't seem to aid
> comprehension.  You use it four times in the document without defining
> what it means.

yeah, that's what I get for trying to get a quick draft up.
next revision, I'll either define the term or use another term.

Date: Wed, 5 Jun 2002 20:39:53 -0400
From: Lawrence Greenfield <[email-masked]>
To: [email-masked], Keith Moore <[email-masked]>
Subject: Re: I-D  Recommendations for Automatic Responses to Electronic Mail
Sender: [email-masked]

Use of the phrase "sorcerer's apprentice syndrome" in a document
intended for a wide variety of people really doesn't seem to aid
comprehension.  You use it four times in the document without defining
what it means.

Larry

To: [email-masked]
cc: [email-masked]
Subject: I-D  Recommendations for Automatic Responses to Electronic Mail
From: Keith Moore <[email-masked]>
Date: Wed, 05 Jun 2002 20:04:12 -0400
Sender: [email-masked]

I have just sent the document to internet-drafts.  It should be in the
repositories in a day or two.  In the meantime, you can download it from
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-response-00.txt

or in alternate versions for the ASCII-impaired:

http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-response-00.ps
http://www.cs.utk.edu/~moore/internet-drafts/draft-moore-auto-email-response-00.pdf

Keith

Date: Wed, 05 Jun 2002 18:58:11 -0500
From: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D on automatic responses
Sender: [email-masked]

Russ Allbery wrote:
> 
> Eric A Hall <[email-masked]> writes:
> > Russ Allbery wrote:
> 
> >> message/delivery-status isn't always applicable as the second part.
> 
> > No, but a message/generic-notification can be.
> 
> Can you give me some idea of what additional content you think would be
> useful to include in all autogenerated replies?

Original-Recipient, at least. (I know you said that you think VERP is
required for this, but the common usage is already there, and at least
some systems conform to it).

Original-Message-ID would also be particularly useful if the generic
notifications were used for things like virus notifications.

I would also expect that specific applications would want to tailor their
own, as we already have with DSNs and MDNs. Vacation and virus
notifications would be obvious candidates.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: [email-masked]
Subject: Re: I-D on automatic responses
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Wed, 05 Jun 2002 14:42:39 -0700
Lines: 12
Sender: [email-masked]

Eric A Hall <[email-masked]> writes:
> Russ Allbery wrote:

>> message/delivery-status isn't always applicable as the second part.

> No, but a message/generic-notification can be.

Can you give me some idea of what additional content you think would be
useful to include in all autogenerated replies?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 05 Jun 2002 08:53:09 -0500
From: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D on automatic responses
Sender: [email-masked]

Russ Allbery wrote:

> message/delivery-status isn't always applicable as the second part.

No, but a message/generic-notification can be.

> > Which portion? Everything the average user should need to know ought to
> > be clearly explained in the text/plain leader.
> 
> If everything that's important is in the text/plain section, why on earth
> should one send anything other than that?

Because humans aren't the only ones that get them.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: Russ Allbery <[email-masked]>
cc: [email-masked]
Subject: Re: I-D on automatic responses 
Date: Wed, 05 Jun 2002 08:43:01 -0400
Sender: [email-masked]

> I believe that those autoreplies should be sent in response to every
> message sent to them, not just once a week.  

I certainly don't believe that the "once a week" idea should apply to
all autoreplies, just to notices of the form "this recipient is
temporarily unavailable".

To: [email-masked]
Subject: Re: I-D on automatic responses
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 04 Jun 2002 22:56:52 -0700
Lines: 44
Sender: [email-masked]

Eric A Hall <[email-masked]> writes:

> I would think that all autogenerated messages should be sent as
> multipart/report, if for no other reason than to let messaging systems
> reuse existing code.

Er, what if the text/plain portion is the entire content?
multipart/report assumes that you're reporting something that implies some
meaningful content to at least the second portion of the message.

Clearly, message/delivery-status isn't always applicable as the second
part.  (Consider, for example, an auto-generated response that gives the
user a tracking number for their problem.  A message/delivery-status part
wouldn't provide any useful information.)

Furthermore, as mentioned in my message, handling of multipart/report in
popular clients is rather far from ideal; the only portion of the message
that you can be assured of them being able to read is the initial part.

> If a multipart/report were used, any subsequent
> message/<app>-notification entities should at a minimum contain the
> Original-Recipient body field (sourced from ORCPT, if available). List
> admins can use this to figure out who they need to cutoff, if nothing
> else.

Well, no, they can't.  For the hard cases where the list owner can't
already tell that, you already don't have enough information to include a
meaningful Original-Recipient.  If the user forwarded their yahoo.com
e-mail address to your server, you have no idea what their original mail
address was to report it.

VERP or address probes are really the only solution to that problem.

>> Bear in mind that MIME encapsulation can make it harder for the user to
>> actually see that portion of the message.

> Which portion? Everything the average user should need to know ought to
> be clearly explained in the text/plain leader.

If everything that's important is in the text/plain section, why on earth
should one send anything other than that?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Subject: Re: Sieve
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 04 Jun 2002 22:21:47 -0700
Lines: 31
Sender: [email-masked]

Florian Weimer <[email-masked]> writes:

> VERP is basically dead for practical purposes.

Do you mean in the sense of being absolutely reliable, or in the sense of
being widely used?

If you mean the latter, you're wrong.  I read the bounce logs of
Stanford's mail servers regularly.  :)

> At work, we run a small read-only mailing list which mainly targets
> German IT workers.  Apparently, many larger institutions gateway mail
> from RFC 821/822 format to some X.400 derivate or proprietary mail
> implementations, and these gateways throw away the distinction between
> envelope address and header address.

> As a result, even delivery failure notifications are regularly sent to
> the address in the From: header, not just the regular stream of
> out-of-office notifications during school vacations.

There is always some mail system out there that's sufficiently perverse
that it will break anything that you try to do, but that's not a reason
not to do something.

The basic idea of VERP is fundamentally sound and solves one of the major
problems in mailing list management, namely correlating a DSN with a list
member when all of the forwarding information for how the message got
there has been systematically destroyed by bad mail systems.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Wed, 05 Jun 2002 00:14:57 -0500
From: "Eric A. Hall" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D on automatic responses
Sender: [email-masked]

Russ Allbery wrote:

> >       - proper MIME encapsulation (?)
> 
> What in particular would you encapsulate?  Just the original message if
> you're including it for reference, or other things as well?

I would think that all autogenerated messages should be sent as
multipart/report, if for no other reason than to let messaging systems
reuse existing code. Secondarily, reusing multipart/report yields itself
to letting people filter them out (eg, list owners can universally reject
them from the posting queue). Furthermore, if we are going to define
fundamental behavior for all apps to use, a little consistency in the
reporting service will go a long way to getting it right. Keith and I are
arguing about this and he can explain his position, but that's mine.

If a multipart/report were used, any subsequent message/<app>-notification
entities should at a minimum contain the Original-Recipient body field
(sourced from ORCPT, if available). List admins can use this to figure out
who they need to cutoff, if nothing else.

> Bear in mind that MIME encapsulation can make it harder for the user to
> actually see that portion of the message.

Which portion? Everything the average user should need to know ought to be
clearly explained in the text/plain leader.

> We still regularly get
> complaints about our bounce messages, which I switched a while back to a
> format that strictly conforms with the DSN standard, because the original
> message shows up as an attachment that the user's mail client can't deal
> with.

Ah, outlook express? The message/<app>-notification entity freaks it out
but the users shouldn't need to parse that stuff. If the trailer entity is
defined as a text/rfc822-headers entity, it will be displayed in-line. The
message/rfc822 entities will be iconified but can be opened directly.
Again, the text/plain leader ought to provide all the info that a human
user needs to know.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: [email-masked]
Subject: Re: I-D on automatic responses
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 04 Jun 2002 21:30:03 -0700
Lines: 35
Sender: [email-masked]

Florian Weimer <[email-masked]> writes:
> Keith Moore <[email-masked]> writes:

>>     - content (should probably limit size, content to limit
>>       DoS attack potential - e.g. should not allow sender to
>>       use the responder as a relay for viruses)

A somewhat dubious but effective way of getting around the problem of
being used as a relay for viruses is to include the original message in
the body of the reply in plain text rather than as a MIME-formatted
inclusion.  That defangs most of the active content in most mailers.
That's what I'm doing right now.

>       - proper MIME encapsulation (?)

What in particular would you encapsulate?  Just the original message if
you're including it for reference, or other things as well?

Bear in mind that MIME encapsulation can make it harder for the user to
actually see that portion of the message.  We still regularly get
complaints about our bounce messages, which I switched a while back to a
format that strictly conforms with the DSN standard, because the original
message shows up as an attachment that the user's mail client can't deal
with.

(I've also encountered a bizarre problem apparently in Eudora where the
mail client for some reason doesn't properly delete the DSN message off of
the server when using POP, thus making the user think that they're
receiving the message over and over again when we only sent it once and
they only have one copy in their mailbox that their client keeps
downloading.  This seems to only happen with Eudora, and not all the time,
and I've not managed to duplicate it or track it down further.)

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Subject: Re: I-D on automatic responses
From: Russ Allbery <[email-masked]>
Organization: The Eyrie
Date: Tue, 04 Jun 2002 21:25:58 -0700
Lines: 27
Sender: [email-masked]

Eric A Hall <[email-masked]> writes:

> Unless I missed them:

>   no autoreplies to owner-* or *-request

>   maintain db of respondents, recommended minimum of once per week

Which type of autoreplies?

For example, my mail system currently sends some autoreplies which are
essentially bounces, but which aren't formatted as bounces because bounces
confuse the user.  There are role addresses that we've retired in favor of
a ticket tracking system, and the user is told to instead submit their
problem to that system.

I believe that those autoreplies should be sent in response to every
message sent to them, not just once a week.  (Whether or not they should
go to owner-* or *-request is an iffier question.)

I'm following this discussion with interest as currently they're going to
From/Reply-To because that's been more reliable in actually reaching the
sender, but I'm pretty much convinced they should actually go to envelope
sender.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

From: Keith Moore <[email-masked]>
To: "Charles Lindsey" <[email-masked]>
cc: [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Tue, 04 Jun 2002 22:56:41 -0400
Sender: [email-masked]

> But what about the case where the list-bot wants to refuse the message, or
> "your message has been passed to the moderator of the list"? Clearly,
> Reply-To is disastrous in this case. From is actually the best choice,
> though Reutrn-Path _might_ just do instead.

>From is no better than reply-to here.  Either one can be a potentially
large group of people.  (more likely with reply-to, but still possible
with from)

Keith

To: [email-masked]
Xref: clerew local.mime:1574
Newsgroups: local.mime
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Choosing recipient of automatic replies
Date: Tue, 4 Jun 2002 18:34:12 GMT
Lines: 33
Sender: [email-masked]

In <[email-masked]> Dave Crocker <[email-masked]> writes:

>At 01:52 AM 6/3/2002 -0400, Keith Moore wrote:

>>    Consider a message
>>intended for a mailing list where the sender specified the list address in
>>the reply-to field (which is a perfectly reasonable thing to do) - if a robot
>>answers the mail on behalf of a list recipient and sends the reply to the
>>entire list, this will be seen as disruptive.

>it is frankly just as bad to have it go to the message originator.  not as 
>bad in scale but as bad in inappropriateness.

>in pretty much all cases of that type of situation, the fact that the 
>recipient is not explicitly mentioned in the To or CC field means that the 
>software should not send a reply at all.

But what about the case where the list-bot wants to refuse the message, or
"your message has been passed to the moderator of the list"? Clearly,
Reply-To is disastrous in this case. From is actually the best choice,
though Reutrn-Path _might_ just do instead.

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

To: Keith Moore <[email-masked]>
Cc: "Dan Wing" <[email-masked]>, "Eric A. Hall" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, [email-masked]
Subject: Re: I-D on automatic responses
From: Florian Weimer <[email-masked]>
Mail-Followup-To: Keith Moore <[email-masked]>, "Dan Wing" <[email-masked]>,  "Eric A. Hall" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>,  [email-masked]
Date: Tue, 04 Jun 2002 23:12:46 +0200
Lines: 17
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> III. Format of automatic responses
>     - envelope return address (avoid loops!)
>     - headers (to, from, subject, auto-submitted)
>     - content (should probably limit size, content to limit
>       DoS attack potential - e.g. should not allow sender to
>       use the responder as a relay for viruses)

     - plain text, English version included, involved addresses have
       to be in Internet syntax

Have a look at

http://www.exim.org/pipermail/exim-users/Week-of-Mon-20020603/039366.html

to see why this is required, or post to BUGTRAQ. :-/

From: "Dan Wing" <[email-masked]>
To: "Florian Weimer" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 13:59:22 -0700
Importance: Normal
Sender: [email-masked]

> > Specifically, I know that PMDF and iMS (MTAs I've worked on) add
> > such a field,and I believe sendmail, qmail, MMDF, PP, exim, and even
> > Exchange do so as well.
> 
> In Exim, it's a config item which is not enabled by default.

That implementation decision hinders proper operation of RFC2298-
compatible UAs.

-d

To: [email-masked]
Cc: [email-masked]
Subject: Re: Sieve
From: Florian Weimer <[email-masked]>
Mail-Followup-To: [email-masked], [email-masked]
Date: Tue, 04 Jun 2002 22:53:55 +0200
Lines: 15
Sender: [email-masked]

[email-masked] writes:

[Return-path with proper semantics]

>> Nice, however it doesn't seem to be implemented widely.
>
> Hmm. My impression has been the exact opposite.

Maybe it's implemented widely, but not universally.

> Specifically, I know that PMDF and iMS (MTAs I've worked on) add
> such a field,and I believe sendmail, qmail, MMDF, PP, exim, and even
> Exchange do so as well.

In Exim, it's a config item which is not enabled by default.

To: Keith Moore <[email-masked]>
Cc: "Dan Wing" <[email-masked]>, "Eric A. Hall" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, [email-masked]
Subject: Re: I-D on automatic responses
From: Florian Weimer <[email-masked]>
Mail-Followup-To: Keith Moore <[email-masked]>, "Dan Wing" <[email-masked]>,  "Eric A. Hall" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>,  [email-masked]
Date: Tue, 04 Jun 2002 22:51:42 +0200
Lines: 24
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

>   - mention a few different kinds of automatic responses -

       - assignment of a tracking number or a similar identifier

> III. Format of automatic responses
>     - envelope return address (avoid loops!)
>     - headers (to, from, subject, auto-submitted)
>     - content (should probably limit size, content to limit
>       DoS attack potential - e.g. should not allow sender to
>       use the responder as a relay for viruses)

      - proper MIME encapsulation (?)

> VI. security considerations
> 	- DoS attack through mail loops
> 	- DoS attack through large #s of requests
> 	- DoS attack by using responder to flood large #s of mailboxes
> 	- attack by using responder to relay harmful/abusive content
> 	- requests by unauthorized parties

        - privacy risks of out-of-office notifications (coworker names
          make social engineering easier)

To: "Eric A. Hall" <[email-masked]>
Cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: I-D on automatic responses
From: Florian Weimer <[email-masked]>
Mail-Followup-To: "Eric A. Hall" <[email-masked]>, Keith Moore <[email-masked]>,  Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>,  [email-masked]
Date: Tue, 04 Jun 2002 22:47:45 +0200
Lines: 6
Sender: [email-masked]

"Eric A. Hall" <[email-masked]> writes:

>   maintain db of respondents, recommended minimum of once per week

ITYM "at most one message per week" (we want to establish an upper
bound on the notification rate, not a lower bound)

Date: Tue, 04 Jun 2002 15:42:14 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: I-D on automatic responses
Sender: [email-masked]

Keith Moore wrote:
> 
> >  I also wanted to provide a Return-Date
> > header which could optionally be used by MUAs to flag an entry in the
> > address book ("is away until mm/dd") or by mailing lists to suspend
> > delivery automagically.
> 
> the last bit seems dubious - just because I won't respond to mail
> for some period of time doesn't mean I don't want it to be sent to me.

If you don't implement the other features, this one provides a reasonable
escape hatch to the list owner. After 3 or 4 oof/notification messages in
a single day, flag the account.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: I-D on automatic responses 
Date: Tue, 04 Jun 2002 16:37:00 -0400
Sender: [email-masked]

>  I also wanted to provide a Return-Date
> header which could optionally be used by MUAs to flag an entry in the
> address book ("is away until mm/dd") or by mailing lists to suspend
> delivery automagically.

the last bit seems dubious - just because I won't respond to mail
for some period of time doesn't mean I don't want it to be sent to me.

Date: Tue, 04 Jun 2002 15:35:07 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: I-D on automatic responses
Sender: [email-masked]

Keith Moore wrote:

> anything else?

Unless I missed them:

  no autoreplies to owner-* or *-request

  maintain db of respondents, recommended minimum of once per week

One other optional thing is message/vacation-notification media-type for
use with multipart/report. Apart from the normal body fields
(Original-Recipient especially), I also wanted to provide a Return-Date
header which could optionally be used by MUAs to flag an entry in the
address book ("is away until mm/dd") or by mailing lists to suspend
delivery automagically.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Tue, 04 Jun 2002 13:12:45 -0700 (PDT)
From: [email-masked]
Subject: Re: Sieve
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > That's precisely the reason that the MAIL FROM address is exposed in the
> > message header as return-path - so the address can be used for automatic
> > responses that are generated after the message leaves the transport/delivery
> > system.

> Ah, this is new in RFC 2821.

Actually, a slightly weaker form of this requirement is present in RFC 1123.
Section 5.2.8 says, in part:

         When the receiver-SMTP makes "final delivery" of a message,
         then it MUST pass the MAIL FROM: address from the SMTP envelope
         with the message, for use if an error notification message must
         be sent later ...

and then:

         IMPLEMENTATION:
              The MAIL FROM: information may be passed as a parameter or
              in a Return-Path: line inserted at the beginning of the
              message.

RFC 2821 makes it explicit that this has to be done with a return-path field;
an improvement IMO.

> Nice, however it doesn't seem to be implemented widely.

Hmm. My impression has been the exact opposite. Specifically, I know that PMDF
and iMS (MTAs I've worked on) add such a field, and I believe sendmail, qmail,
MMDF, PP, exim, and even Exchange do so as well.

				Ned

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 16:26:46 -0400
Sender: [email-masked]

> EG, perhaps my ISP
> enforces draconian AUTH<->reverse-path matching, and being able to use a
> different reverse-path than the From: header would be a viable and fully
> legitimate (still traceable) solution to that problem.

the solution here is to get another ISP.
the mail protocol can't be expected to fix ISP brain-damage.
 
Keith

From: Keith Moore <[email-masked]>
To: "Dan Wing" <[email-masked]>
cc: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, [email-masked]
Subject: I-D on automatic responses
Subject-was: Re: Sieve 
Date: Tue, 04 Jun 2002 16:25:34 -0400
Sender: [email-masked]

> If we have consensus on this, it'd be nice to do an I-D on it.  How to
> do Vacation correctly comes up about once a year.

Okay, how about an I-D on automatic responses to email?  

offhand, seems like it should discuss the following:

I. Introduction
  - discuss the need to specify recommendations for behavior 
    of automatic responses - e.g.
    avoid sending useless/unwanted responses 
    avoid sending responses to the "wrong place"
    avoid mail loops and sorcerer's apprentice syndrome   

II. Types of automatic responses
  - distinguish between automatic responses and DSNs and MDNs
    (which are covered elsewhere)

  - distinguish between mail robots whose response is anticipated
    by the sender (sender sends to that address knowing that it will
    automatically respond), vs. mail robots that respond on behalf
    of a human recipient:
    
  - mention a few different kinds of automatic responses -
    - mail robots that accept requests from humans and send back responses
      (e.g. subscribe to a list, retrieve a file, 
       convert this fortran program to c)
    - out-of-office notices (that don't reply to every message)
    - use of email to communicate between two applications
    - anti-spam responses (e.g. you must reply showing signs of 
      intelligent life before I'll read your previous message)
    - virus scanners

III. Format of automatic responses
    - envelope return address (avoid loops!)
    - headers (to, from, subject, auto-submitted)
    - content (should probably limit size, content to limit
      DoS attack potential - e.g. should not allow sender to
      use the responder as a relay for viruses)

IV. When to send automatic responses

    general: care should be taken to avoid sending needless or
    redundant responses

    examples:

    - mail robots that accept requests and issue responses
	- presumably, one response for each request
    - out-of-office notices 
	- avoid sending multiple responses within N days
	- avoid sending responses unless recipient is in to/cc/bcc field
    - communication between applications
    - anti-spam responses
	- should not be issued for each message sent  
    - virus scanners - only the first time a sender sends a virus

V. Where to send automatic responses

   return-path header field.  if it's not valid, don't respond!

   if no return-path header field, *your* mail system is broken.  fix it.

   why use of other fields is generally a bad idea:

   - reply-to - sender sets reply-to based on the *anticipated*
	response of a human recipient to the content of a message,
        automatic response probably doesn't qualify.
        sometimes reply-to goes (directly or indirectly)
	to large #s of people - responder should not assume
	they all want the response.
   - from - indicates the person/persons on whose behalf the message
	is sent - doesn't necessarily mean they want to see replies.
	a human may redirect manual/personal replies using reply-to,
	automatic replies should still not go to from.
   - sender - not really intended for replies, not guaranteed to be
	valid - often misued by setting to list address
   - to and cc - responder should not assume that other recipients
	of the subject message need to see response.

   also, any address in the to, cc, from, reply-to field might be
   the address of a list for good and valid reasons - return-path
   is the only address which is intended to receive automatic responses,
   and it's reasonable to expect the sender to set that address
   correctly (in SMTP MAIL FROM)

VI. security considerations
	- DoS attack through mail loops
	- DoS attack through large #s of requests
	- DoS attack by using responder to flood large #s of mailboxes
	- attack by using responder to relay harmful/abusive content
	- requests by unauthorized parties

anything else?

Keith

To: Dave Crocker <[email-masked]>
Cc: [email-masked]
Subject: Re: Choosing recipient of automatic replies
From: Florian Weimer <[email-masked]>
Mail-Followup-To: Dave Crocker <[email-masked]>, [email-masked]
Date: Tue, 04 Jun 2002 22:18:47 +0200
Lines: 7
Sender: [email-masked]

Dave Crocker <[email-masked]> writes:

> The important distinction is between a reply by the transport service,
> about transmission, versus a reply by an email-based application,
> about an activity of the application.

What about a mailing list?  The application itself is a transport. ;-)

Date: Tue, 04 Jun 2002 13:09:38 -0700 (PDT)
From: [email-masked]
Subject: RE: Sieve
To: Dan Wing <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> > > Keith is arguing that the decisions and permutations are too hard, and
> > > the Return-Path should be used.
> >
> > That would certainly be a reasonable position. It would seem that every
> > other argument has some kind of failing exception.

> If we have consensus on this, it'd be nice to do an I-D on it.  How to
> do Vacation correctly comes up about once a year.

We had a vacation draft for sieve that covered this but it expired. I'll see
if I can't get the author to resurrect it.

				Ned

To: "Moore, Tom J" <[email-masked]>
Cc: "'Dan Wing'" <[email-masked]>, "Eric A. Hall" <[email-masked]>, Keith Moore <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Sieve
From: Florian Weimer <[email-masked]>
Mail-Followup-To: "Moore, Tom J" <[email-masked]>, 'Dan Wing' <[email-masked]>,  "Eric A. Hall" <[email-masked]>, Keith Moore <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>,  [email-masked]
Date: Tue, 04 Jun 2002 22:07:17 +0200
Lines: 7
Sender: [email-masked]

"Moore, Tom J" <[email-masked]> writes:

["How to get OOONs right"]

> And just maybe Microsoft will read it.  :-(

And IBM's Lotus division.

From: "Moore, Tom J" <[email-masked]>
To: "'Dan Wing'" <[email-masked]>, "'Eric A. Hall'" <[email-masked]>
Cc: "'Keith Moore'" <[email-masked]>, "'Lawrence Greenfield'" <[email-masked]>, "'Dave Crocker'" <[email-masked]>, "'Florian Weimer'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 16:07:28 -0400 
Sender: [email-masked]

And just maybe Microsoft will read it.  :-(

Tom

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: Tuesday, June 04, 2002 3:59 PM
To: Eric A. Hall
Cc: Keith Moore; Lawrence Greenfield; Dave Crocker; Florian Weimer;
[email-masked]
Subject: RE: Sieve

> > Keith is arguing that the decisions and permutations are too hard, and
> > the Return-Path should be used.
> 
> That would certainly be a reasonable position. It would seem that every
> other argument has some kind of failing exception.

If we have consensus on this, it'd be nice to do an I-D on it.  How to
do Vacation correctly comes up about once a year.

-d

Date: Tue, 04 Jun 2002 15:07:18 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Keith Moore wrote:

> > > Return-Path: bounce-address  (set on delivery from MAIL FROM)

> why should the secretary get *what*?

Sorry, I missed the header.

Of course using the null reverse-path is an option for anybody, so I'm not
sure what this argument proves, other than it would be nice for messaging
systems to implement a feature that none of them currently offer.

> if in sending such a message person A fails to recognize that
> MAIL FROM should be set up as appropriate to receive any automatic
> responses that might result from that message, person A has
> failed to use the mail protocol correctly.

It would be a lovely feature for other reasons as well. EG, perhaps my ISP
enforces draconian AUTH<->reverse-path matching, and being able to use a
different reverse-path than the From: header would be a viable and fully
legitimate (still traceable) solution to that problem.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: "Dan Wing" <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, <[email-masked]>
Subject: Re: Sieve
From: Florian Weimer <[email-masked]>
Mail-Followup-To: "Dan Wing" <[email-masked]>, "Eric A. Hall" <[email-masked]>,  "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>,  <[email-masked]>
Date: Tue, 04 Jun 2002 22:06:14 +0200
Lines: 9
Sender: [email-masked]

"Dan Wing" <[email-masked]> writes:

> If we have consensus on this, it'd be nice to do an I-D on it.  How
> to do Vacation correctly comes up about once a year.

Yes, and the industry doesn't get it right. :-(

Such reference material could encourage customers to complain to their
vendors more loudly.

From: Keith Moore <[email-masked]>
To: Florian Weimer <[email-masked]>
cc: Keith Moore <[email-masked]>, "Eric A. Hall" <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 16:02:49 -0400
Sender: [email-masked]

> Gateways from RFC 821 to other protocols
> (essentially, a UNIX delivery agent is such a gateway) tend to throw
> away envelope (To) addresses and keep header addresses only.

the envelope addresses of other recipients are typically unavailable
to such gateways anyway.  SMTP doesn't communicate the envelope address
of each recipient to each MTA - the only envelope addresses sent to
an MTA are those for which *that MTA* is responsible for delivery.

> > That's precisely the reason that the MAIL FROM address is exposed in the
> > message header as return-path - so the address can be used for automatic
> > responses that are generated after the message leaves the transport/delivery
> > system.
> 
> Ah, this is new in RFC 2821.  Nice, however it doesn't seem to be
> implemented widely.

no, it's in RFC 821 also.  however it's true that many MTAs don't 
implement it correctly.

Keth

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 12:59:23 -0700
Importance: Normal
Sender: [email-masked]

> > Keith is arguing that the decisions and permutations are too hard, and
> > the Return-Path should be used.
> 
> That would certainly be a reasonable position. It would seem that every
> other argument has some kind of failing exception.

If we have consensus on this, it'd be nice to do an I-D on it.  How to
do Vacation correctly comes up about once a year.

-d

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 15:58:26 -0400
Sender: [email-masked]

> > You're assuming too much.  Just because a message is sent by someone's
> > authority does NOT mean that they want to receive any kind of automatic
> > notifications.  It would be perfectly reasonable for a CEO to send out
> > a message of the form:
> > 
> > From: CEO
> > Reply-to: customer-relations
> > Sender: secretary
> > Return-Path: bounce-address  (set on delivery from MAIL FROM)
> > To: customers:;
> 
> Why should the secretary get them? 

why should the secretary get *what*?  NOTHING should get sent to the
address in the Sender field.  the only purpose of that field is to 
identify who actually caused the message to be sent; it's not intended
to be used for responses.

> You are essentially arguing that the messaging applications
> should not communicate on the off-chance that the boss might get annoyed
> one day.

no, I'm arguing that messaging applications that issue automatic responses
should not make unwarranted assumptions about the roles of those whose
addresses appear in any field other than the return-path field.

> What if my boss sends a message to the staff on *my* behalf. What then?

if person A sends a message on person B's behalf, whether that is 
appropriate is an issue for person B to decide.  it's not an issue 
for the mail protocol.

if in sending such a message person A fails to recognize that 
MAIL FROM should be set up as appropriate to receive any automatic
responses that might result from that message, person A has
failed to use the mail protocol correctly.

OTOH, if person A does recognize that, and sets up MAIL FROM in 
such a way as to direct those responses to an inappropriate place - 
that's abuse/misuse, not a failure to use the protocol.

Keith

To: Keith Moore <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Sieve
From: Florian Weimer <[email-masked]>
Mail-Followup-To: Keith Moore <[email-masked]>, "Eric A. Hall" <[email-masked]>,  Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>,  [email-masked]
Date: Tue, 04 Jun 2002 21:56:29 +0200
Lines: 29
Sender: [email-masked]

Keith Moore <[email-masked]> writes:

> VERP isn't well-designed then. a recipient-unique envelope return address 
> is useful, but it's unwise to expect that every message sent to that 
> address is a nondelivery report - there is absolutely nothing in the mail 
> specifications that says that only nondelivery reports should go to that 
> address.

It's a fact that most user agents don't know much (if anything) about
envelope addresses, and I can't think of one which offers a "reply to
envelope address" command.  Gateways from RFC 821 to other protocols
(essentially, a UNIX delivery agent is such a gateway) tend to throw
away envelope (To) addresses and keep header addresses only.

If the mailing list is for announcements only, you can add a Reply-To
header to divert messages from real people (and unfortunately, some
out-of-office notifications) to a suitable account, and the remaining
mail to the envelope from should come from an automated service.
Actually, you don't care which one--if your mailing list is so large
that you can't afford dealing with bouncing addresses manually, a lost
subscriber doesn't matter at all. ;-)

> That's precisely the reason that the MAIL FROM address is exposed in the 
> message header as return-path - so the address can be used for automatic 
> responses that are generated after the message leaves the transport/delivery 
> system.

Ah, this is new in RFC 2821.  Nice, however it doesn't seem to be
implemented widely.

Date: Tue, 04 Jun 2002 14:52:29 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dan Wing <[email-masked]>
CC: Keith Moore <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Dan Wing wrote:

> Keith is arguing that the decisions and permutations are too hard, and
> the Return-Path should be used.

That would certainly be a reasonable position. It would seem that every
other argument has some kind of failing exception.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 12:45:33 -0700
Importance: Normal
Sender: [email-masked]

> Keith Moore wrote:
> 
> > You're assuming too much.  Just because a message is sent by someone's
> > authority does NOT mean that they want to receive any kind of automatic
> > notifications.  It would be perfectly reasonable for a CEO to send out
> > a message of the form:
> > 
> > From: CEO
> > Reply-to: customer-relations
> > Sender: secretary
> > Return-Path: bounce-address  (set on delivery from MAIL FROM)
> > To: customers:;
> 
> Why should the secretary get them? Why shouldn't the customer-relations
> get them? You are essentially arguing that the messaging applications
> should not communicate on the off-chance that the boss might get annoyed
> one day.

Keith is arguing that the decisions and permutations are too hard, and
the Return-Path should be used.

> What if my boss sends a message to the staff on *my* behalf. What then?

NDNs and vacation notices go to Return-Path, which is set appropriately
based on whoever wants to receive NDNs, vacation notices, and delay
warnings.

-d

From: "Dan Wing" <[email-masked]>
To: "Florian Weimer" <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 12:43:37 -0700
Importance: Normal
Sender: [email-masked]

> > Imagine the case of exactly this thread, where several people are
> > on the To/CC line, and the [email-masked] mailing list is also
> > on the To/CC line.  If a vacation program did a reply-all, the
> > vacation notice would go to the ietf-822 mailing list.
> 
> Virus scanners do this (some even in their default configurations, it
> seems), and it's really annoying. 

Yeah, I have seen this behavior on the main IETF list a time or two.

> Autoreplies sent to Cc: or To:
> fields is never a good idea because the software cannot know the
> semantics of the addresses.

-d

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 12:41:35 -0700
Importance: Normal
Sender: [email-masked]

> > It's never appropriate to send vacation notices to the entire list
> > of mailboxes in the To/CC.
>
> I am only postulating for specific scenarios, eg new threads (no "Re:").

Well, let's postulate that I send mail to the author of RFC2822 (Peter
Resnick) and CC [email-masked], asking for clarification on a section
of RFC2822.  This wouldn't have a "Re:".

It would be like:

  return-path: <[email-masked]>
  to: [email-masked]
  cc: [email-masked]
  from: [email-masked]

And if Pete has a vacation program that does a reply-all, I think
there would be significant outcry on the mailing list.

> Also, the message you sent to me had two To: recipients.

I don't understand the distinction you're making regarding multiple recipients
in To:.

-d

Date: Tue, 04 Jun 2002 14:42:29 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Keith Moore wrote:

> You're assuming too much.  Just because a message is sent by someone's
> authority does NOT mean that they want to receive any kind of automatic
> notifications.  It would be perfectly reasonable for a CEO to send out
> a message of the form:
> 
> From: CEO
> Reply-to: customer-relations
> Sender: secretary
> Return-Path: bounce-address  (set on delivery from MAIL FROM)
> To: customers:;

Why should the secretary get them? Why shouldn't the customer-relations
get them? You are essentially arguing that the messaging applications
should not communicate on the off-chance that the boss might get annoyed
one day.

What if my boss sends a message to the staff on *my* behalf. What then?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: "Dan Wing" <[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, <[email-masked]>
Subject: Re: Sieve
From: Florian Weimer <[email-masked]>
Mail-Followup-To: "Dan Wing" <[email-masked]>, "Eric A. Hall" <[email-masked]>,  "Keith Moore" <[email-masked]>, "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>,  <[email-masked]>
Date: Tue, 04 Jun 2002 21:39:19 +0200
Lines: 11
Sender: [email-masked]

"Dan Wing" <[email-masked]> writes:

> Imagine the case of exactly this thread, where several people are
> on the To/CC line, and the [email-masked] mailing list is also
> on the To/CC line.  If a vacation program did a reply-all, the
> vacation notice would go to the ietf-822 mailing list.

Virus scanners do this (some even in their default configurations, it
seems), and it's really annoying.  Autoreplies sent to Cc: or To:
fields is never a good idea because the software cannot know the
semantics of the addresses.

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 15:35:25 -0400
Sender: [email-masked]

> > that's part of why sending the response to the return-path address is
> > better - it's more likely to reach someone who can actually make use
> > of the response.
> 
> But they are not always the most useful target.
> 
> Consider an original message which has a From: PHB and CC: HR, and where
> the recipient is the only address listed in To:. It is reasonable for an
> out-of-office notification to go to the From: and CC: parties, since this
> message is specifically intended for the recipient 

No, it's not reasonable for an autoresponder to make such assumptions, 
because the autoresponder has no idea about the purpose of the message
or the roles of those whose addresses are in the From or CC lines.  
(heck, even I can't guess what PHB means)

The only thing the autoresponder knows is that the return-path address
should be set up to receive automatic replies.

It's the responsibility of the sender to ensure that MAIL FROM is set
to an address which is useful for this purpose.

> (given the other people
> in the distribution, it would be a damn good idea to send it to all of
> them). It is not entirely logical to send the message to the secretary
> mailbox in the reverse-path. The secretary doesn't care.

perhaps unfortunately (but probably not), we don't have a separate address
for every discrete purpose, so we don't have one for out-of-office responses.  
four different response addresses (five, if you count List-whatever)
seems to be more than we can handle.  

Keith

Date: Tue, 04 Jun 2002 14:32:53 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dan Wing <[email-masked]>
CC: Keith Moore <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Dan Wing wrote:

> It's never appropriate to send vacation notices to the entire list
> of mailboxes in the To/CC.

I am only postulating for specific scenarios, eg new threads (no "Re:").
Also, the message you sent to me had two To: recipients.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

To: "Eric A. Hall" <[email-masked]>
Cc: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, [email-masked]
Subject: Re: Sieve
From: Florian Weimer <[email-masked]>
Mail-Followup-To: "Eric A. Hall" <[email-masked]>, Dan Wing <[email-masked]>,  Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>,  [email-masked]
Date: Tue, 04 Jun 2002 21:29:29 +0200
Lines: 32
Sender: [email-masked]

"Eric A. Hall" <[email-masked]> writes:

> If the reverse-path has been misconfigured to reference an inappropriate
> mailbox (eg, list-request@domain) then this might even happen
> automatically. This is *designed* to happen automatically with mailing
> lists that use VERP and similar proposals:
>
>  |                                         The VERP extension implements
>  | a way of automatically identifying undeliverable mail recipients,
>  | even when non-delivery reports originate from mail systems that do
>  | not implement delivery status notifications

VERP is basically dead for practical purposes.

At work, we run a small read-only mailing list which mainly targets
German IT workers.  Apparently, many larger institutions gateway mail
from RFC 821/822 format to some X.400 derivate or proprietary mail
implementations, and these gateways throw away the distinction between
envelope address and header address.

As a result, even delivery failure notifications are regularly sent to
the address in the From: header, not just the regular stream of
out-of-office notifications during school vacations.

> Even outside the list world, there are scenarios where sending to the
> reverse-path is inappropriate. EG, when the Sender/From construct is
> actually used, the notification is returned to the Sender instead of the
> From parties.

At least one (not too popular) mail client puts unrouteable addresses
in Sender: fields if the user changes the From: address from the
default. :-(

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 15:28:48 -0400
Sender: [email-masked]

> Dan Wing wrote:
> 
> > Simplistic implementations of auto-unsubscribe will likewise have
> > issues with unable-to-send-for-8-hours informational messages, such
> > as are common with many sendmail configurations.  I expect that any
> > auto-unsubscribe system will have to deal with those informational
> > messages (which are sent to the envelope-from).
> 
> To be clear, I'm not endorsing VERP. Having said that, the idea is to
> catch notifications which are not DSNs. Status: Delayed can be trapped
> easily. I would ass-u-me that implementors also look for WARNING: and
> other magic strings appropriately. At that point the question would be
> about the ~thresholds for any kind of auto-unsub action that might take
> place.

If you parse the message enough to be sure that it is a nondelivery report 
(whether a DSN or not) and treat it as such, I have no problem with that.
But it's foolish to treat unrecognized messages as if they were nondelivery 
reports.

> I would argue that Sender: secretary should receive the delivery failure
> notification but From: PHB should receive the out-of-office notification.

You're assuming too much.  Just because a message is sent by someone's
authority does NOT mean that they want to receive any kind of automatic
notifications.  It would be perfectly reasonable for a CEO to send out
a message of the form:

From: CEO
Reply-to: customer-relations
Sender: secretary
Return-Path: bounce-address  (set on delivery from MAIL FROM)
To: customers:;

>From says who authorized sending of the message, or on whose behalf the 
message is to be sent, but he/she has asked that replies go elsewhere.

Sender says who sent the message, but this is mostly to identify the
responsible party - responses should essentially never go there.

Essentially all automatic notifications should go to Return-Path.

Replies (made by humans, and based on the actual content of the message) 
should go to Reply-To.  

Now if the secretary wants to review the automatic response messages, 
he/she can either arrange for the return-path to point to a mailbox 
where the responses can be collected and reviewed, or he/she can 
put his/her own address in return-path.

> Delay DSNs are management messages, IMO. I would have argued against MDNs
> using the envelope data though.

As far as I can tell, the best criteria for when to use Reply-To/From
instead of Return-Path are:

- if the message is a manual response, made by a human, based on the
  content of the message and the kind of response that the sender of 
  that message anticipated, send the message to the Reply-To address.

  other recipients of the subject message may be cc'ed if appropriate
  but this should not be assumed.

  (e.g. a reply to an invitation to a meeting or social function)

- if the message is a manual response, made by a human, based on the
  content of the message but is a kind of response unlikely to have
  been anticipated by the sender, the above rule does not apply.
  the respondent must use his/her best judgement when deciding where
  to send such responses, keeping in mind the intended purposes of
  From, Sender, Reply-To, and Return-Path. 

  (e.g. a reply to an invitation where the purpose of the reply is to
  discretely point out a faux pas on the part of the party who
  issued that invitation.  anticipated responses - such as acceptances
  or regrets - should go to the reply-to address.)
   
- if the message is an automatic response, it should go to the 
  return-path address.

the above is a more of a statement about etiquette between humans
rather than about either user interface or protocol between computers.
to the extent that the user interfaces and mail protocols don't
support reasonable exchanges between humans, they need to be clarified
or changed.

Keith

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>, "Keith Moore" <[email-masked]>
Cc: "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 12:26:53 -0700
Importance: Normal
Sender: [email-masked]

> > that's part of why sending the response to the return-path address is
> > better - it's more likely to reach someone who can actually make use
> > of the response.
> 
> But they are not always the most useful target.
> 
> Consider an original message which has a From: PHB and CC: HR, and where
> the recipient is the only address listed in To:. It is reasonable for an
> out-of-office notification to go to the From: and CC: parties, since this
> message is specifically intended for the recipient (given the other people
> in the distribution, it would be a damn good idea to send it to all of
> them). It is not entirely logical to send the message to the secretary
> mailbox in the reverse-path. The secretary doesn't care.

It's never appropriate to send vacation notices to the entire list
of mailboxes in the To/CC.

Imagine the case of exactly this thread, where several people are
on the To/CC line, and the [email-masked] mailing list is also
on the To/CC line.  If a vacation program did a reply-all, the
vacation notice would go to the ietf-822 mailing list.

-d

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 12:24:11 -0700
Importance: Normal
Sender: [email-masked]

> > So you're saying a boss, who delegated a menial task like sending mail
> > to 1,000 employees, actually wants to see the 50 or so vacation notices
> > from 50 employees?  That's an interesting boss.
> 
> "wants to see them" is something else. I am only arguing that the
> secretary has no reason to see them as part of the delegated task.

If the pointy-haired-boss (PHB) delegated transmission of the message,
I don't understand why the PHB wouldn't also delegate calling folks
at home (while they're on vacation) to ensure they have received the
important email message -- just like the PHB has delegated non-
delivery notices to the secretary by virtue of having the secretary
use Sender/From.

> > As for the vacation notices being essentially delivery acknowledgements,
> > I'll point to MDN (RFC2298) which correlation MDN behavior between
> > the Envelope-from address and the disposition-notification-to address
> > -- the correlation isn't between the header From address and the
> > disposition-notification-to address.
> 
> I know, I said I would have argued against that as well. MDNs are also
> applications of the network and not management messages.
> 
> In my world view, DSNs are equivalent to ICMP messages, in that provide a
> way for the network to inform the nodes that something will not succeed so
> stop trying (or in the case of delays, that something is taking longer
> than expected). From this perspective, passing around application-layer
> acks and responses (such as MDNs and out-of-office notifications) between
> the network nodes instead of between the application end-points is a
> fundamental layering violation. There is no reason to tell the network
> nodes about an application issue, and its almost always the wrong choice.

I still don't see the case where sending a vacation notice to the
envelope-from causes a problem.  I do see cases where sending a vacation
notice to From: causes a problem -- such as in the very case we're
arguing, where a secretary sends a message to 1000 employees and the
boss doesn't care who is on vacation nor does the boss care who has
an invalid email address nor does the boss care who has a down 
mailer and hasn't received the message in 5 hours.

-d

Date: Tue, 04 Jun 2002 14:23:36 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Keith Moore wrote:

> that's part of why sending the response to the return-path address is
> better - it's more likely to reach someone who can actually make use
> of the response.

But they are not always the most useful target.

Consider an original message which has a From: PHB and CC: HR, and where
the recipient is the only address listed in To:. It is reasonable for an
out-of-office notification to go to the From: and CC: parties, since this
message is specifically intended for the recipient (given the other people
in the distribution, it would be a damn good idea to send it to all of
them). It is not entirely logical to send the message to the secretary
mailbox in the reverse-path. The secretary doesn't care.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 15:11:19 -0400
Sender: [email-masked]

> > no, "management" vs. "application" messages is not where the line should
> > be drawn.  Return-Path is provided so that applications can use it when
> > it's appropriate.  Most automatic responses should go to Return-Path.
> 
> What if there are multiple addresses in From: and Sender: was just the
> messenger, or what if From: is a group address? 

that's part of why sending the response to the return-path address is
better - it's more likely to reach someone who can actually make use
of the response.

> The application acks fall
> apart if basic features of the messaging network are used but the
> application sends its ack to the node instead of the application

if the sending application is putting anything in the MAIL FROM
field other than an address which will reach the sending 
application, the sending application is broken.

Keith

Date: Tue, 04 Jun 2002 14:06:58 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Keith Moore wrote:

> no, "management" vs. "application" messages is not where the line should
> be drawn.  Return-Path is provided so that applications can use it when
> it's appropriate.  Most automatic responses should go to Return-Path.

What if there are multiple addresses in From: and Sender: was just the
messenger, or what if From: is a group address? The application acks fall
apart if basic features of the messaging network are used but the
application sends its ack to the node instead of the application

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Tue, 04 Jun 2002 13:58:38 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dan Wing <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Dan Wing wrote:

> So you're saying a boss, who delegated a menial task like sending mail
> to 1,000 employees, actually wants to see the 50 or so vacation notices
> from 50 employees?  That's an interesting boss.

"wants to see them" is something else. I am only arguing that the
secretary has no reason to see them as part of the delegated task.

> As for the vacation notices being essentially delivery acknowledgements,
> I'll point to MDN (RFC2298) which correlation MDN behavior between
> the Envelope-from address and the disposition-notification-to address
> -- the correlation isn't between the header From address and the
> disposition-notification-to address.

I know, I said I would have argued against that as well. MDNs are also
applications of the network and not management messages.

In my world view, DSNs are equivalent to ICMP messages, in that provide a
way for the network to inform the nodes that something will not succeed so
stop trying (or in the case of delays, that something is taking longer
than expected). From this perspective, passing around application-layer
acks and responses (such as MDNs and out-of-office notifications) between
the network nodes instead of between the application end-points is a
fundamental layering violation. There is no reason to tell the network
nodes about an application issue, and its almost always the wrong choice.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Tue, 4 Jun 2002 14:52:06 -0400
From: Lawrence Greenfield <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked], Florian Weimer <[email-masked]>, Dave Crocker <[email-masked]>, Dan Wing <[email-masked]>, Keith Moore <[email-masked]>, "Eric A. Hall" <[email-masked]>
Subject: Re: Sieve 
Sender: [email-masked]

   From: Keith Moore <[email-masked]>
   Date: Tue, 04 Jun 2002 14:47:59 -0400
[...]
   > We're not disagreeing here. Management messages should use the envelope,
   > and the reverse-path is provided to the application through Return-Path
   > header field. Meanwhile, application messages (replies, content filters,
   > and yes out-of-office notifications) should use the application headers,
   > (ala From/Reply-To).

   no, "management" vs. "application" messages is not where the line should 
   be drawn.  Return-Path is provided so that applications can use it when
   it's appropriate.  Most automatic responses should go to Return-Path.

I believe Dave was agreeing with Eric here that "out-of-office"
notifications should use the From/Reply-to.  I don't think I
understand Dave's reasoning, so I'd kinda another explanation to get
it through my head.

I (and my implementation) agree with Keith and Dan that using the
return-path is preferable.

Larry

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 14:47:59 -0400
Sender: [email-masked]

> > > Even outside the list world, there are scenarios where sending to the
> > > reverse-path is inappropriate. EG, when the Sender/From construct is
> > > actually used, the notification is returned to the Sender instead of
> > > the From parties.
> > 
> > That's a bug in RFC 822.  Nondelivery reports should always go to the
> > Return-path/MAIL FROM address, NEVER to the Sender address.  The
> > contents of the Sender field aren't even required to be a legal address.
> 
> The reverse-path is almost always the same mailbox address as the message
> sender (as specified in Sender, when it is actually present). In that
> regard, the reverse-path will point to the Sender rather than From.

correct.  but you get this address from the Return-Path field, not the
Sender field.

> > > These examples are all really beside the ultimate point, however:
> > > out-of-office notifications are an application of the messaging network
> > > and not in-band management messages, so they really should use the
> > > headers rather than the envelope.
> > 
> > That's precisely the reason that the MAIL FROM address is exposed in the
> > message header as return-path - so the address can be used for automatic
> > responses that are generated after the message leaves the
> > transport/delivery  system.
> 
> We're not disagreeing here. Management messages should use the envelope,
> and the reverse-path is provided to the application through Return-Path
> header field. Meanwhile, application messages (replies, content filters,
> and yes out-of-office notifications) should use the application headers,
> (ala From/Reply-To).

no, "management" vs. "application" messages is not where the line should 
be drawn.  Return-Path is provided so that applications can use it when
it's appropriate.  Most automatic responses should go to Return-Path.

Keith

Date: Tue, 04 Jun 2002 13:30:18 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dan Wing <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Dan Wing wrote:

> Simplistic implementations of auto-unsubscribe will likewise have
> issues with unable-to-send-for-8-hours informational messages, such
> as are common with many sendmail configurations.  I expect that any
> auto-unsubscribe system will have to deal with those informational
> messages (which are sent to the envelope-from).

To be clear, I'm not endorsing VERP. Having said that, the idea is to
catch notifications which are not DSNs. Status: Delayed can be trapped
easily. I would ass-u-me that implementors also look for WARNING: and
other magic strings appropriately. At that point the question would be
about the ~thresholds for any kind of auto-unsub action that might take
place.

By the same token, if you annoy the list owner, where is their threshold?

> Sender/From is classically described for use with a secretary and an
> executive:  the secretary would be Sender, the executive would be From.
> In that case, I argue the executive isn't interested in NDNs (or
> vacation notices) and thus the return-path should be the sender.
> This causes NDNs to be sent to the secretary.  Likewise, if
> vacation notices are sent to the return-path (as vacation works
> on Unix), the vacation notices are sent to the secretary (Sender).
> 
> I believe you're arguing that the executive should see the NDNs and
> should see the vacation messages for a Sender/From message?

I would argue that Sender: secretary should receive the delivery failure
notification but From: PHB should receive the out-of-office notification.
In the scenario above, the secretary is tasked with getting the message to
the recipient, and dealing with addressing and/or delivery errors is part
of that task. On the other hand, an o-o-f notification is essentially an
acknowledgment that delivery succeeded, which is interesting to the task
but not particularly relevant.

> > I might be using a terminal or kiosk with a reverse-path referencing
> > the mobile account, but with From pointing to my master mailstore. I
> > may not see the notification messages for several months, if ever.
> 
> You won't see NDNs, either.

Yeah, good point.

> > These examples are all really beside the ultimate point, however:
> > out-of-office notifications are an application of the messaging network
> > and not in-band management messages, so they really should use the
> > headers rather than the envelope.
> 
> What of NOTIFY=DELAY, then, and its default usage in many mailers,
> including sendmail (which implements the behavior of NOTIFY=DELAY
> by default).

Delay DSNs are management messages, IMO. I would have argued against MDNs
using the envelope data though.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Tue, 04 Jun 2002 13:28:57 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Keith Moore wrote:

> > Even outside the list world, there are scenarios where sending to the
> > reverse-path is inappropriate. EG, when the Sender/From construct is
> > actually used, the notification is returned to the Sender instead of
> > the From parties.
> 
> That's a bug in RFC 822.  Nondelivery reports should always go to the
> Return-path/MAIL FROM address, NEVER to the Sender address.  The
> contents of the Sender field aren't even required to be a legal address.

The reverse-path is almost always the same mailbox address as the message
sender (as specified in Sender, when it is actually present). In that
regard, the reverse-path will point to the Sender rather than From.

> > These examples are all really beside the ultimate point, however:
> > out-of-office notifications are an application of the messaging network
> > and not in-band management messages, so they really should use the
> > headers rather than the envelope.
> 
> That's precisely the reason that the MAIL FROM address is exposed in the
> message header as return-path - so the address can be used for automatic
> responses that are generated after the message leaves the
> transport/delivery  system.

We're not disagreeing here. Management messages should use the envelope,
and the reverse-path is provided to the application through Return-Path
header field. Meanwhile, application messages (replies, content filters,
and yes out-of-office notifications) should use the application headers,
(ala From/Reply-To).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Dan Wing <[email-masked]>, Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve 
Date: Tue, 04 Jun 2002 14:13:56 -0400
Sender: [email-masked]

> Even if the reverse-path has been rewritten to reference an appropriate
> mailbox, the owner of the mailing list is likely to be uninterested in the
> sender's vacation plans. After enough of these, the owner may even
> manually pause or remove the sender from the list, resulting in the same
> effect.
> 
> If the reverse-path has been misconfigured to reference an inappropriate
> mailbox (eg, list-request@domain) then this might even happen
> automatically. This is *designed* to happen automatically with mailing
> lists that use VERP and similar proposals:

VERP isn't well-designed then. a recipient-unique envelope return address 
is useful, but it's unwise to expect that every message sent to that 
address is a nondelivery report - there is absolutely nothing in the mail 
specifications that says that only nondelivery reports should go to that 
address.

>  |                                         The VERP extension implements
>  | a way of automatically identifying undeliverable mail recipients,
>  | even when non-delivery reports originate from mail systems that do
>  | not implement delivery status notifications
> 
> Even outside the list world, there are scenarios where sending to the
> reverse-path is inappropriate. EG, when the Sender/From construct is
> actually used, the notification is returned to the Sender instead of the
> From parties.

That's a bug in RFC 822.  Nondelivery reports should always go to the 
Return-path/MAIL FROM address, NEVER to the Sender address.  The 
contents of the Sender field aren't even required to be a legal address.

> I might be using a terminal or kiosk with a reverse-path referencing the
> mobile account, but with From pointing to my master mailstore. I may not
> see the notification messages for several months, if ever.

In this case only Sender should point to the mobile account, and 
return-path/ MAIL FROM should point to where you want to receive reports.

> These examples are all really beside the ultimate point, however:
> out-of-office notifications are an application of the messaging network
> and not in-band management messages, so they really should use the headers
> rather than the envelope.

That's precisely the reason that the MAIL FROM address is exposed in the 
message header as return-path - so the address can be used for automatic 
responses that are generated after the message leaves the transport/delivery 
system.

Keith

From: "Dan Wing" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>, "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 10:57:26 -0700
Importance: Normal
Sender: [email-masked]

> > A mailing list would rewrite the envelope-from address.  So vacation
> > notices sent to envelope-from wouldn't be seen by the person posting
> > to the mailing list, nor would the vacation notice appear as a
> > 'post' on the mailing list itself.
> 
> Even if the reverse-path has been rewritten to reference an appropriate
> mailbox, the owner of the mailing list is likely to be uninterested in the
> sender's vacation plans. After enough of these, the owner may even
> manually pause or remove the sender from the list, resulting in the same
> effect.

Yep, which is why I stated below the best bet is only send vacation
when recipient is on to/CC, and send vacation to the envelope-from.

> If the reverse-path has been misconfigured to reference an inappropriate
> mailbox (eg, list-request@domain) then this might even happen
> automatically. This is *designed* to happen automatically with mailing
> lists that use VERP and similar proposals:
> 
>  |                                         The VERP extension implements
>  | a way of automatically identifying undeliverable mail recipients,
>  | even when non-delivery reports originate from mail systems that do
>  | not implement delivery status notifications

Simplistic implementations of auto-unsubscribe will likewise have
issues with unable-to-send-for-8-hours informational messages, such
as are common with many sendmail configurations.  I expect that any
auto-unsubscribe system will have to deal with those informational
messages (which are sent to the envelope-from).

> Even outside the list world, there are scenarios where sending to the
> reverse-path is inappropriate. EG, when the Sender/From construct is
> actually used, the notification is returned to the Sender instead of the
> From parties.

Sender/From is classically described for use with a secretary and an
executive:  the secretary would be Sender, the executive would be From.
In that case, I argue the executive isn't interested in NDNs (or 
vacation notices) and thus the return-path should be the sender.
This causes NDNs to be sent to the secretary.  Likewise, if 
vacation notices are sent to the return-path (as vacation works
on Unix), the vacation notices are sent to the secretary (Sender).

I believe you're arguing that the executive should see the NDNs and
should see the vacation messages for a Sender/From message?

> I might be using a terminal or kiosk with a reverse-path referencing the
> mobile account, but with From pointing to my master mailstore. I may not
> see the notification messages for several months, if ever.

You won't see NDNs, either.

> These examples are all really beside the ultimate point, however:
> out-of-office notifications are an application of the messaging network
> and not in-band management messages, so they really should use the headers
> rather than the envelope.

What of NOTIFY=DELAY, then, and its default usage in many mailers,
including sendmail (which implements the behavior of NOTIFY=DELAY
by default).

-d

Date: Tue, 04 Jun 2002 12:22:11 -0500
From: "Eric A. Hall" <[email-masked]>
To: Dan Wing <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, Dave Crocker <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

Dan Wing wrote:

> A mailing list would rewrite the envelope-from address.  So vacation
> notices sent to envelope-from wouldn't be seen by the person posting
> to the mailing list, nor would the vacation notice appear as a
> 'post' on the mailing list itself.

Even if the reverse-path has been rewritten to reference an appropriate
mailbox, the owner of the mailing list is likely to be uninterested in the
sender's vacation plans. After enough of these, the owner may even
manually pause or remove the sender from the list, resulting in the same
effect.

If the reverse-path has been misconfigured to reference an inappropriate
mailbox (eg, list-request@domain) then this might even happen
automatically. This is *designed* to happen automatically with mailing
lists that use VERP and similar proposals:

 |                                         The VERP extension implements
 | a way of automatically identifying undeliverable mail recipients,
 | even when non-delivery reports originate from mail systems that do
 | not implement delivery status notifications

Even outside the list world, there are scenarios where sending to the
reverse-path is inappropriate. EG, when the Sender/From construct is
actually used, the notification is returned to the Sender instead of the
>From parties.

I might be using a terminal or kiosk with a reverse-path referencing the
mobile account, but with From pointing to my master mailstore. I may not
see the notification messages for several months, if ever.

These examples are all really beside the ultimate point, however:
out-of-office notifications are an application of the messaging network
and not in-band management messages, so they really should use the headers
rather than the envelope.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, "Barry Leiba" <[email-masked]>, [email-masked]
Subject: Re: Replying to a mailing list 
Date: Tue, 04 Jun 2002 12:23:04 -0400
Sender: [email-masked]

> >but I do like list-specific fields better than having lists rewrite
> >originator-supplied fields.
> 
> every now and again, Keith and I agree on something.  This is one of them.
> 
> 
> (but of course, it did not last for even one entire message...)

:)

> >And many/most humans can't be bothered, with
> > > the result that replies often wind up going to *everyone* the MUA will
> > > allow them to be sent to.
> >
> >interesting that in the days of paper memos, people could be bothered
> >to think about such things.
> 
> the human factors issues are a tad different.  

absolutely.

> paper did not automatically fill out the reply fields...

and thus, paper never filled out the reply field incorrectly :)
 
> Getting the defaults "right" is a dilemma and, therefore, requires choosing
> the kind of error that is least undesireable.

I think of it as a user interface issue.  sometimes user interfaces that
try to guess what the human wants are more annoying (and/or error-prone)
than those that expect the human to explicitly specify what he/she wants.

our understanding of desirable characteristics of user interfaces has 
increased a lot in the past 20+ years.  similarly, I don't think the 
subtleties of communication between humans and automatic responders 
over email were well understood at the time the data model for email 
headers was defined.
 
> >part of the problem is probably (as you said) that the subtle
> >differences between return-path, from, reply-to, and sender
> >aren't clear to most email users
> 
> The intent was that users should only need to know about From/Reply-to,
> with Sender serving as a kind of accountability fall back.  

actually this works most of the time - human users don't generally fool with
either sender or return-path.  

> Return-path
> (and Sender) are intended for the mail handling system, not really for the
> recipient user.

sender seems to have been intended for humans, if only as a diagnostic tool,
because 822 doesn't require it to be a valid email address.

Keith

From: "Dan Wing" <[email-masked]>
To: "Lawrence Greenfield" <[email-masked]>, "Dave Crocker" <[email-masked]>
Cc: "Florian Weimer" <[email-masked]>, <[email-masked]>
Subject: RE: Sieve
Date: Tue, 4 Jun 2002 08:44:57 -0700
Importance: Normal
Sender: [email-masked]

>    At 01:58 PM 6/3/2002 -0400, Lawrence Greenfield wrote:
>    >The Sieve vacation draft (now expired) explicitly mandates that the
>    >vacation response messages be sent to the envelope from address
>    >("Return-path").  In practice, we haven't had any complaints about
>    >this behavior.
>
>    I suspect you haven't been sampling adequately.  Most of the people I know
>    are quite irritated with getting such notices, unless they have explicitly
>    cited the recipient in To or CC.
>
> I'm sorry, let me rephrase: "In practice, we haven't had any
> complaints about vacation responses going to the envelope from address
> and not the reply-to address."
>
> Vacation messages to the envelope from address are easier to reason
> about.  I suspect they're much less likely to cause mail loops.
>
>    >We do receive complaints about the check for the recipient's address
>    >in the To/Cc header lines.
>
>    Complaints from whom?  The people who get vacation notices when they send
>    to a mailing list?
>
> Complaints from the people who set the vacation messages and want
> their messages to go to everybody who sends them mail directly or
> indirectly.  I hate vacation messages from mailing lists, and I agree
> with the To/Cc test for responses.  But not everyone agrees with us.
> Luckily I don't sell my software and don't have to be responsive to
> customer complaints.

A mailing list would rewrite the envelope-from address.  So vacation
notices sent to envelope-from wouldn't be seen by the person posting
to the mailing list, nor would the vacation notice appear as a
'post' on the mailing list itself.

In my experience, the safest vacation notice is one that only
responds if you're on the To/CC, _and_ sends the vacation notice
to the envelope-from address -- using the envelope-from is consistent
with non-delivery notifications.

-d

Date: Mon, 3 Jun 2002 21:25:36 -0400
From: Lawrence Greenfield <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Sieve
Sender: [email-masked]

   Date: Mon, 03 Jun 2002 18:18:42 -0500
   From: Dave Crocker <[email-masked]>
[...]
   At 01:58 PM 6/3/2002 -0400, Lawrence Greenfield wrote:
   >The Sieve vacation draft (now expired) explicitly mandates that the
   >vacation response messages be sent to the envelope from address
   >("Return-path").  In practice, we haven't had any complaints about
   >this behavior.

   I suspect you haven't been sampling adequately.  Most of the people I know 
   are quite irritated with getting such notices, unless they have explicitly 
   cited the recipient in To or CC.

I'm sorry, let me rephrase: "In practice, we haven't had any
complaints about vacation responses going to the envelope from address
and not the reply-to address."

Vacation messages to the envelope from address are easier to reason
about.  I suspect they're much less likely to cause mail loops.

   >We do receive complaints about the check for the recipient's address
   >in the To/Cc header lines.

   Complaints from whom?  The people who get vacation notices when they send 
   to a mailing list?

Complaints from the people who set the vacation messages and want
their messages to go to everybody who sends them mail directly or
indirectly.  I hate vacation messages from mailing lists, and I agree
with the To/Cc test for responses.  But not everyone agrees with us.
Luckily I don't sell my software and don't have to be responsive to
customer complaints.

Larry

Date: Mon, 03 Jun 2002 18:12:54 -0500
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Replying to a mailing list
Cc: "Barry Leiba" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 12:43 PM 6/3/2002 -0400, Keith Moore wrote:
>but I do like list-specific fields better than having lists rewrite
>originator-supplied fields.

every now and again, Keith and I agree on something.  This is one of them.

(but of course, it did not last for even one entire message...)

>And many/most humans can't be bothered, with
> > the result that replies often wind up going to *everyone* the MUA will
> > allow them to be sent to.
>
>interesting that in the days of paper memos, people could be bothered
>to think about such things.

the human factors issues are a tad different.  paper did not automatically 
fill out the reply fields...

Getting the defaults "right" is a dilemma and, therefore, requires choosing 
the kind of error that is least undesireable.

>part of the problem is probably (as you said) that the subtle
>differences between return-path, from, reply-to, and sender
>aren't clear to most email users

The intent was that users should only need to know about From/Reply-to, 
with Sender serving as a kind of accountability fall back.  Return-path 
(and Sender) are intended for the mail handling system, not really for the 
recipient user.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

Date: Mon, 03 Jun 2002 18:18:42 -0500
To: Lawrence Greenfield <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Sieve
Cc: [email-masked], Florian Weimer <[email-masked]>
Sender: [email-masked]

At 01:58 PM 6/3/2002 -0400, Lawrence Greenfield wrote:
>The Sieve vacation draft (now expired) explicitly mandates that the
>vacation response messages be sent to the envelope from address
>("Return-path").  In practice, we haven't had any complaints about
>this behavior.

I suspect you haven't been sampling adequately.  Most of the people I know 
are quite irritated with getting such notices, unless they have explicitly 
cited the recipient in To or CC.

At any rate, such a specification should be done as an extension to 2822, 
rather than as a part of sieve.  The issue goes beyond split-UA interactions.

>We do receive complaints about the check for the recipient's address
>in the To/Cc header lines.

Complaints from whom?  The people who get vacation notices when they send 
to a mailing list?

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 03 Jun 2002 15:37:49 -0400
Sender: [email-masked]

> > From vs. Sender is as valid as it ever was.  My boss is constantly
> > asking other people (his secretaries and other employees) to send
> > out messages on his behalf.
> 
> >From and Sender is only one way to solve that particular problem.
> Authenticated sender permissions is another. Letting any fool send mail as
> your boss is about the dumbest imaginable method, given the current
> climate. It was certainly a reasonable design choice at its inception but
> things change, eh.

okay, but what you've specified is not semantically equivalent to
>From vs. Sender - nor does it seem to reflect reality as well.  
(at least not in my part of the world - though I expect that 
practice varies quite widely from one culture to another)

authentication is a separate issue. it is as easy to authenticate From 
and/or Sender as it would be to authenticate your Sender and Signatories. 

e.g. 

From: Jack Dongarra <[email-masked]>
From-authorization: {a formatted statement indicating that 
  "<[email-masked]> is allowed to send messages on my behalf"
  and including certain conditions, like date and/or subject,
  that is signed using [email-masked]'s private key}
Sender: Keith Moore <[email-masked]>
Content-type: multipart/signed

{message signed with [email-masked]'s signature}

Keith

p.s. however don't expect this to reduce the amount of spam.  

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 03 Jun 2002 15:30:24 -0400
Sender: [email-masked]

> At 09:10 AM 6/3/2002 -0400, Keith Moore wrote:
> > > the responding software cannot know what the originator -- human or
> > > otherwise -- is expecting, except as indicated by the presence or absence
> > > of a Reply-to field.
> >
> >that's simply not true.  if your robot performs a specific function
> >and expects a specific kind of input, it's reasonable for a robot
> >that receives well-formed input to assume that the sender is expecting
> 
> oh.  you mean 'expect' the same way that an smtp server, listening on port 
> 25 'expects' smtp protocol conformance and the way a server receiving IP 
> datagrams with a TCP protocol id 'expects' conformance with TCP.
> 
> Yes.  When the application-level mail receiving code is participating in a 
> formal application level protocol, it should 'expect' that the other side 
> is conforming to that application-level protocol.  The response-addressing 
> rules will be whatever is specified for that application protocol.
> 
> Absent such formal, application-level value-added enhancement to the 
> protocol environment, the question is what should an automaton that is a 
> participant in the unmodifed RFC 2822 protocol environment.

there's a separate question about whether it's a good idea for such a 
formal protocol to allow use of reply-to.  IMHO it is generally a bad idea.

> It should honor the reply-to field.  It needs to have a very good reason 
> not to.  That is what an IETF "SHOULD" means.

having the responses be issued by a robot who is not in a position to
make an intelligent decision about whether to override the reply-to
default is a very good reason for the robot to ignore reply-to.

> The reply-to field specifies an email-level protocol behavior for the 
> generation of user-agent level replies that are not handling-related.

blind faith in the ability of a rigid protocol engine to do the right 
thing doesn't solve real problems - especially when experience indicates
that the rigid protocol often does the wrong thing.
 
> > > it is frankly just as bad to have it go to the message originator.  not as
> > > bad in scale but as bad in inappropriateness.
> >
> >no it's not. partially because the return-path should NEVER be a list.
> 
> I did not say that sending such an automated response to return-path was 
> good.  I said that it was just as bad.  the effect is just as bad.  

having the response go to the return-path field is safer - has less
potential to cause harm.  this is not "just as bad", it's better.

> My 
> comment was not about protocol formalities, but the real-world impact that 
> such rogue responses cause to real users, no matter what address they are 
> sent to.  My own belief is that such automata behaviors are the same as spam.

surely there's a difference between this "spam" going to the sender of a 
message, who might actually be able to use the information in the response,
and having the "spam" going to other parties who had nothing to do with 
the request and have no idea why they're being issued the response?

> > > >And if both the sender and recipients are computer programs - i.e. if
> > > >this is the use of email within an application - it's probably best for
> > > >the sender to never use reply-to (and for the recipient to ignore it).
> > >
> > > Reply-to overrides From.  There is no reason not to use it.
> >
> >Reply-to creates ambiguity and the possibility of replies going to different
> >places.
> 
> Reply-to causes confusion only for the 2 reasons I cited in my previous 
> note.  The intent and specification of reply-to was and is pretty 
> clear.  And, yes, I know that you are not the only one who thinks otherwise.

the intent may have been clear.  it turns out that it doesn't work well.

> >   There is no reason for anybody to use it unless the sender wants
> >to provide the recipient with a *choice* about where to reply.
> 
> The same as a protocol participant has a 'choice' about conforming to the 
> protocol.  Reply-to is not added because the sender wishes to create choice 
> but wishes to direct a respondent to send to a specific -- and possibly 
> different -- address.  

in the case of a human respondent, it MUST be a choice.  the original sender
cannot reasonably expect the respondent to reply only in the way he/she
saw fit.  there are too many exceptional cases.  now you could insist
that user agents force the respondent to compose a separate message, but
that's a pretty silly impediment for the sake of protocol purity.

humans simply don't follow rigid protocols - at least, not if they want
to work effectively.  interpersonal messaging systems need to reflect
that reality and not impose arbitrary constraints on how humans communicate.

> >   As for
> >robots, even assuming that robots need to be able to respond to one of
> >multiple destinations, it's probably better for the robot to define its own
> >mechanism with semantics appropriate to the applicatoin than to overload
> >reply-to.
> 
> Having random protocol participants define their own, random behaviors is 
> anarchy.  

no, it's sanity.  having each protocol layered on top of mail overload 
the semantics of the underlying mail protocol by using reply-to in subtly
different ways is anarchy.

> > > Most of the problems with Reply-to are a) its semantics getting overloaded
> > > by lack of another field for mailing list automata,
> >
> >there's no need for a separate field for automata, return-path does fine.
> 
> I said *mailing list* automata.  Mailing lists are notably different 
> communication domains than regular, person email and hence the need for a 
> 'followup' header, or some such.

I agree that mailing lists are sometimes different, but in the case you 
cite, the mailing list isn't doing the replying.  At most it is adding
another hint to the message for the recipient/respondent to sort out.

> > > and b) a tendency for
> > > folk to forget that we are just talking about a protocol, albeit one that
> > > often has a human as part of the protocol engine.
> >
> >seems like the incorrect tendency is for certain humans to expect that humans
> >in general will rigidly follow subtle protocols.
> 
> But it is not so incorrect to expect rigid behavior from automata and other 
> software that are coded to follow protocol specifications.

no, it's just incorrect to specify those automata in such a way that they
expect or force humans to behave rigidly.

Keith

Date: Mon, 03 Jun 2002 14:24:48 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies
Sender: [email-masked]

Keith Moore wrote:

> From vs. Sender is as valid as it ever was.  My boss is constantly
> asking other people (his secretaries and other employees) to send
> out messages on his behalf.

>From and Sender is only one way to solve that particular problem.
Authenticated sender permissions is another. Letting any fool send mail as
your boss is about the dumbest imaginable method, given the current
climate. It was certainly a reasonable design choice at its inception but
things change, eh.

> > I know this is OT, but I wanted to make the argument that the canonical
> > problem is that the legacy model is not reflective of modern usages.
> 
> well, neither is the model you've proposed.

:/

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

From: Keith Moore <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
cc: Keith Moore <[email-masked]>, Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 03 Jun 2002 15:18:50 -0400
Sender: [email-masked]

Keith Moore wrote:

> > even now I'm not sure that list-specific fields solve those problems,
> 
> > part of the problem is probably (as you said) that the subtle
> > differences between return-path, from, reply-to, and sender
> 
> IMO, the whole construct is wrong. While the headers were appropriate for
> the time and place of their design, the modern usage has gone to another
> place which is not particularly well suited to the design. For example,
> From vs Sender is a good model if From doesn't have connectivity, but in
> the modern age, From is just another way for spammers to lie.

>From vs. Sender is as valid as it ever was.  My boss is constantly
asking other people (his secretaries and other employees) to send
out messages on his behalf.  That's exactly the case for which the
>From vs. Sender distinction was intended - the problem is just that 
that this isn't widely understood.

> I know this is OT, but I wanted to make the argument that the canonical
> problem is that the legacy model is not reflective of modern usages. 

well, neither is the model you've proposed.  

Keith

Date: Mon, 03 Jun 2002 11:31:02 -0500
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Choosing recipient of automatic replies 
Cc: Keith Moore <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

At 09:10 AM 6/3/2002 -0400, Keith Moore wrote:
> > the responding software cannot know what the originator -- human or
> > otherwise -- is expecting, except as indicated by the presence or absence
> > of a Reply-to field.
>
>that's simply not true.  if your robot performs a specific function
>and expects a specific kind of input, it's reasonable for a robot
>that receives well-formed input to assume that the sender is expecting

oh.  you mean 'expect' the same way that an smtp server, listening on port 
25 'expects' smtp protocol conformance and the way a server receiving IP 
datagrams with a TCP protocol id 'expects' conformance with TCP.

Yes.  When the application-level mail receiving code is participating in a 
formal application level protocol, it should 'expect' that the other side 
is conforming to that application-level protocol.  The response-addressing 
rules will be whatever is specified for that application protocol.

Absent such formal, application-level value-added enhancement to the 
protocol environment, the question is what should an automaton that is a 
participant in the unmodifed RFC 2822 protocol environment.

It should honor the reply-to field.  It needs to have a very good reason 
not to.  That is what an IETF "SHOULD" means.

The reply-to field specifies an email-level protocol behavior for the 
generation of user-agent level replies that are not handling-related.

> > it is frankly just as bad to have it go to the message originator.  not as
> > bad in scale but as bad in inappropriateness.
>
>no it's not. partially because the return-path should NEVER be a list.

I did not say that sending such an automated response to return-path was 
good.  I said that it was just as bad.  the effect is just as bad.  My 
comment was not about protocol formalities, but the real-world impact that 
such rogue responses cause to real users, no matter what address they are 
sent to.  My own belief is that such automata behaviors are the same as spam.

> > in pretty much all cases of that type of situation, the fact that the
> > recipient is not explicitly mentioned in the To or CC field means that the
> > software should not send a reply at all.
>
>true for a "out of the office memo" (though it's not specified anywhere),
>but your assertion is not supportable in general.

Except the empirics of experience.

Out-of-office/vacation notices are but one example.  Another would be the 
filtering agents that notify you of selective handling by the recipient, 
depending upon whether they know you.  And so on.

> > >And if both the sender and recipients are computer programs - i.e. if
> > >this is the use of email within an application - it's probably best for
> > >the sender to never use reply-to (and for the recipient to ignore it).
> >
> > Reply-to overrides From.  There is no reason not to use it.
>
>Reply-to creates ambiguity and the possibility of replies going to different
>places.

Reply-to causes confusion only for the 2 reasons I cited in my previous 
note.  The intent and specification of reply-to was and is pretty 
clear.  And, yes, I know that you are not the only one who thinks otherwise.

>   There is no reason for anybody to use it unless the sender wants
>to provide the recipient with a *choice* about where to reply.

The same as a protocol participant has a 'choice' about conforming to the 
protocol.  Reply-to is not added because the sender wishes to create choice 
but wishes to direct a respondent to send to a specific -- and possibly 
different -- address.  It is the same construct FTP third-party server 
specification and HTTP redirects.

>   As for
>robots, even assuming that robots need to be able to respond to one of
>multiple destinations, it's probably better for the robot to define its own
>mechanism with semantics appropriate to the applicatoin than to overload
>reply-to.

Having random protocol participants define their own, random behaviors is 
anarchy.  Protocols specify a discipline.  It's not very helpful to 
well-behaved open systems operation, if a participant behaves any ol' way 
it chooses, because there is no way to predict that behavior, and hence 
there will be no interoperability.

> > Most of the problems with Reply-to are a) its semantics getting overloaded
> > by lack of another field for mailing list automata,
>
>there's no need for a separate field for automata, return-path does fine.

I said *mailing list* automata.  Mailing lists are notably different 
communication domains than regular, person email and hence the need for a 
'followup' header, or some such.

> > and b) a tendency for
> > folk to forget that we are just talking about a protocol, albeit one that
> > often has a human as part of the protocol engine.
>
>seems like the incorrect tendency is for certain humans to expect that humans
>in general will rigidly follow subtle protocols.

But it is not so incorrect to expect rigid behavior from automata and other 
software that are coded to follow protocol specifications.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

Date: Mon, 03 Jun 2002 13:46:22 -0500
From: "Eric A. Hall" <[email-masked]>
To: Keith Moore <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies
Sender: [email-masked]

Keith Moore wrote:

> even now I'm not sure that list-specific fields solve those problems,

> part of the problem is probably (as you said) that the subtle
> differences between return-path, from, reply-to, and sender

IMO, the whole construct is wrong. While the headers were appropriate for
the time and place of their design, the modern usage has gone to another
place which is not particularly well suited to the design. For example,
>From vs Sender is a good model if From doesn't have connectivity, but in
the modern age, From is just another way for spammers to lie.

I've been thinking about this in terms of a revised format/protocol, and
am of the opinion that a better usage for the current Internet mail model
is to use a Sender and Signatories model. This solves a lot of problems,
but as with all of the other radical departures, it pretty much depends on
overhauling the infrastructure.

In the Sender and Signatories model, the Sender is the Original Sender, as
identified in the envelope. These must match, and Sender must always be
provided. If there is only one party associated with the message, then
only the Sender needs to be provided. If something like a mailing list
redistributes the message, it becomes the Signatory, but the Sender header
field remains (and must still match the Original Sender envelope). If a
secretary is sending mail on behalf of the PHB, the PHB is the Signatory,
and the secretary is the Sender. Default replies go to the Signatory,
Reply-to-All goes to the Signatory+Sender+CC.

Parts of that model are similar to Sender and From but parts are radically
different (mailing list becomes the new From-equivalent, for example).

One of obvious benefits to this approach is that forging From goes away.
Another benefit is that the mailing list model is more cleanly aligned
with the default usage. Another benefit ist that Reply processing is much
simpler. Also, following a Resent-* style of forwarding is clearer.

I know this is OT, but I wanted to make the argument that the canonical
problem is that the legacy model is not reflective of modern usages. If
anybody has any thoughts about the usage I've laid out, I'd be happy to
hear about them off-list.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Mon, 3 Jun 2002 13:58:38 -0400
From: Lawrence Greenfield <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: [email-masked], Florian Weimer <[email-masked]>
Subject: Re: Choosing recipient of automatic replies 
Sender: [email-masked]

   Date: Mon, 03 Jun 2002 07:38:43 -0500
   From: Dave Crocker <[email-masked]>
[...]
   >On the other hand, if the
   >sender is not expecting an automatically generated reply, but is expecting
   >a reply from a human (as in a "out of the office" response) then sending
   >to the return-path address usually makes more sense.

   no.

The Sieve vacation draft (now expired) explicitly mandates that the
vacation response messages be sent to the envelope from address
("Return-path").  In practice, we haven't had any complaints about
this behavior.

We do receive complaints about the check for the recipient's address
in the To/Cc header lines.

Larry

Date: Mon, 03 Jun 2002 13:28:43 -0400
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Choosing recipient of automatic replies
Sender: [email-masked]

> another part of the problem is probably that email has made it so
> easy to send messages that we now have to deal with too many messages
> - which is a clue as to why people "can't be bothered" to think about
> where to send replies anymore.  offhand, I don't see how to fix this

Yes, exactly.  A couple of years ago, we did an IBM Academy study on 
e-mail, and as part of it we talked with some executive secretaries. 
One question we asked was, "What's the biggest problem you have, or 
your principal has, with e-mail?", and the answer was "It's abused." 
When we pressed for explanations, we found that the complaint was 
twofold:

1. Because it's so easy to send it, people send it... and the principal 
is *flooded* with things that s/he never had to deal with before. 
People used to say to themselves, "The VP is too important for us to 
bother with this," when "bothering" meant calling on the telephone or 
sending a paper memo.  Now they say, "We'd better send this to the VP, 
just to cover all the bases."

2. One thing many of us like about e-mail is that it's asynchronous. 
One thing that executives (or, at least, their secretaries) hate about 
it is that it's asynchronous.  In the old days, if you called the exec, 
and the exec was on the phone, well... you had to try again later.  Or 
you had to talk with Cerberus (uh, the secretary).  Either way, it was 
self-limiting.  Now... you send e-mail and go on your way.  So the busy 
exec has that much more to deal with.

The result of the combination of these things is that most exec sec'ies 
sort their principals' mail, a sort of triage, and the exec never 
actually looks at the inbox itself.  There's an FYI folder that never 
gets looked at, an Urgent folder that's the first thing, and an 
"everything else" folder that's handled as time permits.

But I digress.  In any case, how this fits into the discussion at hand 
is to say that in practice, every e-mail address that the (human) 
reply-er can get to will be used... just so the human can be sure that 
no tern is left unstoned.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Keith Moore <[email-masked]>
To: "Barry Leiba" <[email-masked]>
cc: [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 03 Jun 2002 12:43:16 -0400
Sender: [email-masked]

> The fact that mailing lists are a difficult problem is a matter of bad
> choices throughout the history of e-mail.  In the beginning, one couldn't
> guess, but once it became clear, we should have put mailing-list-specific
> fields in to solve the problem.  We didn't.  A pity.

well, we did put them in eventually.  it just took awhile.
even now I'm not sure that list-specific fields solve those problems,
but I do like list-specific fields better than having lists rewrite 
originator-supplied fields.

> The problem is that all of this isn't clear, and that some of it
> depends upon a human thinking about what the reply is and to whom it
> should really be sent.  And many/most humans can't be bothered, with
> the result that replies often wind up going to *everyone* the MUA will
> allow them to be sent to.

interesting that in the days of paper memos, people could be bothered 
to think about such things.  

part of the problem is probably (as you said) that the subtle 
differences between return-path, from, reply-to, and sender 
aren't clear to most email users - and there is a lot of 
misunderstanding out there.   (and if the protocol developers can't
agree on when to use each field, how can we expect users supposed to 
behave uniformly?)  still, if the protocol folks can come to agreement
there is some potential that improved user interfaces might help 
this problem.

another part of the problem is probably that email has made it so 
easy to send messages that we now have to deal with too many messages -
which is a clue as to why people "can't be bothered" to think about
where to send replies anymore.  offhand, I don't see how to fix this one.

Keith

From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 3 Jun 2002 09:55:01 -0400
Sender: [email-masked]

The fact that mailing lists are a difficult problem is a matter of bad
choices throughout the history of e-mail.  In the beginning, one couldn't
guess, but once it became clear, we should have put mailing-list-specific
fields in to solve the problem.  We didn't.  A pity.

But let's look at how this stuff might be used (and *is* used, in some
non-standard systems, at least) in a business environment.  Here's a
common situation: an admin assistant sends a note on behalf of a principal,
submitting the message from a shared group ID.  The message asks for some
response to be sent to the principal's tech assistant.  Something like this:

> Return-Path: <[email-masked]>
> Sender: <[email-masked]>
> From: <[email-masked]>
> Reply-To: <[email-masked]>
> To: ...
> Subject: Information needed
> 
> All,
> I urgently need any information you have about the Banana project.  Please
> collect that you have and send it to Nancy ASAP.  Thanks.
> 
> Susan Goombah
> Manager, Fruit Projects
> company.com, Inc.

Now, the decision about where to send various types of replies can be a
complicated one, and very much depends upon the semantics.  Very rarely
sure *any* reply to this go to Susan.  It's her signature on the message,
but everything here is delegated.

Most human-generated replies should go to Nancy, the Reply-To address.
Most mail-transport replies should go to Group-ID, the Return-Path
address.  Some things might go to Joe, the Sender address (perhaps
something like "Why did you send this to Bill; he's been re-assigned
for weeks now?  Please correct your mailing list."), but those could
arguably go to the Group-ID also (which is resumably used so that if
Joe is out one day, the temp who's substituting can deal with things
in his stead).

The problem is that all of this isn't clear, and that some of it
depends upon a human thinking about what the reply is and to whom it
should really be sent.  And many/most humans can't be bothered, with
the result that replies often wind up going to *everyone* the MUA will
allow them to be sent to.

Barry 
--
Barry Leiba, Internet Messaging Technology   ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Keith Moore <[email-masked]>, Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 03 Jun 2002 09:10:30 -0400
Sender: [email-masked]

> >   If the sender is a human, and he/she is expecting
> >an automatically-generated reply,
> 
> the responding software cannot know what the originator -- human or 
> otherwise -- is expecting, except as indicated by the presence or absence 
> of a Reply-to field.

that's simply not true.  if your robot performs a specific function
and expects a specific kind of input, it's reasonable for a robot
that receives well-formed input to assume that the sender is expecting
the robot to perform its particular function.  (unfortunately robots
often get spammed these days which is why I said 'well-formed input')

> >    Consider a message
> >intended for a mailing list where the sender specified the list address in
> >the reply-to field (which is a perfectly reasonable thing to do) - if a robot
> >answers the mail on behalf of a list recipient and sends the reply to the
> >entire list, this will be seen as disruptive.
> 
> it is frankly just as bad to have it go to the message originator.  not as 
> bad in scale but as bad in inappropriateness.

no it's not. partially because the return-path should NEVER be a list.

> in pretty much all cases of that type of situation, the fact that the 
> recipient is not explicitly mentioned in the To or CC field means that the 
> software should not send a reply at all.

true for a "out of the office memo" (though it's not specified anywhere),
but your assertion is not supportable in general.

> >And if both the sender and recipients are computer programs - i.e. if
> >this is the use of email within an application - it's probably best for
> >the sender to never use reply-to (and for the recipient to ignore it).
> 
> Reply-to overrides From.  There is no reason not to use it.

Reply-to creates ambiguity and the possibility of replies going to different
places.  There is no reason for anybody to use it unless the sender wants 
to provide the recipient with a *choice* about where to reply.  As for 
robots, even assuming that robots need to be able to respond to one of
multiple destinations, it's probably better for the robot to define its own
mechanism with semantics appropriate to the applicatoin than to overload
reply-to.

> >The bottom line is that the specifications leave a lot of wiggle room
> >regarding use of Reply-To because we really haven't been able to find
> >a clear set of rules that works for all cases.
> 
> They do not leave as much wiggle room as folks often want to believe.  The 
> protocol intent of Reply-To  was and is simple and precise.  

and naive.

> Most of the problems with Reply-to are a) its semantics getting overloaded 
> by lack of another field for mailing list automata, 

there's no need for a separate field for automata, return-path does fine.

> and b) a tendency for 
> folk to forget that we are just talking about a protocol, albeit one that 
> often has a human as part of the protocol engine.

seems like the incorrect tendency is for certain humans to expect that humans
in general will rigidly follow subtle protocols.

Keith

Date: Mon, 03 Jun 2002 07:38:43 -0500
To: Keith Moore <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Choosing recipient of automatic replies 
Cc: Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:52 AM 6/3/2002 -0400, Keith Moore wrote:
>For example, automatically generated message disposition notifications aren't
>generated by the mail transport system - they're generated by the recipient's

right.  meant to cover all "transport-related" communications.

my main intent was to distinguish application-level replies from 
"handling-related" replies.

>   If the sender is a human, and he/she is expecting
>an automatically-generated reply,

the responding software cannot know what the originator -- human or 
otherwise -- is expecting, except as indicated by the presence or absence 
of a Reply-to field.

>On the other hand, if the
>sender is not expecting an automatically generated reply, but is expecting
>a reply from a human (as in a "out of the office" response) then sending
>to the return-path address usually makes more sense.

no.

>    Consider a message
>intended for a mailing list where the sender specified the list address in
>the reply-to field (which is a perfectly reasonable thing to do) - if a robot
>answers the mail on behalf of a list recipient and sends the reply to the
>entire list, this will be seen as disruptive.

it is frankly just as bad to have it go to the message originator.  not as 
bad in scale but as bad in inappropriateness.

in pretty much all cases of that type of situation, the fact that the 
recipient is not explicitly mentioned in the To or CC field means that the 
software should not send a reply at all.

(Aren't we all a little tired of getting vacation notices from mailing list 
recipients' automata? We did not send our message to that person 
specifically, so getting a vacation notice from then is wildly inappropriate.)

>And if both the sender and recipients are computer programs - i.e. if
>this is the use of email within an application - it's probably best for
>the sender to never use reply-to (and for the recipient to ignore it).

Reply-to overrides From.  There is no reason not to use it.

>The bottom line is that the specifications leave a lot of wiggle room
>regarding use of Reply-To because we really haven't been able to find
>a clear set of rules that works for all cases.

They do not leave as much wiggle room as folks often want to believe.  The 
protocol intent of Reply-To  was and is simple and precise.  The exact 
boundary of its use, relative to use of an envelope-type address, has moved 
a bit, but not much.

Most of the problems with Reply-to are a) its semantics getting overloaded 
by lack of another field for mailing list automata, and b) a tendency for 
folk to forget that we are just talking about a protocol, albeit one that 
often has a human as part of the protocol engine.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

From: Keith Moore <[email-masked]>
To: Dave Crocker <[email-masked]>
cc: Florian Weimer <[email-masked]>, [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Mon, 03 Jun 2002 01:52:53 -0400
Sender: [email-masked]

> >Should the service use the envelope or the header address to choose
> >the recipient for the automatic reply?
> 
> The important distinction is between a reply by the transport service,
> about transmission, versus a reply by an email-based application, about an
> activity of the application.

Certainly a reply by the mail transport service should always go to the
return-path / MAIL FROM address - that much, at least, is not controversial.

However it's not at all clear that a reply that is not from the transport
service should go to the reply-to address(es) even if the field is present.
For example, automatically generated message disposition notifications aren't 
generated by the mail transport system - they're generated by the recipient's 
user agent - but they are still supposed to go to the return-path address.  

   from RFC 2298:

   MDNs SHOULD NOT be sent automatically if the address in the
   Disposition-Notification-To header differs from the address in the
   Return-Path header (see RFC 822 [2]).  

As to whether Reply-to should be used for other kinds of automatic replies,
the answer can be subtle.  If the sender is a human, and he/she is expecting
an automatically-generated reply, then it might be reasonable to assume
that if the human set a reply-to field then he/she intended the reply to
go to that address rather than the From address.  On the other hand, if the
sender is not expecting an automatically generated reply, but is expecting
a reply from a human (as in a "out of the office" response) then sending 
to the return-path address usually makes more sense.    Consider a message 
intended for a mailing list where the sender specified the list address in 
the reply-to field (which is a perfectly reasonable thing to do) - if a robot
answers the mail on behalf of a list recipient and sends the reply to the 
entire list, this will be seen as disruptive.  

And if both the sender and recipients are computer programs - i.e. if
this is the use of email within an application - it's probably best for
the sender to never use reply-to (and for the recipient to ignore it).

The bottom line is that the specifications leave a lot of wiggle room 
regarding use of Reply-To because we really haven't been able to find
a clear set of rules that works for all cases.

Keith

Date: Sun, 02 Jun 2002 22:52:42 -0500
To: Florian Weimer <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Choosing recipient of automatic replies
Cc: [email-masked]
Sender: [email-masked]

At 10:34 PM 6/2/2002 +0200, Florian Weimer wrote:
>Suppose a mail-based service needs to send an automatic reply to an
>incoming mail message.  Mail is received sent over a protocol which
>contains an envelope sender (such as SMTP).
>
>Should the service use the envelope or the header address to choose
>the recipient for the automatic reply?

The important distinction is between a reply by the transport service, 
about transmission, versus a reply by an email-based application, about an 
activity of the application.

If the reply is about email transport, then the envelope address should be 
used, per RFC 2821.  If the reply is about the application-level service 
that is simply using email as an underlying service, then the reply should 
use the rules in RFC 2822:

>3.6.2. Originator fields
...
>The originator fields also provide the information required when replying 
>to a message. When the "Reply-To:" field is present, it indicates the 
>mailbox(es) to which the author of the message suggests that replies be 
>sent. In the absence of the "Reply-To:" field, replies SHOULD by default 
>be sent to the mailbox(es) specified in the "From:" field unless otherwise 
>specified by the person composing the reply.

and

>3.6.3. Destination address fields
...
>When a message is a reply to another message, the mailboxes of the authors 
>of the original message (the mailboxes in the "From:" field) or mailboxes 
>specified in the "Reply-To:" field (if it exists) MAY appear in the "To:" 
>field of the reply since these would normally be the primary recipients of 
>the reply.
...
>Note: Some mail applications have automatic reply commands that include 
>the destination addresses of the original message in the destination 
>addresses of the reply. How those reply commands behave is implementation 
>dependent and is beyond the scope of this document. In particular, whether 
>or not to include the original destination addresses when the original 
>message had a "Reply-To:" field is not addressed here.

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850

From: Keith Moore <[email-masked]>
To: Florian Weimer <[email-masked]>
cc: [email-masked]
Subject: Re: Choosing recipient of automatic replies 
Date: Sun, 02 Jun 2002 17:21:29 -0400
Sender: [email-masked]

> Suppose a mail-based service needs to send an automatic reply to an
> incoming mail message.  Mail is received sent over a protocol which
> contains an envelope sender (such as SMTP).
> 
> Should the service use the envelope or the header address to choose
> the recipient for the automatic reply?

it's a bit of an open-ended question, but in general I recommend 
that automatic responses use the envelope return address (or 
return-path header address which should be the same).  that way, 
all responses get sent to the same place, regardless of whether 
they are normal replies, nondelivery reports, delivery reports, 
or whatever. 

Keith

To: [email-masked]
Subject: Choosing recipient of automatic replies
From: Florian Weimer <[email-masked]>
Date: Sun, 02 Jun 2002 22:34:50 +0200
Lines: 6
Sender: [email-masked]

Suppose a mail-based service needs to send an automatic reply to an
incoming mail message.  Mail is received sent over a protocol which
contains an envelope sender (such as SMTP).

Should the service use the envelope or the header address to choose
the recipient for the automatic reply?