Alan Stebbens wrote:
It is generally a Bad Idea to respond automatically to any kind of bulk or
list mail. I cannot think of a single valid reason to have an automatic
response sent to a list. Even if it is possible to determine who was the
original sender of a message that was relayed through a list, it is a bad
idea to automatically reply.
I agree, and there are safeguards in the spec, as is.
For example, if you send a mail through the "IETF-MTA-FILTERS" list and got
back 100 automatic vacation responses, you would be little bit miffed, I'll
bet.
The vacation spec specifies the following:
* replies go to the envelope sender, NOT the from or sender address, so
I wouldn't get the responses, the list maintainer would.
* my vacation agent may only reply to a given message if my address is
in the to or cc lines. So those replies won't be generated in the first
place.
So this vacation spec is not contributing to that problem.
So, given that it is a Bad Idea, it seems reasonable (to me :^) that the
VACATION extension specifically state that it will not ever respond to mail
with certain attributes, including "Precedence: bulk" or "Precedence: list",
as well as certain Sender or From addresses (see next issue).
Precedence is not a standard header, and is referenced only in RFCs that
say not to use it.
| > * does it generate replies to "mailer-daemon", "Postmaster", "root", and
| > other system accounts?
|
| Implementation dependant (as of the next revision).
It is a bad idea to leave what should be consistent behaviour as
"implementation dependant".
I don't want to specify the list because it's a moving target. If we
supply the list, it will be incomplete and probably a point where people
will attack the spec.
Worse, I don't want to specify that certain IDs always belong to the
mail system; that may not be true.
Preventing replies to system accounts is not a life-or-death feature.
Some of these messages (like the ones from MAILER-DAEMON) will come with
an envelope sender of <>, so they don't count; we won't be replying to
bounces.
What you may not have realized is that it is important that this be at
least partially implementation-dependant in case someone invents yet
another one of these names. We already have PoStMaStER, root,
MAILER-DAEMON, possibly Administrator, System, *-request, owner-*, etc.,
and it is not at all clear that all of these addresses are always system
accounts.
If the mail comes from a human behind the guise of a system account, it
may be useful to know that someone is on vacation, or that they won't
reply because the user name isn't familiar (ever send Nathaniel
Borenstein mail?).
That is, imagine that you're a postmaster, replying to mail with the
From line postmaster(_at_)whatever(_dot_)com, and having my vacation decide
not to
reply with the following message because you're clearly a computer:
Hi. I don't read mail from people I don't know. I will
never get your message unless you resend it t
tjs+urgent(_at_)mirapoint(_dot_)com(_dot_)
What I'm trying to point out is that none of these addresses are
standard. Requiring people to not reply to them is demanding that
people base standards on ad-hoc names that there may be very good
reasons to violate.
Given the fact that vacation replies to the envelope, not the from line,
I don't consider it much of an issue.
Again, in this case certain source addresses
should *never* receive automatic responses. The VACATION spec should
enumerate the well-known system and postmaster account names in addition to
specifying a VARIABLE that can be set on a per-site basis. [Hint: Sieve
should support variables, of some kind, and not leave the details to a
"implementation dependent" spec.]
What's the benefit to doing this in a variable? That is a MAJOR amount
of complexity to introduce, and there is running code that doesn't need
it. (We're talking about another ten pages of spec and breaking several
implementations for what immediately amounts to a minor feature.)
The only possible reason to not build-in a specific list of well-known
system addresses is because it is remotely possible that some site might
wish to include even these addresses in the vacation responses. This is an
extremely unusual case, and can be provided for by using an explicit Sieve
rule, without using VACATION.
No, an explicit rule doesn't help. Vacation is the only command that
responds to messages, and it won't respond to them.
Thus, IMHO, VACATION MUST NOT generate responses to a well-known set of
addresses, and, in addition, SHOULD support a site-specific or user-specific
list of addresses for which autoresponses will be avoided.
I am not convinced that this is the Right Thing, but we don't need
variables to do that. We can get by with the existing spec plus an if,
i.e.,
if not address :is :localpart "from" ["postmaster","mailer-daemon"]
{ vacation ... ; }
My point is that variables are overkill.
| > * does it generate replies to mail with any subject containing the text:
| > "[vacation]" or "[auto-response]"? If so, why? If not, are
| these the only
| > two strings that are recognized as being generated by an email
| > auto-responder.
|
| Yes, why not?
This is another Bad Idea. If my auto-responder replies to a message from
you about my being on vacation, and your auto-responder replies to that
message, you and I both will have contributed to at least one and possibly
two unecessary messages.
One of those messages is never unnecessary. If I send you mail, and get
a vacation, that message is mandatory; it's the whole point of this
spec.
Your question is cogent. There are other strings that should be avoided,
but this SHOULD be site- and user-configurable. However, even without any
site- or user-specification of specialized subject tokens, there should be a
set of DEFAULT tokens defined by the VACATION spec. So, I suggest these
VARIABLES:
[deleted]
We're going to have to put regexp into the Sieve spec eventually, in order
to make it easier to write rules, so we might as well do so with the
AVOID_SUBJECT variables.
You are handing me a loaded can of worms. We don't "need" regular
expressions. I don't want to have to write them up or reference a POSIX
spec that I don't have and can't afford.
I object to overloading the Subject header. It has a perfectly good
meaning that cannot be understood by (modern) computers and hacking
around it with globs or regexps is not a clean solution.
We should add yet another header that can be properly standardized that
marks a message as automatically generated without consent of a human on
the other end. I think this solves that problem, and should probably be
written up as yet another spec so that we don't have non-Sieve solutions
dependant on Sieve's vacation extension.
Would this solve that problem?
Tim