Memory error on OpenBSD-current
Is anyone else getting memory errors on starting /var/qmail/rc (qmail-start) when compiled with egcs in OpenBSD-current? If I compile with -O2 I get the memory error; with -O1 it seems to work OK. Evan
Re: tcpserver control on domain name
> If someone controlled the reverse mapping for a range of IP addresses and knew > your domain name, he could make one of his addresses reverse map to a name in > your domain and gain access you don't want him to have. You can compare the forwards and reverse nameservice to make sure that they are both the same IP/hostname. Ie: the name returned from the reverse nameservice lookup must have 1 A record that maps to the incoming IP address (this is equivalent to tcpserver's paranoid mode). Evan
Re: Qmail is not a replacement for Sendmail
> I don't see what this has to do with anything. Sendmail didn't come > with a pop3 program. You need checkpasswd only if you're going to use > qmail-pop3d. It's true that if you're going to continue to use > qpopper, as I have, you need to hack it a little to get ./Mailbox and > XTND XMIT working. Note that there is no requirement for qmail to deliver to ~/Mailbox. You can continue to deliver to /var/mail if you like; see /var/qmail/boot/binm* or /var/qmail/boot/proc*. Interesting how only 2/10 of the sample boot scripts deliver to ~/Mailbox and yet Pike totally missed it! Of course, given his other complaints, I suppose it is hardly surprising. Evan
Re: RBL, DUL, Shubs, woohoo
Hi Doug, > What is the *best* means to use the RBL, DUL, Shubs, and others, with > qmail-smtpd and be able to allow our dialups to relay? tcpserver/tcprules will take care of the selective relaying, and rblsmtpd (available from ftp://koobera.math.uic.edu/pub/software/) will handle RBL for you Evan
Re: POP security question
> i thought about this one this weekend, if /bin/false is in /etc/shells > and you have ftp enabled, then a user could ftp in a .qmail file that > contains a expect script that runs chsh, and boom, they have a shell. how > to avoid this, options: /bin/false should never be in /etc/shells, period. If one wanted to be paranoid about it, one could specify different passwords for login vs. POP access by using a custom checkpassword with qmail-pop3d. One could authenticate against a database, or perhaps against a Kerberos server with the principal user.pop@domain (which would have a different password than the principal user@domain). One could also use the Cyrus IMAP/POP server which has the additional advantage that one doesn't need users in /etc/passwd to begin with (as long as one authenticates against Kerberos, or one writes a custom pwcheck daemon to authenticate against something other than /etc/passwd). Cyrus can also support Kerberised POP if the MUA supports it (ie: Eudora) which means encrypted POP sessions. Finally, assuming all customers use MUAs that support SSL (ie: Communicator and Outlook Express) one could wrap the POP server with stunnel and do encrypted POP sessions. I described how to get Cyrus' deliver to cooperate with qmail and how to wrap qmail-pop3d with stunnel a few months ago; one should be able to find those messages quite easily in the list archives. Evan
Re: qmail-inject
Well, I might as well add my voice to the chorus... >I wish to send the content of a text file to users on my system without >attaching it. What about a simple "mail user < file"? Evan
Re: Why Red Hat is not distributing qmail
>It hasn't improved over itself much since 1.00, so the reasons >probably haven't changed since their last evaluation, which was >negative. qmail itself hasn't had terribly major changes, but a lot of things have been added along side qmail which make it much more attractive, such as dot-forward, fastforward and rblsmtpd, as well as the ability to deliver to /var/mail via the local mailer (OK, it could always do that, but Dan now ships samples that use mail.local and procmail). In particular dot-forward, fastforward and /var/mail delivery are pretty major improvements if you're very attached to sendmail. Evan
Re: Procmail type rules?
>What I am trying to do is filter incoming mail... for example, for mail >coming in from the qmail mailing list, move the mail to the 'Qmail Mailing >List' IMAP folder in my directory. Also the same type of rule for the RedHat >mailing list, or for mail from a paticular person. Assuming you're using uw-imapd, the easiest way to do it is to subscribe to the list as (say) [EMAIL PROTECTED] and then create a file called: .qmail-qmail containing something like: ./mail/qmail This will write mail to [EMAIL PROTECTED] to an mbox file ./mail/qmail. I use this for the 20 or so mailing lists I'm on, and it works very nicely. There are other ways you can tackle this problem. In fact, I'm almost sure that someone just posted something about this, so you should check the list archives. Definitely check out dot-qmail(5), qmail-command(8) and condredirect(1). If you have any further questions you can mail me. Evan
Re: Procmail type rules?
>Is there a way to get the qmail-smtpd to use some form of delivery rules, >similar to procmail 'recipies'? I am using IMAP and would like to filter the >mail on the server when it comes in. I think you mean "Is there a way to get qmail-local to use some form of delivery rules," because you want the rules to happen on local delivery. The answer is pretty simple: it depends on what you want to do :-) If you really want, you can use procmail as your local delivery agent (see /var/qmail/boot/proc), but unless you want to do some heavy processing I think it would be a lot easier for you to use qmail's own .qmail files. Perhaps you can tell us exactly what you want, and we can try to help? Evan
Re: The qmail security guarantee
>Agreed. That kind of message is issued when the file is there, but >isn't readable. I probably shouldn't have used my favorite example in >that example. :-) Ah! My apologies. Yes, that would be nice. Evan
Re: The qmail security guarantee
>If it can't read a control file, it should say so, to stderr. >(e.g. "unable to read rcpthosts") Just a note that usually it is not an error for a control file to be missing. The control files mostly only override default settings. For rcpthosts in particular, my complaint would be that the default behaviour is IMHO wrong; if there is no rcpthosts, qmail-smtpd should refuse to relay anything as opposed to relaying everything. If you want to relay everything, you should have to create a file with a single "#" in it. But that is a side issue :-) I think you've got the right idea. The main one for me is that if qmail-smtpd sends any sort of error to a client, an error (hopefully slightly more verbose) should also be written to stderr. That should be pretty trivial to do since I believe all the error output is done in only a few functions. Evan
Re: verifying system binaries, a la R*dh*t
>That would be a waste of time. Dan doesn't trust Redhat; Redhat >doesn't trust Dan. Note that Redhat is not unique in this regard. Nor is Dan, I might add. I would rather gnaw off my arm than use something from Redhat. Personally I think that this has gone way too far. I agree with Dan that using getpwnam() is not acceptable, I disagree that editing binaries is a sane thing to do. I don't see why people can't get off their asses and type make setup on their own, but if they are so lazy I also don't see why the UIDs can't be put in to control files. I don't see how putting information in a control file is any less secure than putting it in a binary, and while it adds more code it would solve this stupid argument, which in itself is a worthy goal! Evan
