Re: [Exim] Administrivia - Christmas is coming, the autorepl…

Top Pagina
Delete this message
Reply to this message
Auteur: Exim Users Mailing List
Datum:  
Aan: Marc MERLIN
CC: Exim Users Mailing List
Onderwerp: Re: [Exim] Administrivia - Christmas is coming, the autoreplies are getting fat
[ On Sunday, December 16, 2001 at 15:27:43 (-0800), Marc MERLIN wrote: ]
> Subject: Re: [Exim] Administrivia - Christmas is coming, the autoreplies are getting fat
>
> As if we were the ones using the broken stuff. It's the people creating
> loops who do, not us. I'm merely advocating more ways to deal with broken
> stuff because their brokenness affects me.


You're a very confused person Marc. Perhaps you could go back to
Nigel's original posting in this thread and start over. We're both
working to the same end here. I just happen to have a proven answer
already implemented.

> You chose to ignore that and want to confine yourself to what you think the
> RFCs say (for the record, I somewhat agree with your interpretation), but
> again, I do not limit myself to what RFCs say, I also look at the real
> world.


Perhaps you should learn to tread a little more carefully before you go
beyond the RFCs since they are in fact created by people living in the
real world and they are meant for application in the real world (even if
it sometimes seems as if they're meant for a slightly dated version of
our real world today). The IETF is not an ivory tower organisation. It
is quite literally the current collection of concerned people living
directly in the trenches of our ``real world.'' Perhaps if you think
they are making the wrong decisions then you should participate in their
process and at least learn why they've done things as they've done, and
maybe even influence them with your own experiences if your corner of
the real world.

> You chose to ignore the real world and live in your world of RFCs, and fully
> RFC compliant people.


I live in the real world where interoperability rules, and where it's
only intentionally blocked by policy decisions that have been made after
taking great care to measure the events of the real world and to observe
and predict all the effects and consequences of such policy decisions.

(in case you're wondering about the qualifiers, that's a
C.Y.A. statement intended to deflect complaints that I myself
don't always follow the RFCs 100% either! ;-)

> My point has been that you limit yourself in doing so, which is fine when
> you run your mail server, but not fine when it affects other people's
> mailing lists and mail servers.


You should try to wake up and smell the coffee Marc. Your nightmares
wouldn't be so bad if you listened to some common sense instead of
trying to figure things out all on your own when you're lost in a forest
of details and cannot see the bigger picture. The correct way of doing
things happens to make your life as a mailing list operator and
postmaster much easier. This I know from my own experience in the same
capacity.

> You are correct, in some configs, you will not be able to set it.
> Well, you just loose one of the loop avoidance mechanisms. There are still a
> few left, "Precedence:" being the first one obviously


Unfortunately the "precedence:" header is the least of one's defenses.
It's an ``ideal world'' mechanism only. The real defense is called
``rate limiting'' and has been implemented by BSD Vacation since at
least 1990, and perhaps even since its inception in 1983, though I don't
have a copy of the original to check. It's such a powerful and
successful mechanism that it makes all your whining and crying about the
problem, and even Nigel's subtle attempt at giving duplicate advice,
quite unnecessary, and silly in hind-sight.

(That doesn't mean we should stop using "precedence:" -- quite the
contrary! We should promote it instead! It has the advantage of being
a very user-visible indicator.)

> No, I will not reconfigure my mail to relay through different mail servers
> depending on where I plug my laptop, no I will not change my MTA's config to
> say helo with whatever IP it happens to sit behind when I flush the queue.


Perhaps you should read a few RFCs written from real-world perspectives
and learn a bit more about how to properly configure a workstation
automatically.

--
                                Greg A. Woods


+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>