[Top] [All Lists]

Re: vacation replies to From: or envelope from

2001-04-03 07:37:39
On Tue, Apr 03, 2001 at 09:54:49AM -0400, Keith Moore wrote:
Propably  James M Galvin <galvin(_at_)acm(_dot_)org>   wrote:
Personally, I agree with the choice of responding to the message From:
header as opposed to the envelope from.  The message From: header is the
author of the content of the message and if that content is "urgent" in
any way, I would want that person to know I am not being timely.

I am of the opposite opinion.  Vacation notices should go to the same
place as nondelivery reports and automatically-generated delivery 
notifications - which is to say the envelope return address.
If the author of the message wants to get notifications about whether
and when a message will delivered or read, the standard mechanisms
for this all require that the author's address be in the envelope 
return address. I see no reason why vacation notices should not follow 
this well-established practice.

        Indeed.   It is a great nuisance to send something to
        a mailing-list and receive heaps of "autoresponding email"
        (or whatever it calls itself this week) that person XYZ
        is away now.

        With listmanager hat on, I would probably remove such
        recipients which bounce to list-owner address with
        vacation.  As a list-subscriber I definitely don't
        want kwazillion notifications that some people have
        vacation.  (And having had this situation, we *have*
        removed people who are complained about running that
        kind of M$ "vacation")

        For various reasons relating to corporate security
        I myself never run vacation, less "paranoid" people do...

In any case, I don't think the primary issue is where to respond but
rather when to respond.  A response should only be created when the
address of the recipient appears in either the message To: or Cc:

I agree that this is a useful heuristic, though I don't think it's
sufficient by itself.

        "vacation" responding when the message reaches one of five
        addresses I have, but not when To: or Cc: doesn't list
        any of them..  Yes, neat heuristic, and often ok.
        List traversing does not (usually) alter those two header
        types.  (Check also Resent-To: and Resent-Cc:)

        Adding also rate limiting, e.g. only one message per destination
        address per 24 hours, now that would be neat thing for most
        M$ environment vacation features -- UNIX has had that since
        day 2 (BSD + sendmail + vacation), so it is nothing new.

Of course, either set of rules means that certain mailing list softare
habits are, shall we say, unorthodox.  I am often confounded by which
set of rules is really the lesser of two evils, since at this point
neither is a clear winner.

part of the problem is that very little about list behavior is 
standardized, so we get a wide variation in behavior from one list 
to another.  for instance, far too many lists fail to rewrite 
return-path and gratuitously rewrite a half-dozen other headers.

in the past efforts to alleviate this problem have been hampered 
because each author of list software truly believed that his way 
was the One True Way.    but who knows, maybe the world is saner now.

        And Keith is idealist  ;-)

        It would be nice if there could be some agreenment on
        how list systems should manage headers (and envelopes),
        but that is unlikely with existence of opposite schools
        of thought at

                "send individually tailored transfer envelope and
                visible headers to each recipient",
                "minimize the number of sent messages by sending
                to all recipients at same domain(*) with multiple
                RCPT TO envelopes for the message"

        The first one tries to ensure that bounce message will
        get properly automatically processed -- with recipient
        recognition at reliable levels.  Simultaneously it will
        maximize network resource usage.

        The second one tries to minimize network resource usage
        (and is what RFC 821 / 1123 / DRUMS try to encourage.)


/Matti Aarnio   <mea(_at_)nic(_dot_)funet(_dot_)fi>