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