[ On Mon, February 23, 1998 at 23:26:27 (-0500), Keith Moore wrote: ]
> Subject: Re: bin/5039: change to vacation to support wider variety of mailers 
>
> I have no problem with checking the Bcc header.

The problem is the Bcc is normally purposefully empty (and although some
have interpreted the RFCs to suggest that it should be filled in with

> I do have a problem with modifying vacation so that it will 
> send replies to mailing lists.

Although my survey hasn't been 100% scientific I'd suggest that if you
examine the mail you receive from lists you'll find as I did that not
very much would actually be returned to to the list distribution
address, if any (though the list maintainer might get a copy).

> There's no such thing as an appropriate Precedence field, and lists
> certainly aren't expected to use it.
> 
> Precedence is not only non-standard, poorly conceived, and undefined, 
> its use is so overloaded that it has been known to cause delivery failures.

Your statements don't seem to be backed up by the evidence I've seen in
the field.  I admit my experience doesn't extend too far outside the
realm of e-mail on the Internet and other Unix related systems, but are
we not discussing a Unix specific e-mail handling tool?

The only instance I'm aware of where 'Precedence' might cause delivery
failures is in overly ambitious and misguided spam filters.  *I* am not
going to be bullied by spammers into giving up something that *does*
work very well in most instances.

> (e.g. Some gateways won't forward messages that contain a Precedence
> field unless the field contains one of a particular set of keywords.
> (and neither 'junk' nor 'list' qualifies)

That's something I was not aware of.  I should hope it to be fairly rare
these days though, as I've never had any problem receiving mail which
contains a 'Precedence' header.  Having not maintained a large list
though I can't say I have much experience with people not being able to
receive mail from lists I have run.

If you have any explicit examples of "gateways" that refuse to pass
messages containing some values of 'Precedence' header keywords I'd
really like to know more about them.

> Some list exploders refuse
> to forward messages with Precedence: bulk because they think it
> will cause a mail loop.  etc.)

Of course list exploders should refuse to pass messages containing the
header "Precedence: bulk".  A list forwarding to a list can be a nasty
thing indeed, and is often considered unfriendly at best anyway.  (I'm
not talking about group alaises here, but real lists.)  [Oh, and if you
really need to do this a quick little sed or awk filter will easily fix
things up to make it possible.]  This isn't a bug -- it's a feature!

> I have no problem with vacation using Precedence as a heuristic,
> but vacation shouldn't depend on it being there.

Vacation(1) already does depend on 'Precedence' to some extent (eg. to
prevent loops, as I discuss below).

> That's true, but the "check the to/cc/bcc" field heuristic is still 
> valuable.  And you don't have to enable it.  Why defeat it?

It is currently not possible to defeat vacation(1)s 'to/cc' heuristic.
That's my problem.  It is clearly wrong in some circumstances and causes
no end of confusion to naive users.
 
> This would be unfortnate, as it would unnecessarily cause bounces
> to lists that don't happen to use Precedence.

Many of the true list management packages do use 'Precedence' or else
set the 'Reply-to' or 'From' header to the listserver address (i.e. the
admin address, not the list distribution address).

> If you manage to 
> force people to adopt something that works poorly, you make it
> more difficult to put in place something that works well.

Your logic does not compute.

> Ideally, vacation would recognize the autosubmitted field;
> it would not respond to messages with AutoSubmitted
> headers with a keyword other than not-auto-submitted, 
> and it would emit
> 
> AutoSubmitted: auto-replied
> 
> in every reply that it generated.

Now that's getting overly pedantic!  ;-)

> (autosubmitted is defined in RFC 2156, which is a standards-track
> document; it's based on an X.400 field with a similar name.
> there are drafts of additional documents that define its use 
> for loop control.)

Ah, yes, X.400, RFC 2156.  "Overly Pedantic."(tm)

"Standards track" and "draft" documents are all well and good, but all
too often they don't define working code and consensus.  Real working
code and consensus do that all by themselves!  ;-)  Let's not discuss
things yet to come when talking about current code that doesn't conform
to current consensus.

> Resent-* wasn't really intended for use by list exploders;
> it's intended to indicate manual redirection.

RFC 822 certainly does *not* indicate any such limitations, and the use
of 'Resent-*' headers by mailing list software is far from rare, though
indeed it's not universal either.  Where do you get the impression that
RFC 822 reserves 'Resent-*' for use with "manual redirection"?

> > True, but vacation(1) is really a MUA facility, not an MTA facility and
> > as such it should respond as an MUA (i.e. to the 'Reply-To'), not as an
> > MTA.  
> 
> experience shows that it doesn't work well.  
> (it's a really good way to cause mail loops)

That's usually just because of "pilot" error, and specifically in the
case of vacation(1) somewhat obfuscated documentation.  However I might
point out that anyone who can think through more than two levels of
logic would quickly realize that since vacation(1) won't respond to
messages with the "Precedence: junk" header and that the ~/.vacation.msg
file can contain any arbitrary headers that mail loops will be
*impossible* if only they're smart enough to include such a header in
their outgoing message.  Unfortunately the documentation has never to my
knowledge given an example showing how this should be done.  I'm going
to fix that in my version ASAP.

> > The RFCs are very clear on this point and nothing they say
> 
> RFC 822 is anything but clear on the subject of replies.
> (which is why reply-to is mis-implemented in almost every mailer
> on the planet, but that's a different story.)

Ah, not really (w.r.t. the definition of 'Reply-To' that is -- I
certainly don't want to defend the overall clarity of RFC 822, though in
its day it was a brave new attempt at a more strict protocol definition
than most any that came before it, esp. in the field of e-mail).

Quite the contrary in fact.  RFC 822 is *VERY* clear on the subject of
addressing a reply.

RFC 822 is even fairly clear about the fact that if the originator wants
to see a copy of they reply then they'd better include themselves (or be
sure they're on any group list that they do specify), though this is
only by obvious implication.

Even if you want to classify vacation(1) as an "automated system" in the
terms of RFC 822 then that RFC states clearly what vacation(1) should
do:

     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO

            [[... stuff about transport notices ...]]

            o   If the "Reply-To" field exists, then the reply  should
                go to the addresses indicated in that field and not to
                the address(es) indicated in the "From" field.

            o   If there is a "From" field, but no  "Reply-To"  field,
                the  reply should be sent to the address(es) indicated
                in the "From" field.

Waffling about things that are clearly not so is not just silly, but it
perpetuates myths that are harmful.  (Take a closer look at some of the
more recent RFCs, such 2156, if you want to see the harm being done!)

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>