Mailing List Archive

------- 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 #2 from Ian Eiloart <iane@sussex.ac.uk> 2007-11-28 12:25:28 ---
--On 28 November 2007 09:35:44 +0000 J R Binks <jethro.binks@strath.ac.uk>
wrote:

>
> 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

Mine don't have to worry about that either, I provide a web application
which provides a default message that they can modify. It then wraps that
message in a set of conditions:
message must be personal with aliases drawn from our LDAP database,
message must have very low spamassassin score
once_repeat: 7 days

Comments are added, giving the script version number, the date of editing,
and the client IP address.

However, I do like your approach, and will probably implement something
like it.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

> 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

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #3 from Michael Haardt <michael.haardt@freenet.ag> 2007-11-29 09:01:16 ---
> 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


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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@strath.ac.uk> 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

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #5 from J R Binks <jethro.binks@strath.ac.uk> 2007-11-29 09:57:15 ---
(In reply to comment #4)

> 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 have now expanded the wiki page somewhat, with more introductory text and
references, and a warning about considering entries on the local parts list.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #6 from Michael Haardt <michael.haardt@freenet.ag> 2007-11-29 10:03:15 ---
> 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.

RFC 3834 suggests not to answer to spam already.

> > 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.

You misunderstood me. RFC 3834 documents common best practice.
Such practice may change, and if it does, it is time for a new RFC.
My experience on asking RFC authors is very positive and if the RFC
changes, or an important draft is out, changing Exim will be way easier.

> 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.

The structure of my filter is to first sort spam out and what remains
goes to the inbox and is processed by vacation. That avoids responses
to spam without extra checks.

If anything, SMTP is an anachronism. ;-)

Asked differently: Those who send newsletters from noreply@* in both
header and envelope, and get flooded with automatic responses just get
what they deserve, don't they? What's wrong there? How could it harm
the sender of the response?

> 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.

Yes and no. Microsoft indeed does not care much about RFCs, but I know
quite a few people running an open source MTA in front of Exchange to
take care of all that crap.

My point is: If common best practice as documented by RFC 3834 is not
common or even best practice, then change the RFC and have at least all
MTAs of vendors/authors who care follow. "Works for me" is the least
work, but it may not be as good as the result of the first alternative.
Start with a set of suggested changes to the RFC and a broader audience
will listen.

Michael


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #7 from J R Binks <jethro.binks@strath.ac.uk> 2007-11-29 10:39:01 ---
(In reply to comment #6)

> RFC 3834 suggests not to answer to spam already.

Well of course. Assuming you can identify it. But spam is not the only
traffic to which responses should not be sent.

> You misunderstood me. RFC 3834 documents common best practice.
> Such practice may change, and if it does, it is time for a new RFC.
> My experience on asking RFC authors is very positive and if the RFC
> changes, or an important draft is out, changing Exim will be way easier.

I disagree: RFC 3834 does not document common best practice, it documents
desired practice. It is titled: "Recommendations for Automatic Responses to
Electronic Mail" and the abstract says: "This memo makes recommendations for
software that automatically responds to incoming electronic mail messages ...
The purpose of these recommendations is to discourage undesirable behavior
...". The phrases "best practice" or "common practice" or variants do not
appear once.

I do not know if the author believed that he was documenting "common best
practice", but the final document is not written that way. It is a set of
rules which it is desired people follow, but there is no suggestion that any of
them are widely implemented at the time of writing. In essence, it is an
academic retro-fit to fix a problem that has emerged, and for the first time
(as far as I know) documents the notion that there are several sorts of
"automatic message", and that they need to be separately identified and dealt
with in different ways.

> If anything, SMTP is an anachronism. ;-)

I actually nearly wrote that :).

> Asked differently: Those who send newsletters from noreply@* in both
> header and envelope, and get flooded with automatic responses just get
> what they deserve, don't they? What's wrong there? How could it harm
> the sender of the response?

That's a very particular example to choose! Why send mail you don't need to
send? I agree that those people may deserve it, but that doesn't mean we
should not try to avoid doing so anyway, where it is obvious an autoresponse is
a fruitless exercise. In particular, the RFC says: "Responders are encouraged
to check the destination address for validity before generating the response,
to avoid generatingresponses that cannot be delivered or are unlikely to be
useful.".

> > 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.
>
> Yes and no. Microsoft indeed does not care much about RFCs, but I know
> quite a few people running an open source MTA in front of Exchange to
> take care of all that crap.

And I know many who are not, and unfortunately I receive mail from them and
have to come to some decision whether or not it is appropriate to send an
autoreply to some of that mail. So what Microsoft and other vendors do does
matter.

> My point is: If common best practice as documented by RFC 3834 is not
> common or even best practice, then change the RFC and have at least all
> MTAs of vendors/authors who care follow. "Works for me" is the least
> work, but it may not be as good as the result of the first alternative.
> Start with a set of suggested changes to the RFC and a broader audience
> will listen.

If RFC 3834 is supposed to be documenting real "common best practice", then it
should be written that way, but it isn't. It documents idealised theoretical
solutions to the problems based on real-world experience and observation, in
the hope that implementors will follow it. It does not document common
implementations as of today (and certainly not of 3 years ago when it was
written).

I do not know how you persuade vendors to follow any recent RFC, given that
many of them are so lax at following those that are over 20 years old, and even
if they do so from now, there is still years of legacy crud out there that
isn't going away, and has to be dealt with. That's the practicalities of the
situation on the ground.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #8 from Michael Haardt <michael.haardt@freenet.ag> 2007-11-29 11:31:38 ---
> That's a very particular example to choose! Why send mail you don't need to
> send? I agree that those people may deserve it, but that doesn't mean we
> should not try to avoid doing so anyway, where it is obvious an autoresponse is
> a fruitless exercise. In particular, the RFC says: "Responders are encouraged
> to check the destination address for validity before generating the response,
> to avoid generatingresponses that cannot be delivered or are unlikely to be
> useful.".

Right, it is a particular example. How different is it from a user
who picks the mail address "donotreply", because he thinks it is
funny? Running a large mail service, I often smiled about the addresses
people pick, and *no.?reply* is a pattern that yields many addresses.
There is no reason why they should not work. It is bad enough listserv
and friends burned a couple local parts. Mailman on the other side
obeys RFC 3834 and needs no additional checks.

> If RFC 3834 is supposed to be documenting real "common best practice", then it
> should be written that way, but it isn't. It documents idealised theoretical
> solutions to the problems based on real-world experience and observation, in
> the hope that implementors will follow it. It does not document common
> implementations as of today (and certainly not of 3 years ago when it was
> written).

The rules given try to work for legacy systems, too, as can be seen
from the checks for particular well known local parts. You state they
do not, and I say: Start with suggested changes to make a successor of
RFC 3834 even more useful. What's wrong? What's missing? A bunch of
MTAs do care, and changing all those is better than just changing Exim,
plus a consensus among experts in the area may give even better results
than just a quick patch that works for a single person.

Sometimes, it's really the Internet Engineering Troll Force, but most
of the time, people on IETF lists are a very productive and helpful
community.

Michael


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

------- 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 #9 from Ian Eiloart <iane@sussex.ac.uk> 2007-11-29 12:10:17 ---
--On 29 November 2007 09:01:17 +0000 Michael Haardt
<michael.haardt@freenet.ag> wrote:

>
> Note the option never_mail in the autoreply transport for address lists.
>

Ah! That's just what I need. I don't want to add a condition in my wrapper,
because I have hundreds of messages written already. Also, my web
application has an "expert mode" where people just hand-craft their
filters.

I guess a cross reference in the documentation would have got me there, but
thanks for this!


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email

--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##