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