Re: Qmail Documentation (was addresses containing . )
Russell Nelson <[EMAIL PROTECTED]> writes:
> ... I would say that qmail-smtpd should access a
> cdb which is constructed from locals + virtualdomains + a new file
> named receivebysmtp, which has lines that start with a + if the host
> should be acceptable for receipt via SMTP, and a minus if the host
> should not be acceptable (which is another way of saying "was found in
> locals or virtualdomains but we wish to reject").
I'd like to consider going a step further, with a single CDB that
contains the *entire* site configuration policy. This would include
rcpthosts, localhosts, virtualdomains, users, aliases, and smtproutes.
This would be used by qmail-smtpd, to decide what to accept (both for
"I don't relay" and "Unknown user" purposes) and by qmail-send as it
routes mail. As a bonus, a small tool could query this and allow an
admin to check how qmail is going to handle a given address.
It would presumably require progressively stripping an address until a
match came up, possibly along the lines of:
[EMAIL PROTECTED]: accept, local ~adb
[EMAIL PROTECTED]: accept, alias [EMAIL PROTECTED]
@onramp.ca: reject 550 Unknown user {since no specific-user records matched}
.example.com: accept, relay { for a customer }
.private.onramp.ca: accept, route 10.11.12.13
@virtual.example.com: accept, virtual ~exam
default: norelay { unless RELAYCLIENT is set }
Hmm, it might also be nice to check MAIL FROM: against that database, and
refuse to relay for users who have set their address to a local one that
we know does not exist; that way their POP client tells them the error of
their ways immediately. Configuration errors like that are the second
largest source of doublebounces.
--
Anthony DeBoer <[EMAIL PROTECTED]>
Re: Qmail Documentation (was addresses containing . )
On Thu, Feb 18, 1999 at 08:10:20AM -0500, [EMAIL PROTECTED] wrote: > On Thu, 18 Feb 1999, Peter van Dijk wrote: > > > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > > > On Wed, 17 Feb 1999, Chris Naden wrote: > > > > > > for qmail-send: for its description of locals to explicitly say that > > > virtual domains should *not* be placed in locals? > > > > > > for qmail-smtpd: for its description of rcpthosts to say that it > > > should contain all the hosts in locals and virtualdomains plus > > > those hosts you act as MX for. > > > > > > Actually, in stead of the latter suggestion, I'd prefer that there be > > > another control file: mxhosts, and drop rcpthosts, which is just > > > confusing everyone. Then we have simple explanations for what goes where. > > > You're not saying that qmail-smtpd should just read in locals and > > virtualdomains and accept mail for all domains in there, right? > > No. I was suggesting replacing rcpthosts with mxhosts and having > smail-smtpd read virtualdomains, locals and mxhosts. Having looked at > "man qmail-control" I've decided that the reason Dan did things this way > is that qmail-smtpd only has to read/check one file (rcpthosts), rather > than three (virtualdomains, locals and mxhosts). It's a typical tradeoff: > simpler program vs requiring people to read the documentation and put the > right things in rcpthosts. err.. aahh!!! I have local-only domains that _are_ in locals or virtualdomains, but not in rcpthosts. And I don't want 'm to either. The suggestion Russ posted is what I'm looking for (no rcpthosts, but smtpd accepting mail for all domains in locals, virtualdomains and mxhosts, and a way to list domains _not_ to accept mail for, even though they are in one of the first two files). Greetz, Peter. -- .| Peter van Dijk | stoned worden of coden .| [EMAIL PROTECTED] | dat is de levensvraag | coden of stoned worden | stonend worden En coden | hmm | dan maar stoned worden en slashdot lezen:)
Re: Qmail Documentation (was addresses containing . )
On Thu, Feb 18, 1999 at 12:03:33AM -, Russell Nelson wrote: > Scott Schwartz writes: > > Peter van Dijk <[EMAIL PROTECTED]> writes: > > | You're not saying that qmail-smtpd should just read in locals and >virtualdomains and > > | accept mail for all domains in there, right? > > > > Of course it should! (cdb optional.) That avoids the whole multiple > > redundancy plus illogical defaults problem that the current scheme > > suffers from. > > > > If you want an optional rcpthosts or mxhosts for special cases, then > > fine, that's a special case, which mostly no one will ever need to know > > about. > > You still need to be able to subtract local-only domain names, and add > non-local domain names. I would say that qmail-smtpd should access a > cdb which is constructed from locals + virtualdomains + a new file > named receivebysmtp, which has lines that start with a + if the host > should be acceptable for receipt via SMTP, and a minus if the host > should not be acceptable (which is another way of saying "was found in > locals or virtualdomains but we wish to reject"). Amen to that! Greetz, Peter. -- .| Peter van Dijk | stoned worden of coden .| [EMAIL PROTECTED] | dat is de levensvraag | coden of stoned worden | stonend worden En coden | hmm | dan maar stoned worden en slashdot lezen:)
Re: Qmail Documentation (was addresses containing . )
On Thu 1999-02-18 (08:10), [EMAIL PROTECTED] wrote: > On Thu, 18 Feb 1999, Peter van Dijk wrote: > > > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > > > On Wed, 17 Feb 1999, Chris Naden wrote: > > > > > > for qmail-send: for its description of locals to explicitly say that > > > virtual domains should *not* be placed in locals? > > > > > > for qmail-smtpd: for its description of rcpthosts to say that it > > > should contain all the hosts in locals and virtualdomains plus > > > those hosts you act as MX for. > > > > > > Actually, in stead of the latter suggestion, I'd prefer that there be > > > another control file: mxhosts, and drop rcpthosts, which is just > > > confusing everyone. Then we have simple explanations for what goes where. > > > You're not saying that qmail-smtpd should just read in locals and > > virtualdomains and accept mail for all domains in there, right? > > No. I was suggesting replacing rcpthosts with mxhosts and having > smail-smtpd read virtualdomains, locals and mxhosts. Having looked at > "man qmail-control" I've decided that the reason Dan did things this way > is that qmail-smtpd only has to read/check one file (rcpthosts), rather > than three (virtualdomains, locals and mxhosts). It's a typical tradeoff: > simpler program vs requiring people to read the documentation and put the > right things in rcpthosts. I quite like the way Dan has made rcpthosts work. It allows you to easily specify who you'll receive mail for in one place. The only thing that I'd like is for the behaviour when rcpthosts doesn't exist to change. Since the "normal" thing is for rcpthosts to be locals + virtualdomains I think that this should be the default if rcpthosts doesn't exist. - Keith -- Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa Email : [EMAIL PROTECTED] WWW : http://www.rucus.ru.ac.za/~keith/ IRC : Panthras JAPH "Any technology sufficiently advanced is indistinguishable from a perl script" Standard disclaimer. ---
Re: Qmail Documentation (was addresses containing . )
On Thu, 18 Feb 1999, Peter van Dijk wrote: > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > > On Wed, 17 Feb 1999, Chris Naden wrote: > > > > for qmail-send: for its description of locals to explicitly say that > > virtual domains should *not* be placed in locals? > > > > for qmail-smtpd: for its description of rcpthosts to say that it > > should contain all the hosts in locals and virtualdomains plus > > those hosts you act as MX for. > > > > Actually, in stead of the latter suggestion, I'd prefer that there be > > another control file: mxhosts, and drop rcpthosts, which is just > > confusing everyone. Then we have simple explanations for what goes where. > You're not saying that qmail-smtpd should just read in locals and > virtualdomains and accept mail for all domains in there, right? No. I was suggesting replacing rcpthosts with mxhosts and having smail-smtpd read virtualdomains, locals and mxhosts. Having looked at "man qmail-control" I've decided that the reason Dan did things this way is that qmail-smtpd only has to read/check one file (rcpthosts), rather than three (virtualdomains, locals and mxhosts). It's a typical tradeoff: simpler program vs requiring people to read the documentation and put the right things in rcpthosts. I think I'll just make things work the way I want by making my own mxhosts and having an automatic procedure which builds rcpthosts appropriately. Or better yet, make the procedure which builds morercpthosts do it my way. > Greetz, Peter. > -- > .| Peter van Dijk | stoned worden of coden > .| [EMAIL PROTECTED] | dat is de levensvraag > | coden of stoned worden > | stonend worden En coden > | hmm > | dan maar stoned worden en slashdot lezen:) > -- "Life is much too important to be taken seriously." Thomas Erskine<[EMAIL PROTECTED]>(613) 998-2836
Re: Qmail Documentation (was addresses containing . )
Scott Schwartz writes: > Peter van Dijk <[EMAIL PROTECTED]> writes: > | You're not saying that qmail-smtpd should just read in locals and virtualdomains >and > | accept mail for all domains in there, right? > > Of course it should! (cdb optional.) That avoids the whole multiple > redundancy plus illogical defaults problem that the current scheme > suffers from. > > If you want an optional rcpthosts or mxhosts for special cases, then > fine, that's a special case, which mostly no one will ever need to know > about. You still need to be able to subtract local-only domain names, and add non-local domain names. I would say that qmail-smtpd should access a cdb which is constructed from locals + virtualdomains + a new file named receivebysmtp, which has lines that start with a + if the host should be acceptable for receipt via SMTP, and a minus if the host should not be acceptable (which is another way of saying "was found in locals or virtualdomains but we wish to reject"). -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: Qmail Documentation (was addresses containing . )
Peter van Dijk <[EMAIL PROTECTED]> writes: | You're not saying that qmail-smtpd should just read in locals and virtualdomains and | accept mail for all domains in there, right? Of course it should! (cdb optional.) That avoids the whole multiple redundancy plus illogical defaults problem that the current scheme suffers from. If you want an optional rcpthosts or mxhosts for special cases, then fine, that's a special case, which mostly no one will ever need to know about.
Re: Qmail Documentation (was addresses containing . )
On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > On Wed, 17 Feb 1999, Chris Naden wrote: > > for qmail-send: for its description of locals to explicitly say that > virtual domains should *not* be placed in locals? > > for qmail-smtpd: for its description of rcpthosts to say that it > should contain all the hosts in locals and virtualdomains plus > those hosts you act as MX for. > > Actually, in stead of the latter suggestion, I'd prefer that there be > another control file: mxhosts, and drop rcpthosts, which is just > confusing everyone. Then we have simple explanations for what goes where. You're not saying that qmail-smtpd should just read in locals and virtualdomains and accept mail for all domains in there, right? Greetz, Peter. -- .| Peter van Dijk | stoned worden of coden .| [EMAIL PROTECTED] | dat is de levensvraag | coden of stoned worden | stonend worden En coden | hmm | dan maar stoned worden en slashdot lezen:)
Re: Qmail Documentation (was addresses containing . )
At 12:33 PM 2/17/99 -0500, you wrote: >> You are right again. After ppl have pointed me to the appropriate >> place (not all of which are easy to find if you're a relative >> novice in sysadmin terms) everything *is* in the docs. Understanding >> it once it's there is another matter. New sysadmin's have to learn > >I wasn't meaning to come across as mad-at-you, and I hope you didn't take >it that way. Not at all... *8-) > That's why I >suggested reading *all* the man pages; unless you're a slow reader, you >can do it in an evening. If you've even skimmed them all, you'll remember >vaguely what's there. True; when I read the FAQ I was in a hurry and only read the immediately relevant entry, I intend now to remedy that. Let's face it guys, it all works because you guys help >> out the new guys, who become experienced and help out more new guys. >> That's why we're a *community* right? > >That's why I answered your original question; I do agree with you. On >the other hand, it does get old answering FAQs. > >Anybody who's new to qmail, please do yourself and the list a favour: >read the FAQ, all of it. Thoroughly agreed, and my own guilt admitted in my followup below. However, I have retained my comment about community because I'm going to return to it later. >[snip] >> Qmail documentation is impressive in it's comprehensiveness but >> it is a little less so in it's comprehension. It can be very difficult >> to understand what is being said, be it as it may that what is said >> is entirely accurate. This is partly to expand for later comment. What I mean here is that if you are new to the unix admin community and terminology and *concepts*, thought patterns (eg me; I've been involved for all of 6 months, sporadically because I have this work thing getting in the way *8-) then qmail documentation can be confusing not through innaccuracy but through assumed knowledge. It's written for the experienced/talented, by the experienced/talented. Not a fault in the documentation, but a good reason for the help that you guys provide in this list here. > >> The fact that everything can be found and that some questions are >> stupid (the particular question I asked which prompted this thread >> happens to be one of them; if I'd re-read the FAQ rather than the >> list archives I'd have caught it myself) doesn't mean that ppl, >> particularly people new to the game like myself, are going to need >> *and*benefit*from* advice and help from more experienced users like >> yourselves. > >Again, I agree with you that newcomers will need some help, and it's the >job of more experienced people to help them. (Imagine how much better the >real world would work if we used this thinking there, but I digress :-). >We just wish that more people would read the documentation, especially the >FAQ. True, sir; I thoroughly agree with you both in content and in digression. But as above, reading the docs (which in this particular case I didn't but in others I have done and still gone slightly or majorly wrong) is not synonymous with fully understanding what's going on. >> Do, please, be tolerant and patient with us; we do learn, it's > >Yeah, I'm getting snippy in my old age [smarten up Tom ] >Sorry about that. My response to your rant was as much an over-reaction as anything you might have said. I've seen similar but stronger-worded rants frequently in different lists/faq's/news groups over the last few weeks, and i guess my response was building. The feeling is rapidly appearing among the experienced of the internet that the clueless are a bad thing. I (possibly because I am a teacher of sorts at times) view the clueless as tomorrows experts and feel it to be my job to help 'em get there if I know more than they do. I know ppl who are capable of working out linux and similarly mind-bending things effectively from first principles by having an os to play with and then playing. I also know that the majority of us are simply not in that league. Of the various forums in which I've tried to get help recently (and there are a few; my inexperience is farily wide-spread in this sphere) the two most universally helpfull have been this list and the apache-ssl list. The only reason the rant that I responded with got posted here, I guess, is actually because I think here it would be usefully recieved in a way that in some more cliquey forums it would be simply ignored/flamed. I certainly implied no serious personal criticism of either Tom or anyone else here. Thanks for your extended attention, cHris
Re: Qmail Documentation (was addresses containing . )
On Wed, 17 Feb 1999, Chris Naden wrote: [snip] > > > >I've heard many people complain about the lack of documentation that comes > >with qmail; I'd like to put in a contrary opinion. I've never seen so > >completely documented a system. Everything is there. The only gotcha is > >that, apart from the FAQ, nothing is repeated. The moral of the story is: > >read through *all* the qmail docs quickly once, or at least read the FAQ. > > > > > > You are right again. After ppl have pointed me to the appropriate > place (not all of which are easy to find if you're a relative > novice in sysadmin terms) everything *is* in the docs. Understanding > it once it's there is another matter. New sysadmin's have to learn I wasn't meaning to come across as mad-at-you, and I hope you didn't take it that way. There are many different right ways to configure qmail and to find the one that's right for you requires that you understand how qmail works. It's not difficult, but there is a lot of it. That's why I suggested reading *all* the man pages; unless you're a slow reader, you can do it in an evening. If you've even skimmed them all, you'll remember vaguely what's there. I admire Dan's documentation for coverage: everything's there. On the other hand, something a bit more like the original Perl book, starting off using it, then documenting commands and finally some cookbook-style recipies might be easier to take. However, if you print /var/qmail/doc/* and /var/qmail/man/cat*, and order it appropriately, you've almost got it. But then you've got a book, effectively. [Everybody will appreciate it when the qmail book is available.] > somewhere. If they haven't the advantage of a degree, they have to > learn from the friendly and helpful people who make up the internet > community. Let's face it guys, it all works because you guys help > out the new guys, who become experienced and help out more new guys. > That's why we're a *community* right? That's why I answered your original question; I do agree with you. On the other hand, it does get old answering FAQs. Anybody who's new to qmail, please do yourself and the list a favour: read the FAQ, all of it. [snip] > Qmail documentation is impressive in it's comprehensiveness but > it is a little less so in it's comprehension. It can be very difficult > to understand what is being said, be it as it may that what is said > is entirely accurate. One example of this is the sheer number of ppl > (I was one and i@ve seen the thread recur several times just in the > month I've been here) who read the setup info as instructing them to > place virtual domains in rcpthosts, virtualdomains *and*locals*; the > documentation isn't wrong, but it's quite easy to misunderstand. I personally don't read it that way, but you're right that many peopl have misunderstood. How about beefing up the man pages: for qmail-send: for its description of locals to explicitly say that virtual domains should *not* be placed in locals? for qmail-smtpd: for its description of rcpthosts to say that it should contain all the hosts in locals and virtualdomains plus those hosts you act as MX for. Actually, in stead of the latter suggestion, I'd prefer that there be another control file: mxhosts, and drop rcpthosts, which is just confusing everyone. Then we have simple explanations for what goes where. > The fact that everything can be found and that some questions are > stupid (the particular question I asked which prompted this thread > happens to be one of them; if I'd re-read the FAQ rather than the > list archives I'd have caught it myself) doesn't mean that ppl, > particularly people new to the game like myself, are going to need > *and*benefit*from* advice and help from more experienced users like > yourselves. Again, I agree with you that newcomers will need some help, and it's the job of more experienced people to help them. (Imagine how much better the real world would work if we used this thinking there, but I digress :-). We just wish that more people would read the documentation, especially the FAQ. > Do, please, be tolerant and patient with us; we do learn, it's Yeah, I'm getting snippy in my old age [smarten up Tom ] Sorry about that. > just a little hard for us if we are rebutted and end up trying > to learn in a vaccuum. Fortunately for *my* operations, that > hasn't happned to me.. I pray it doesn't happen to anyone else here. > > ~cHris -- "Life is much too important to be taken seriously." Thomas Erskine<[EMAIL PROTECTED]>(613) 998-2836
Re: Qmail Documentation (was addresses containing . )
>> I've searched the archives and i couldn't locate >> anything dealing with this. > >FAQ 4.6, also man dot-qmail: >-- cut here -- > WARNING: For security, qmail-local replaces any dots in ext > with colons before checking .qmail-ext. For convenience, > qmail-local converts any uppercase letters in ext to lower- > case. >-- cut here -- You're entirely right; sorry! I completely forgot to check the FAQ, having searched the list archives etc. > >I've heard many people complain about the lack of documentation that comes >with qmail; I'd like to put in a contrary opinion. I've never seen so >completely documented a system. Everything is there. The only gotcha is >that, apart from the FAQ, nothing is repeated. The moral of the story is: >read through *all* the qmail docs quickly once, or at least read the FAQ. > > You are right again. After ppl have pointed me to the appropriate place (not all of which are easy to find if you're a relative novice in sysadmin terms) everything *is* in the docs. Understanding it once it's there is another matter. New sysadmin's have to learn somewhere. If they haven't the advantage of a degree, they have to learn from the friendly and helpful people who make up the internet community. Let's face it guys, it all works because you guys help out the new guys, who become experienced and help out more new guys. That's why we're a *community* right? I've asked several stupid questions and some relevant questions since I've been here, and i've recieved a great deal of very valuable help and instruction from this list, noteably Mate Wierdl and Mr Sam. I'm new to sysadmining. However, I've been able to pass on what I@ve learnt, both in the Apache sphere and the qmail sphere, to other ppl even newer, so that they don't bother you experienced guys, but they do get their systems running. Qmail documentation is impressive in it's comprehensiveness but it is a little less so in it's comprehension. It can be very difficult to understand what is being said, be it as it may that what is said is entirely accurate. One example of this is the sheer number of ppl (I was one and i@ve seen the thread recur several times just in the month I've been here) who read the setup info as instructing them to place virtual domains in rcpthosts, virtualdomains *and*locals*; the documentation isn't wrong, but it's quite easy to misunderstand. The fact that everything can be found and that some questions are stupid (the particular question I asked which prompted this thread happens to be one of them; if I'd re-read the FAQ rather than the list archives I'd have caught it myself) doesn't mean that ppl, particularly people new to the game like myself, are going to need *and*benefit*from* advice and help from more experienced users like yourselves. Do, please, be tolerant and patient with us; we do learn, it's just a little hard for us if we are rebutted and end up trying to learn in a vaccuum. Fortunately for *my* operations, that hasn't happned to me.. I pray it doesn't happen to anyone else here. ~cHris
