------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=635
--- Comment #4 from J R Binks <jethro.binks@???> 2007-11-29 09:28:40 ---
(In reply to comment #3)
> > One reason why I do not like using the autoreply feature of the Exim filter is
> > because the 'personal' test is not flexible enough.
>
> The personal test reflects common best pratice as documented in RFC 3834.
> In filters, it is just a shortcut and you could easily add more conditions.
>
> > In my case, I use a vacation router/transport to generate autoreply (vacation)
> > messages. Easier for the users: they just put their message into a file, and
> > do not have to worry about filter syntax. My method is documented at:
> > http://wiki.exim.org/EximAutoReply
>
> I disagree with never answering role accounts, because it makes
> using them useless. If I write to info@*, and a human responds (a
> common experience to me), and I have an automatic reply configured, it
> should be sent. Since you already wrap autoresponse functionality,
> why extend the personal test instead of generating filter files with
> additional tests?
Ian wraps, not me :)
> Note the option never_mail in the autoreply transport for address lists.
>
> Many tests for local parts are not needed, because "Auto-submitted:" is
> set, and that's how it should be. It is a rather young extension, and the
> list of local parts is for software from the age before that is still in
> use. It's not something to extend, but the use of "Auto-submitted:" is.
In principle, I agree. Messages that don't want to receive autoreplies in
return should set Auto-submitted: headers. However real life is not like that,
and very very few systems do. Very very few systems send messages with empty
sender "<>"; as Ian comments "noreply@..." and such addresses are often used in
both From: field and SMTP sender.
My primary motivation is preventing autoreplies where they are not wanted and
are possible harmful; for example, we may be seen to be a source of collateral
spam. Some anti-spam experts are vociferous about inappropriate autoresponse
mechanisms. I would prefer not to send an autoreply, than send one to
somewhere it is not wanted and possibly harmful or annoying to someone else.
> > My feeling is that the conditions used by the 'personal' test need to be
> > directly configurable by the server administrator, so that user filters using
> > the test benefit from lists such as the above.
>
> If you feel that way, I suggest you talk to the author of RFC 3834.
I welcome the day when every system generating emails automatically does so
using approved fields from that document. It's hard enough getting people
implementing systems within my University to understand why they should do so,
even when I can sit with them and talk them through it for an hour.
The whole issue of generating new email messages in response to messages
received, in this world of spam and collateral spam is highly contentious.
Some believe that 'vacation' systems as a whole are an anacronism from a world
where everyone was nice. It's a different world now. RFC 3834 is really an
attempt to keep autoresponse mechanisms reasonable in the new hostile world,
but unless it is widely implemented, it is useless. I see little widespread
implementation in vendor products, or amongst the companies who auto-generate
messages for whatever reasons.
Indeed, the recent implementation of Yet Another Indicator Of Automatically
Generated Mail by Microsoft, in the form of the X-Auto-Response-Suppress:
header, shows that vendors really aren't listening to the Best Practice. No
change there then.
Even if they did listen, the legacy crud is still out there.
I would suggest we add some notes to the AutoReply wiki page to discuss some of
these issues, so that people attempting an implementation can consider all the
issues for themselves. I've never claimed my method is best, but it works for
me, and I think it strikes a reasonable balance. In particular, I don't think
the 'personal' test in filters is discussed on that page, and probably should
be.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
