[exim-dev] [Bug 635] Add "noreply" and "do_not_reply" to per…

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Michael Haardt
Ημερομηνία:  
Προς: exim-dev
Αντικείμενο: [exim-dev] [Bug 635] Add "noreply" and "do_not_reply" to personal test
------- 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@???> 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