On 6 November 2011 04:22, David Southwell <da...@vizion2000.net> wrote: > On Saturday 05 November 2011 22:40:03 Murray S. Kucherawy wrote: >> > -----Original Message----- >> > From: owner-postfix-us...@postfix.org >> > [mailto:owner-postfix-us...@postfix.org] On Behalf Of David Southwell >> > Sent: Saturday, November 05, 2011 9:41 AM >> > To: postfix-users@postfix.org >> > Cc: /dev/rob0 >> > Subject: Re: executive parser (was: Re: spf configuration woes) >> > >> > Just to add weight to my last posting - the use of a " " as a critical >> > symbol is really quite idiotic. What cannot be seen should never be that >> > significant! >> >> The current RFC defining email message format is RFC5322, and it uses >> leading whitespace as line continuation in header fields. Its >> antecedents, going back as far as RFC733 (1977) and perhaps further, do >> the same thing. Thus, your assertion appears to be in conflict with quite >> a bit of operational history and experience. > > I think what is being forgotten here is that administrators have to cope with > a whole variety of software. The history of one narrow sphere (e.g.) mail is
I think what is being forgotten here is that YOU were too stupid to add an spf filter to some of the most widely used MTA SW on the web. And when you finally figured it out* you chose to be hostile, arrogant and rude. figured it out = had your hand held. Ideally it seems you wanted someone to write your master.cf for you It should be noted I installed an SPF policy a few weeks ago - which I accomplished in less time, with less mails to the list and less coding experience (and a good deal more reading of the documentation). > Hence thoughtful engineers incorporate diagnostic parsers and html > configuration tools. IMHO postfix has been very slow to develop an apporocah > which places the needs of system administrators in the forefront of its > development strategy. > > People make mistakes. Even the most experienced administrators. Administrators > are not primarily programmers. They look at configuration files. During a busy > day they do not want the hassle of having to ask themselves the question "What > do spaces do in this .config .cf file?" Good configuration files make their > formatting requirement obvious. That is why I say the use of " " is, in an > administrator's context, idiotic. It is idiotic because it demands that > adminstrator to ask himself/he > rself the question is this " " significant or insignificant. When there are > hundreds of " " in a file the luckless adminstrator has too much on his/her > plate when trying to fix a problem as quickly as possible. Administrators should be asking themselves all the time if something is significant or not. Everytime I see an indendation I wonder if it's supposed to be a space, a run of spaces or a tab. And what the effects of aligning them all with tabs might be. You are clearly not an administrator. > I have been taking this list silently for years. Amonst a lot of genuinely > helpful contributions I have witnessed a regular splattering of rudeness and > arrogance by some long standing contributors heaped on the heads of luckless > administrators trying to succesfully configure postfix. I had no idea luckless meant to dumb or lazy to follow instructions.. You say you'd run netstat before Wietse asked you to? That being the case, why - in either of the responses immediately after that suggestion did you not simply say "I did that - here's the output". For the luckless administrator in you I'd like to point out that ignoring something someone (indeed the only person engaged on issue) asks you twice to do something and you ignore it that is also rude. And when you get called on that rudeness you complain?!? > The design of Postfix's configuration system and supporting documentation > represents the honest efforts of people who have a single point of focus > namely: > > Making postfix work when it has been given the appropriate configuration data. As does every other piece of SW in the entire world. > IMHO Postfix needs to add to its goals a determination to make configuration a > breeze rather than a challenge. That means diagnostic and corrective parsers > and or an html based configuration interface. Such facilities would cut down > the traffic on this list and stop a few people looking down their noses at > thuose who make a mistake. You want to make it fool-proof? You'll only build a better class of fool to defeat it.
