On 2 Jul 1999, Joe Kelsey wrote:
> I just can't stand listening to Scott prattle on endlessly about his own
> ignorance anymore...
isn't that incorrect...
I'm not prattling on endlessly about my ignorance.
I mean, if you think trying to clarify things means that I'm ignoreant,
so be it, but that's not what you said.
> Scott D. Yelich writes:
> Dan writes his software the best way. Please enlighten us as to where
> he is wrong. You seem to have all the answers, please let us know.
I don't have all the answers... in fact, I'm looking for a few answers
-- but if what works for someone else doesn't work for me -- I'm called
an idiot. If I then ask for another solution or any other ideas or
quote someone or something that isn't much liked on this list -- I'm
told that I must know all the answers...
I don't. I wish I did.
> > (2) This list expects everyone to be an expert in everything (including
> > qmail) inherently and has this as a prerequesite to existing...
> Anyone who chooses to try to install and configure ANY MTA must by
> definition be an expert system administrator and able to "go with the
> flow" and think on their feet. RTFM and when that doesn't work, RTFS.
Everyone agrees that sendmail is much more complicated than qmail? right?
Don't be afraid to agree -- you know you want to...
Well, I've never had to read the source of sendmail in order to get it
to do something that I needed it to do. Sorry.
> Scott, you have proven over and over that you attempt to do things
> without even referencing the FAQ. I followed the directions in the FAQ
> and the various INSTALL, etc. files and had absolutely no trouble
Someone else stated that the FAQ was unable to get more specific
than a generic inetd reference. That's BS -- think about it --
look at the qmail uid install instructions that come with
qmail 1.03 -- are those not specific?
The faq could easily say: inetd syntax may be different on different
systems -- please be aware of your system's requirements....
and then give two examples (ie: solaris and linux) that show
not only how to do inetd on those two systems -- but that just
also happen to illustrate two different inetd syntaxes!
whoa! the faq just got better *and* more specific!
> installing and running qmail in under 3 hours on Solaris 7. Yes, I even
> found the conf-cc and conf-ld files and fixed them myself without
> pissing and moaning on the list---in fact, I wasn't aware of the list
> when I did it!
ME TOO! So, I bear questions for other sysadmins. The list happily
attributes it all to me -- it's not *my* fault that people here *assume*
and are being hostile to *me* for something that really isn't even an
issue to me. That why I say in private messages, I'm not upset... I
think it's mildly amusing, actually.
> > (3) If one is not an expert and speaks publically on the list, the
> > overly belligerent and pugnacious list has a habit of tearing them a new
> > virtual bodily orifice?
> The overly beligerence and pugnacity is all in your mind. You come here
> and prove your ignorance every time you post. You respond to simple
> answers with anger and whining. You have shown no desire to even try to
> fix what you perceive to be mistakes. Put up or shut up.
Do I prove my ignorance? What about Adam? What about Alex? What about
the people who tell me to use taildir when it won't run even after
fighting it to get it to compile? What about the people who tell me to
use ipfilter for solaris 7? What about the people who berate me for not
having cc installed!?! This guy says that CC has been installed,
default, on every system he has ever used and adminned for the last 7
years -- WELL GOOD FOR HIM -- now I invite him to install solaris.
The point is -- I look for solutions -- for ideas -- discussion...
choices. does this list provide any? this list tells me that if I
can't get qmail to work or if I have problems with the documentation --
to write better documentation. So this list wants a "qmail newbie" to
write qmail documentation? I've stated that I thought that was a silly
thing to suggest. Now someone is tearing Alex apart for his desire to
do just this!
Ok, so I put together a qmail 1.03 with rbl, patches for tarpitting, all
kinds of stuff and I want to share it and release it? can I? nope --
dan will sue.
Go figure.
> > (4) If that same person then makes anything less than a godly effort to
> > solve every problem affecting the universe, oh and qmail as well, then
> > they are berated into the oblivion of obscurity?
>
> You don't need to make a godly effort. Just show by your own words that
> you have some understanding of the concepts involved in networking. You
> continually express ignorance of the most basic subjects, such as how to
> search through the RFC index to find the appropriate RFC. Everyone has
> to go through the same pain---the index just isn't that good. But, the
> RFC's themselves are fairly small and it really doesn't take much time
> to find what you need. You obviously do not want to spend any of your
> oh so precious time doing any research on your own though.
time me.
go
Fri Jul 2 18:34:12 MDT 1999
ok, I found: http://rfc.x42.com/
<A HREF="http://rfc2219.x42.com/">2219</A> Use of DNS Aliases for Network Servi\
ces. M. Hamilton, R. Wright.
October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST
CURRENT PRACTICE)
Note that in this scenario no information about ph.hivnet.fr should
exist in the DNS other than the CNAME record. For example,
ph.hivnet.fr could not contain a MX record.
it doesn't say why.... it only says that none should be there -- bind
allows it... shouldn't bind NOT allow it if the rfc[s] state it
shouldn't be allowed? that's the only real reference to MX in that rfc.
2181 Clarifications to the DNS Specification. R. Elz, R. Bush. July
1997. (Format: TXT=36989 bytes) (Updates RFC1034, RFC1035, RFC1123)
(Updated by RFC2535) (Status: PROPOSED STANDARD)
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
it doesn't say why.... it only says that none should be there -- bind
allows it... shouldn't bind NOT allow it if the rfc[s] state it
shouldn't be allowed? that's the only real reference to MX in that rfc.
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
um. so?
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query.
Aha! something... but is that entirely true (about no data/information
being returned?)
1912 Common DNS Operational and Configuration Errors. D. Barr.
February 1996. (Format: TXT=38252 bytes) (Obsoletes RFC1537) (Status:
INFORMATIONAL)
Whoa! this one looks good.
2.4 CNAME records
A CNAME record is not allowed to coexist with any other data. In
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
can't also have an MX record for suzy.podunk.edu
Strange... bind seems to support this?
Don't use CNAMEs in combination with RRs which point to other names
like MX, CNAME, PTR and NS. (PTR is an exception if you want to
implement classless in-addr delegation.) For example, this is
strongly discouraged:
podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4
[RFC 1034] in section 3.6.2 says this should not be done, and [RFC
974] explicitly states that MX records shall not point to an alias
defined by a CNAME. This results in unnecessary indirection in
accessing the data, and DNS resolvers and servers need to work more
to get the answer. If you really want to do this, you can accomplish
the same thing by using a preprocessor such as m4 on your host files.
aha! not only a reason why... (indirection, repeated lookups), but a
way to avoid it -- by using m4! Now there's useful information.
Also, having chained records such as CNAMEs pointing to CNAMEs may
make administration issues easier, but is known to tickle bugs in
some resolvers that fail to check loops correctly. As a result some
hosts may not be able to resolve such names.
Aha! So, some buggy software might also not work with this....
should the software be fixed?
<A HREF="http://rfc1537.x42.com/">1537</A> Common DNS Data File Configuration E\
rrors. P. Beertema. October
1993. (Format: TXT=19825 bytes) (Obsoleted by RFC1912) (Status:
INFORMATIONAL)
This one doesn't even seem to have the text "cname" in it anywhere.
1536 doesn't seem to talk about it either.
Fri Jul 2 18:54:08 MDT 1999
20 minutes? not quite 5... but I have not done some homework and
even put it here for the people who simply assume that I didn't
look at faqs or rfcs.
Ok, no RFC says that CNAMES are valid for MXes. Several tend to talk
about why CNAMES might be bad for certain records, etc., ok, fine.
I'll chage my question to a new one: WHY DOES BIND ALLOW THIS IF IT IS
SO UNIVERSALLY APPALED AND CONDEMNED?
Seems just a wee bit silly to me. Next I'll find that it's become
standard practice not to allow hostnames with "_"s in them or some other
arbitrary char... ok, so "@" might be bad, I can see that... but why "_"
-- oh, for the same reason. Oh not! What about the letter "A" ?
> > (5) If that person returns from oblivion with suggestions that just
> > might make qmail a better place - they are then subjected to repeated
> > ridicule for any perceived weakness in their character simply for
> > attempting to help make the (qmail) world a better place?
> You have never made a single constructive suggestion on this list. I am
> waiting for your first suggestion. What is it?
My suggestion is that the list be a little more forgiving for those who
are apparently attempting to learn qmail. Doesn't that account for
*anything* ?
Why assume that someone is the enemy just because they are asking a
question about why something is so? If they don't accept your answer on
faith -- hell, they don't know you from Adam (sorry, I thought the joke
would fit in well...) and perhaps just want a little more information.
Here is my conclusion... and what I tell peopel who ask *me* why
CNAMES aren't allowed for MXes:
``CNAMES are basically aliases and have been deemed to be apparently
only appropriate in certain DNS record specifications. The reasons for
this appear not to be entirely clear or well documented, but may stem
from reasons concerning multiple-repeated use of resources which may be
wasteful or from historic or other archaic reasons. However, in the
case MX records pointing to CNAMES, this is easily overcome by having
the target of the MX record simply having an A record -- as multiple A
records is valid, at least for now. This technique more than likely
accomplishes what was intended through the use of the CNAME target for
the MX without going against the DNS specifications. However, the case
and solution isn't as clear for other DNS records and what is valid
where -- luckily these records don't have the limelight that MX records
have.''
or something like that...
> answers with anger and whining. You have shown no desire to even try to
> fix what you perceive to be mistakes. Put up or shut up.
[DELETED]
> You have never made a single constructive suggestion on this list. I am
> waiting for your first suggestion. What is it?
I simply ask why... and sometimes when I'm given an answer I find
difficult to accept, I ask why again. At that point I am berated and
insulted.
I find it reprehensible to insult people for their opinions when they
are trying to learn! You know, they might just be trying to form a new
opinion.
Please think about that.
Scott
