> 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?
> Note that associated with it is a long list of patterns that match 'senders to
> whom autoreply messages should not be sent'. My own implementation has an
> additional list of local addresses that generate mail but do not expect a
> reply.
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.
> Note also that there are a number of other conditions on an incoming message
> which indicate that a reply should not be sent; the 'personal' test
> encapsulates few of these. I guess even my own list is not exhaustive, but it
> does deal with the vast majority now.
>
> 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.
Perhaps it is time to change the common best practice, but from a
superficial view, I did not see what you added beyond RFC 3834 apart
from more local parts. Personally, I would like to avoid using the old
subject in the response, because it lets you bypass address verification
when subscribing a third party to a mailing list. Appearantly, that
does not happen (often), that's why my suggestion was not followed.
On the other side, people like seeing the subject in the response.
Other than that, I have no had any trouble by simply following it.
Michael
