Re: a bug again?
On Tue, 7 Sep 1999, Marcin Jaskowiak wrote: I have two problems with qmail... first it seems that it doesn't use aliases in user's home directories (e.g. /home/john/alias/.qmail-john:doe). that's not in the user's homedir, that's a subdir "alias" that you invented. if you create ~john/.qmail-john:doe you will be able to de\irect messages to [EMAIL PROTECTED] with the file. the ~/alias/ directory is not an option, I donno why you tried it. The second is that qmail's pop3d server doesn't use aliases (in /var/qmail/alias/.qmail-*) when downloading mails... : why would it use an alias as a user? how would it authenticate it anyway? RTFM... this is basic Email stuff, not even Qmail specific. -- Ira Abramov | Internet Zahav | Linux Guru and T-Shirt collector Ixnay on the IcrosoftMay | please write to me only in English! [EMAIL PROTECTED] | it's hard to read Hebrew left to right
Re: fastforward: wildcards
On Mon, 6 Sep 1999, Kush wrote: I have a mail gateway and it forwards email to specific mail hosts in my network. I have a few mailing lists on these mail hosts, but the mail gateway (with fastforward) is unable to forward any email destined to the ezmlm list email addresses. I have `noc:@shell.blah.com` in my aliases file why do you use fastforward to forward the Emails then? if the servers inside the firewall are of the format YYY.blah.com and the mail is infact destined for [EMAIL PROTECTED] then use smtproutes. if it is a single domain that you split to departmental mail servers, I sugest using a fastforward file for the flat aliases, and a .qmail-aliasname-default for aliases that may have extensions. This doesn't happen because noc-subscribe@ isnt in the alias file. Is there anyway I can specify a wildcard in the alias files? perhaps: noc::@shell.blah.com? (I heard ":" could be a wildcard in qmail?) you heard wrong. : is used in .qmail filenames to replace dots (some security reason, forgot right now) also, I don't believe "@hostname" as the right parameter is a legal format. what you want: cd ~alias echo "| forward $[EMAIL PROTECTED]" .qmail-noc ln -s .qmail-noc .qmail-noc-default -- Ira Abramov | Internet Zahav | Linux Guru and T-Shirt collector Ixnay on the IcrosoftMay | please write to me only in English! [EMAIL PROTECTED] | it's hard to read Hebrew left to right
Re: daemontools binaries (was Re: binaries)
On Fri, 20 Aug 1999, Greg Hudson wrote: the daemontools binaries are included, they are, like all DJB software other than Qmail itself, under PD (not GPL). Public domain would mean you can do anything you want with it. You can't; in particular, you are not allowed to distribute derivative works other than precompiled var-qmail packages without Dan's permission. where is that written? As it turns out, there is a license among Dan's web pages. See: ftp://koobera.math.uic.edu/www/qmail/dist.html it refers ONLY to Qmail itself. nothing about daemontools, tcpserver, cyclog, libtai, EZmlm, cdb, and other such packages that are seperate. the page specifically says that if you wish to distribute a precompiled qmail, it must include the precompiled fot-forward and fastforward too, but nothing about vice versa (I can't understand why, except for one system I installed, I never used DF and FF anywhere). back to squere one: Don't ask me how I know that, maybe an old discussion here, but I do know that there are no LICENSE readme files in the packages or on DJB's site. I remember Dan had long and persuasive discussiona about how he doesn't want Qmail to go the sendmail way (a gazzilion contradicting versions with security holes introduced by nameless "contributors"), but the add-on packages are not part of that. at least not explicitly... If you download some source code and there is no license, you can't assume that the source is in the public domain or that you have permission to do anything covered by the exclusive rights given under copyright law. again: I didn't just assume, I said I vaguely remember it from an old discussion on the list. that's why there is a very serious need for a LICENSE file in each of those tars that Dan distributes! oh wait... there's one line in the readme... "You may distribute unmodified copies of the fastforward package." well, better than nothing at all I'll go untar the entire directory of my mirror of Koobera now, and write a summery of the licenses once and for all, so Russ has something to put up on qmail.org so we can stop this silly thread. Ofcourse I would have prefered DJB to do it because it's afterall his software and his IP to take care of, but it seems like he never donates his opinion tho these threads (and they pop up every 6 months). Good Day...
Re: daemontools binaries (was Re: binaries)
On Fri, 20 Aug 1999, Russell Nelson wrote: Other products are in the public domain (e.g. cdb or checkpassword). And other products are simply copyrighted with NO permission to redistribute granted at all (e.g. mess822, or libtai). umm, isn't libtai part of the cyclog package as it is? and mess822 has been hanging around in a binary RPM on Mate W.'s site... either it's OK or Dan doesn't care enough... I would prefer to see a file called COPYRIGHT in each product. COPYRIGHT has nothing to do with distribution rights, the free software movement shows us that the connection is dissapearing, and so does DJB himself on his site. And no, it doesn't really matter what I say on www.qmail.org, because legal authority can only come from the author. All I could do is open myself up to legal liability. ok, that I can understand.
RE: I've been doing some relay testing.
On Thu, 19 Aug 1999, Ben Kosse wrote: Actually, ORBS hasn't listed us. That e-mail touched precicely 3 systems: the client, the one I'm building, and our internal Exchange box. It ended up in our *INTERNAL* e-mail server as an undeliverable message. qmail tried to send it to someone inside our network who didn't exist. What I'd like to do is just outright refuse the messages. I agree with the people replying here that accepting the message and then discarding it quietly is the right approach and the mail-abuse tester program is not written correctly, but as a hack to fix it for now, did you try the patch to add regexp to the badmailfrom system? it's somewhere on the qmail.org site. if it accepts something like ".*%.*@.*" you should be ok I suppose.
fastforward and aliasing to \self
I started seeing a problem with handling the aliases by fastforward. some of our users had in the old sendmail host a few aliases set up in a way that the entire company mail is CC:ed to an aditional user, sometimes two. consider the following example: user1: \user1, \mon1, \mon2 user2: \user2, \mon1, \mon2 user3: \user3, \mon1, \mon2 user4: \user4, \mon1, \mon2 mon1: \mon1, \mon2 mon2: \mon2, \mon1 now sendmail looks up the aliases file first, the messages get delivered locally and don't end up in an alias loop. with Qmail, even if I force ~alias match before local delivery I'll have a loop problem. I can't specify a file delivery since they are not owned by alias' UID ofcourse, and fastforward won't do a file delivery anyway. also, this is going to switch from a UID-per-mailbox setup to a single-UID delivery system. in either case users do not have a homedir to put .qmail files in it. the way I see it now I'll have to hand over the alias resolution to a local agent I'll write (the one that will lookup the database for authentication and delivery instructions) and give up on fastforward completely. am I being too drastic?
Viewing cyclog logs
I had this idea... in my free time (in a month? :-) I want to start working on a log reviewing tool for cyclog. right now it's very inconveniant to run less on a random logfile, since the filename changes once in a while, plus the time stamps are not human readable. an interface to read the right log automatically, in human time and the right time zone, plus coloring and possibly jumping fixed time gaps automatically, including across log files (one minute, one hour, etc). the way the cyclog directories are organized will let such a tool guess automatically what logs exist on the system to begin with and offer them to the user in a menu etc., etc. anyone already working on this? can we collaborate and split the work? anyone got more feature ideas or things he'd like to implement there? I have a feeling that with a good audit review tool and with Mate's excellent inetd-replacement system to tcpserver, we could push cycslog to take the command from syslogd for most system functions if not all, hopefully to make it a standard on one of the Linux distributions as a beginning.
Big mama ISP server
at 150K users, the loads on my server aren't impressive, I'm guessing Israeli users surf and chat more than write Emails, possibly because of the software limitations (very few Right-to-left clients available, fewer agree on the encoding of the characters) My bosses are quite happy with an outgoing Qmail server, so now I want to make all other functions work on Qmail (local delivery, virtual domains, pop, ETRN users moving to AUTORUN etc.) right now an ugly 8 meg password file with a 6 meg shadow sidekick are pushed around the servers with scp. I'm going to move delivery and RADIUS auth all to RDBMs... (anyone done this? It's really hard to find useful info about this online... should I patch them all to lookup CDB files, or lookup an SQL server maybe?) the main question I'd like to pose to people, because getting sun machines just for tests is too expensive an option here, has anyone compared the speed advantage or loss when moving between the following setups: 1. current: sendmail delivers to a local in-house agent written in C (15k tool) that tests for a vacation flag for a user, then delivers to a two level hashed spool directory (/var/spool/mail/u/s/username) mounted from a net appliance box after checking mail quota limits (not standard fs quota). a second machine servers pop with qpopper. 2. wanted: qmail uses qmail-users or an external lookup (of CDB or some SQL?) to deliver to a a single-UID hash of maildirs if within quota, while checking for a vacation flag and executing if necessary. POP is served from another machine using qmail-pop3d. no dialup users have a UID or an entry in the /etc/passwd (YEAH!!!) is qmail-pop3d up to such volumes? is the 2-order growth in number of directories and files on the fileserver a speed damper? should I let qmail deliver to the existing hash and keep Qualcomm's popper poppin'? all sugestions and experianced tips are welcome, on-list or off it. TIA! Ira. (Oh yeah, and Russel, if you have a ready-made solution you can offer for a fee, send me an offer!)
Re: receive
On Mon, 16 Aug 1999, Kevin Chang wrote: hello all. I met a question with maildir format. When I send a mail to a user. I can found a new letter in his $HOME/Maidir/new, but when i receiver letter from netscape under x-window, The netscape cann't find the new letter. if you use Maildir, Netscape can only see the mil through POP. a simple .qmail dile for that user or the qmail-local setting for the entire system will change it to mbox delivery, then you can use movemail. questin two: What should I setup the upstream smtp server in qmail control file? check the manpage about smtproutes if you must have all the mail going out through one server
Re: qmail-Linux-distribution
On Sat, 14 Aug 1999, Kevin Waterson wrote: Every Redhat server I set up I need to go throuth the process of ridding the system of sendmail and istalling qmail. I use the memphis rpm and wrote up a simple install script So I started piecing together my own redhat clone (yes, yet another) and would like to know what I need to do BeroLinux already did that, then Qmail disappeared when it was merged into Mandrake Linux. I sugest you switch to Mandrake as a platform (I love it. it's also recompiled for Pentium entirely) and ask them to add a legal Qmail binary distro into their install process, and make Sendmail an option and not a must. I'll join in to that request if you do...
Re: binaries
On Sat, 14 Aug 1999, Mate Wierdl wrote: I still do not know what option to rpm you are talking about that would allow patches to be applied on the fly. I doubt that is possible: some patches do not use the %patch macro. welp, I saw it once and I can't remember the syntax. the basic man page doesn't have it, and 3am is no time to dig rpm.org At this point, I will include 4 patches (rbl, verh, big-to-do, qmqpc), and not the UCE patches, because I have no idea how they work (I am not even sure I have procmail installed anymore; I have maildrop). But people can Lionel's UCE patch has absolutly nothing to do with procmail. I'm an ISP. people misconfig their clients all the time, and try to send with return addresses invented by chimps with no connection to reality. the patch makes sure mail is accepted only from return addresses with a domain part (aka @host) that actually exists somewhere as an MX or an A record. people simply send with a non-return address and never get replies or bounces. Sendmail has this feature btw, and I'm trying to convince people here that Qmail is better. it surprises me this patch exists since v1.01 but hasn.t been assimilated by DJB, it's quite an important one...
Re: binaries
On Wed, 11 Aug 1999, Mate Wierdl wrote: A simple pointer: people who look for the "memphis" rpm, should not look into the var-qmail dir. People who look for a binary distribution of qmail, should look into var-qmail. I loved that qmail SRPM, it always worked great for me. The only added bonus is that now one does not have to compile qmail. The old rpm does not meet the criteria for binary redistribution. so basically it's a drop-in replacement to the old qmail SRPM that was there, once you add qmail-run? (which makes more sense named qmail-init maybe?) As for patches: binary redistribution does not allow any patches used to build the package. that I understand. I meant that up to a month ago I would download the old SRPM, do rpm --rebuild and then install the resault I did not understand your comment about applying patches at srpm build time. Perhaps you want to elaborate. what I mean is that the new binary RPM you are distributing would be accompanied by the SRPM that created it. doing --rebuild will create the binary allowed for distribution, but doing --rebuild plus some options (forgot the syntax, man RPM) will incorporate patches (like RBL MAPS and Widdifield's UCE patches, quota check patch to qmail-send, or whatever) and rebuild, creating a binary RPM, possibly named differently. right now I am happy running the Qmail as installed from the SRPM through rebuild. Now I want to add a single patch, I need to download the qmail original tar, patch it manually, recompile, and copy just the one patched binary over the one from the RPM... I might have just installed from the TARs to begin with... (not that I don't know how to, I'm just lazy :-) patches I'd love to have as an option: Red Hat group-per-user allow-group-writable-homedir patch. The Widdifield/Lambertsen/Haisley UCE patch NSCP messenger pop progress indication pop3 authentication for relaying SMTP authentication Nagy Balazs' envelope sender check (make sure it's bouncable) Oversize DNS packets (AOL fix) limit the number of RCPT TO: Mark Delany's envelope sender regex check patch Sam does have his own rpm that uses the patch. Also, Bruce Guenter has an rpm that employs selected patches. I'll go check that one out... It is rather trivial to add patches to var-qmail-create. Those who cannot, should not. haven't checked it out yet. does that come instead of the SRPM now? One problem I see with my old rpm is that a few people installed it, and then they started reading the docs included with qmail, and thought they have to create initscripts and such. Having two rpms I believe makes it clearer what people will get (since apparently I cannot always count on them reading the READMEs I put up). well that's their lookout, ain't it? I used it just fine so far... people who install software w/0 reading the instructions or the man page are either very bold or crazy. people who skip even the README are simply daft. expecially when it's such a central piece of software like a mail server. (Just my opinion :-)
Re: 20,000 mailboxes...
On Tue, 10 Aug 1999, Magnus Bodin wrote: One of the biggest swedish ISP:s (algonet) are using qmail for their 5+ users. Solaris, Sun and NetWork Appliances hardware. Internet Zahav here in Israel is THE biggest ISP in the country currently... 150k users. we use Qmail for all outgoing mail since about a week ago (I pushed it, got no help from the bosses), having to prove it's good, I redirected all the users to relay through a Pentium II-350 with an IDE drive instead of the sendmail over an Enterprise Solaris box, and things turned out to work faster. now that the bigwigs saw the success, I'll move in to change the rest of the servers to Qmail too (main incoming, virtual domains, pop etc) High time I switch to a DB instead of a multi-megabyte passwd file. any ideas, ready-made delivery tools? same DB should also authenticate for Radius and pop. non-qmail specific replies will be happily accepted offlist too. TIA, Ira
Re: Squashing 20,000 rumors...
On Tue, 10 Aug 1999, Jeffrey Skelton wrote: What about Critical Path? Do they use qmail - or at least something derived from qmail. Egroups.com both in and out, AFAIK, and ezmlm for the list management (or derivative of)
Re: binaries
On Tue, 10 Aug 1999, Mate Wierdl wrote: var-qmail packages and binary rpms are in ftp://moni.msci.memphis.edu/pub/qmail/var-qmail Comments are welcome please don't take this the wrong way... but compared to the RPMs I like to use (one directory above it, same FTP site), what are the added bonuses? I couldn't find any reference to that in the two packages' readme files, though it reads as if you maintain both of those parallel (conflicting?) distribs. and while I'm at it... can it be a runtime option for the "rpm --rebuild" stage to include extra optional patches? i.e. the SRPM will include the files to patch qmail-smtpd for UCE, and use them during rebuild if requested in the commandline.
non-existant host - defered?!
I just noticed messages to non-existant hosts (due to typos or whatever) don't get bounced, but instead stay stuck in the queue for the full lifetime (1 week here). any REALLY good reaon for that?
Re: M$ Exchange - qmail
On Sun, 1 Aug 1999, Olivier M. wrote:
I have a friend which has an Microsoft Exchange Mail server ("main" server)
always connected to the internet, and there are a few (about 10)
other MS-Exchange servers which are connecting directely to the main
mailserver every hour using ISDN-dialin (ppp).
if the dial-in is done by the exchange server itself, i.e. not an ISDN
router, then ETRN is easy to config for the Exchange's dialer and on the
Qmail side I'd implement Autorun which I read is very effective as an ETRN
replacement (and it does indeed work with serialmail and maildir2smtp. all
documented). I'm working for a fairly large ISP, and the above is the way
I'll convert us to work soon.
Recipientmap dead?
In a new installation I'm doing for a client, I found the need for the /var/qmail/control/recipientmap I used to use back in the 1.01 days. now it seems not to respond, it's not even in the qmail-control manpage. was it really canceled? is there an equivalent, i.e. so I won't need to break up the old sendmail rules file into 11300 little .qmail files!!! btw: the egroups post function still attempts to post to djb-qmail@koobera which bounces. please fix it to post here (whoever is the liason) so I can subscribe for digests. TIA, Ira
Re: relaying redundancy
On Mon, 26 Jul 1999, torben fjerdingstad wrote: I wish smtproutes could take a prioritized list of destinations. Our workstations has jam.net.uni-c.dk defined as "smarthost", using smtproutes, which contains :jam.net.uni-c.dk If that host is down, my outgoing mail is deferred, and I am not notified. It would be nice if having :jam.net.uni-c.dk :nn.net.uni-c.dk in smtproutes would try jam first, then nn. What are my options? I cannot send mail out directly because of a firewall. a little simplistic, but I'd run a script on cron once, say, every 10 minutes that will ping a packet to Jam, and swap to a backup version of smtproutes and notify you if there's no echo, only to be swapped back and check again in the next execution. pinging when up will return exit code of 0, ping timed out will return 1 and host doesn't exist gives 2 (DNS dead?). I'm not aware of an internal qmail solution. taking it a step forward, you could use serialmail and check the load balances on those two relays before releasing outgoing mail once a minute, but that's just an overkill and delays mail :)
Re: Recipientmap dead?
On Mon, 26 Jul 1999, Martijn Koster wrote: On Mon, Jul 26, 1999 at 12:09:21PM +0300, Ira Abramov wrote: In a new installation I'm doing for a client, I found the need for the /var/qmail/control/recipientmap I used to use back in the 1.01 days. now it seems not to respond, it's not even in the qmail-control manpage. was it really canceled? is there an equivalent, i.e. so I won't need to break up the old sendmail rules file into 11300 little .qmail files!!! A grep through the source 1.03 directory turns up UPGRADE: WARNING for upgrades from 1.01: recipientmap is gone. The virtualdomains mechanism has been expanded to support virtual users. it doesn't really give the same functionality since it adds a prepend instead of translating... to illustrate: my current set of rules for sendmail looks like this: @bothers.com[EMAIL PROTECTED] @building.com [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @stooge.com [EMAIL PROTECTED] . . . so user or entire domain (full or as fallback) are forwarded to local users. I don't need prepends here. furthermore, it's rare but I may sometimes need to forward one of those users' Email out (and not to mail.inter.net.il) right now the only compact solution I see is to send this file to a filter that will chop up and 'sort -u' to forward them all to virtualdomains which in turn will send them all to virforward-user@localhost, then ~alias/.qmail-virforward-default will peel $LOCAL and change the '@' into '=', then forward it to a fastforward patched to look at a special aliases.cdb which I made from the original rules file by changing @ to = and changing the double tab to a colon. as for catch-all @domain.com domains, they even complicate things further. seems like I'll have to break it down to a gazillion .qmail files, which is something that will not be fun to manage. anyone knows a better, cleaner way? :-(
Re: Null
On Mon, 26 Jul 1999, Russell Nelson wrote: Tony Wade writes: Hi there, How does one dump mail to /dev/null , hand waves wildly in the air I know! I know! Pick me! Pick me! echo '#' .qmail I thought it would discard it as a null file hat way, so ever since I started using qmail (and it's been 3 years now I think, maybe more) I'd use: | cat /dev/null (it's also more descriptive of where the mail went :)
Re: Recipientmap dead?
On Mon, 26 Jul 1999, Russell Nelson wrote:
Ira Abramov writes:
to illustrate: my current set of rules for sendmail looks like this:
@bothers.com [EMAIL PROTECTED]
@building.com [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
So?
#!/usr/bin/perl
.
.
.
if ($left) {
writefile(".qmail-$right-$left", "$out");
} else {
writefile(".qmail-$right-default", "$out");
there you go, again it means a gazillion files (well 11394 at the current
count, this is an ISP) and that's both a waste of inodes, a mess in your
eyes, and doesn't solve removing of the .qmail files as aliases are
cancled. the current mechanism is the support person updatiing the file
through a web interface, the cron pushes the file (with the additions or
substractions) onto the mail server.
hey, I'll time that perl script, if it's under a few seconds to parse the
entire rules file I'll just chmod +t, delete all .qmail files and recreate
them, then chmod -t. it's a kludge, it's heavier than want it, but it
will work (still open to cleaner ideas, people)
Re: Industry name for various email services? (repost)
On Mon, 26 Jul 1999, Dave Kitabjian wrote: What are the industry-standard names for the following email services: I doubt it's a standard in some ISO or IEEE book, it's not even an RFC. let your marketing guy sit with a copywriter and find a name for these packages so they SELL :-) any_name@their_domain and a separate POP for each. (.qmail-any_name) ISP-based virtual mail domain any_name@their_domain but they get only a single pop account, "default", for retrieval of all the mail (.qmail-default). single-mailbox domain forwarding, AKA lame. 3) All mail to any_name@their_domain_2 is treated as any_name@their_domain_1 (by virtualdomains entry: their_domain_2:their_domain_1) full domain overlay? symetric domain forwarding? let your copywriter think it up for you :)
