Problem with qmail counting local deliveries
Our qmail+ldap installation seems to be losing track of the number of local deliveries going on. We have it set up to limit concurrent local deliveries to 50, and after running for a while, it will think that it already has 50 local deliveries running, and won't start any more up. In reality, though, it has between 0 and 20 running Here's an example: mail013# tail -1000 syslog | grep 'status:' | tail -10 Apr 10 14:09:32 mail013 qmail: 955390172.820586 status: local 50/50 remote 13/50 Apr 10 14:09:35 mail013 qmail: 955390175.792667 status: local 50/50 remote 12/50 Apr 10 14:09:35 mail013 qmail: 955390175.993011 status: local 50/50 remote 11/50 Apr 10 14:09:39 mail013 qmail: 955390179.265143 status: local 50/50 remote 10/50 Apr 10 14:09:40 mail013 qmail: 955390180.472890 status: local 50/50 remote 9/50 Apr 10 14:09:41 mail013 qmail: 955390181.445602 status: local 50/50 remote 8/50 Apr 10 14:09:48 mail013 qmail: 955390188.578305 status: local 50/50 remote 9/50 Apr 10 14:09:48 mail013 qmail: 955390188.705810 status: local 50/50 remote 8/50 Apr 10 14:09:53 mail013 qmail: 955390193.873759 status: local 50/50 remote 9/50 Apr 10 14:09:54 mail013 qmail: 955390194.544234 status: local 50/50 remote 10/50 mail013# ps -ef | grep qmail-local | grep -v grep |wc -l 0 mail013# ps -ef | grep qmail-lspawn |grep -v grep |wc -l 19 Additionally, many of the 19 qmail-lspawn processes are a week old or older, and seem to be hung (they don't have any child processes, and are in a poll() system call). This can be solved by shutting down qmail and starting it back up, but I don't want to have to do this every week for each of our 20 mail servers. Has anybody seen this problem before? We are running qmail-1.03 with the LDAP patches from 19991007. We've got a cluster of about 20 mail servers, each pushing around 65,000 messages/day. I'm seeing this problem after running for about 2 weeks. Thanks for any pointers, --Scott.
Re: Qmail IMAP AND Pop3 recomendations
"Peter Janett" [EMAIL PROTECTED] writes:
It's all working OK, but now I need to be able to access the accounts via
IMAP. I have been looking into Courier-IMAP, but if possible, I'd like the
IMAP server to use the same checkpasswd I'm using for POP3 access.
I solved this problem with a hack. I wrote a script to run before
checkpassword and clean up what imaplogin sends to it, then another
program to clean up what checkpassword does and set up the environment
how imapd expects it.
I start up tcpserver like this. The interesting lines are the
preimap.pl, checkpassword, and postimap.pl lines. I also use
POP-style bulletins, which is the qmail-popbull line; you may not need
it in your environment.
( nohup supervise /var/supervise/qmail/imap.143 \
tcpserver -R -c 100 -v \
-u 400 -g 400 \
0 143 \
${exec_prefix}/sbin/imaplogin \
/usr/tools/src/imaptest/preimap.pl \
/var/qmail/bin/checkpassword \
/usr/tools/src/imaptest/postimap.pl \
/var/qmail/bin/qmail-popbull /var/qmail/bulletins \
${exec_prefix}/bin/imapd Maildir )
preimap.pl and postimap.pl are as follows:
--preimap.pl-
#!/usr/local/bin/perl
use POSIX;
open(AUTHIN,"=3");
@lines=AUTHIN;
close(AUTHIN);
($fdR,$fdW) = POSIX::pipe()
or die "Couldn't create pipe: $!\n";
defined($pid=fork())
or die "Couldn't fork: $!\n";
if (!$pid)
{
# Child
POSIX::dup2(3,$fdR);
POSIX::close($fdW);
exec(@ARGV);
die "Couldn't exec: $!\n";
}
open(AUTHOUT,"=$fdW")
or die "Couldn't open fd #$fdW as AUTHOUT: $!\n";
# Ignore first two
shift(@lines); shift(@lines);
grep(s/\n/\0/,@lines);
print AUTHOUT @lines, "Y123456\0";
close(AUTHOUT);
#exit(0);
-
-postimap.pl-
#!/usr/local/bin/perl
delete $ENV{AUTHUSER};
$ENV{AUTHADDR}="test\@test";
$ENV{AUTHFULLNAME}="";
delete $ENV{AUTHEXPIRE};
$ENV{AUTHENTICATED}="yes";
exec(@ARGV)
or print "exec failed!: $!\n";
-
Re: Multi-RCPT vs. Single RCPT delivery - logic error?
Here's one interesting solution I heard about not too long ago: http://www.whalemail.com/ Another interesting solution would be to teach your MTA to automatically replace MIME attachments with a link to a Web page and a password, and decode and store the attachments on a Web server. Not appropriate for a lot of people, but interesting for a business that can get away with automagically munging people's email. -Scott. Chris Hardie [EMAIL PROTECTED] writes: On Fri, 28 Apr 2000, Andy Bradford wrote: I may be rehashing old topics, and I may sound a little bit old fashioned (even at age 26), but I don't believe email was ever meant to handle that large amount of traffic. Or, in other words SMTP != FTP I am still of the opinion that one should instruct users to use the right protocols for the right reasons. Hence, put the 10MB PowderPoint file in a public or private ftp directory and then include a URL to fetch it in the email. I agree with this sentiment, but it's becoming increasingly difficult to find good ways to enforce it. Case in point: we do web development for an organization that has a PR firm develop brochures and then send them to us for posting on their website. The files are often 7-10 MB in size, large enough to be cumbersome for e-mail, small enough to make overnighting a ZIP disk seem a little excessive. The organization hosts their site with us, and so we could obviously instruct them to upload the files through FTP, but the PR firm shouldn't necessarily be able to do this. It gets more complicated when you think that it's not always going to be the same person at the PR firm sending the files, and that there are many cases where other third parties need to send us materials related to the site. Clearly it's a complicated issue, but it seems that as broadband access to the net becomes more common, businesses are going to expect to be able to use one "interface" to do all their communications, be it plain text messages or large multi-megabyte file transfers. I cringe every time someone sends me a 7 MB mail message, but it's difficult to explain to them why this is a bad idea. I'd be interested to hear if anyone's found a good general solution to this in a production/business environment. Chris -- Chris Hardie - - mailto:[EMAIL PROTECTED] -- http://www.summersault.com/chris/ --
Adding local IP address to ipme
I have a farm of qmail servers sitting behind a load balancer. I'm having a problem with being a secondary MX for a domain, because the individual qmail servers in the farm don't realize that the IP address of the load balancer actually points to them. They keep trying to re-deliver to the load balancer's address, which connects them back to a different mail server within the farm, which does the same thing, until the message bounces because of too many hops. Is there a patch that will let me add addresses to the ipme structure that qmail uses to determine whether the MX record for a host is actually itself? Reading back over that, it's a little confusing. Here's an example. I have 25 qmail servers, 10.0.0.1 through 10.0.0.25. The load balancer, which will semi-randomly select one of the actual servers to pass the connection on to, has an address of 1.2.3.4. Domains for which we are a secondary MX have a less preferred MX record that points to 1.2.3.4. When a message comes in to be queued, it comes in to 1.2.3.4, which is redirected to (for example) 10.0.0.5. The domain is in its rcpthosts, but not its locals, so 10.0.0.5 tries to forward it on to the next best-preference MX. It tries to connect to the primary MX, fails, and then tries to connect to the secondary, 1.2.3.4. It doesn't realize that it is already handling mail for 1.2.3.4, so it opens up another connection to 1.2.3.4, which redirects it to (for example) 10.0.0.16. This process repeats until the message bounces. I'm looking at patching ipme.c and giving it a config file, but it seems to me that somebody must have already done this. Can anybody point me in the right direction? I'm using qmail-1.0.3+ldap. Thanks, --ScottG.
Re: PTR question (Probably RFC related)
If that server is going to be connecting to other mail servers and sending them mail, common practice requires a PTR record, and an A or CNAME record for that name that refers to the same IP address. Many mail servers will refuse to accept your mail otherwise. ScottG. Cyril Bitterich [EMAIL PROTECTED] writes: Hi, could you tell me if there is any need to have a valid reverse lookup for your mailserver. Either based on a RFC or common practice. Thanks, Cyril
Re: how do I resync two machines after MX confusion ?
Interestingly, I'm in a similar situation, only my messages are still in the queue. Normally, I would just put ":new.server.name" in my smtproutes, and have it dump its queue, but it's already put all of the local messages in the "local" section of the queue, which doesn't look at smtproutes. Is there a clever way to make this work? Can I just move them into the remote directory, then run the queue? Or tar up the queue directory, move it onto the new machine in a temp directory, run qmail-qfix, and then rename the files over into their new locations? Any suggestions would be much appreciated. -ScottG. [EMAIL PROTECTED] writes: It depends on where the mail is on this clone server. Is it in the mail queue or has it been locally delivered to users there? The former is much easier to deal with than the latter. Regards. On Thu, Jun 29, 2000 at 01:56:31AM +0200, Andre Morin wrote: First of all, this is a really stupid situation we should never have run into in the first place ; however : Due to some not so interesting reasons, for a couple of days our DNS has pointed to another machine with our cloned qmail-configuration on another IP in another town. I have complete root access to that machine. Now everything is back as before, but while this machine was MX for quite a bunch of virtual domains we host, the mail arrived there. What I need to do now, and I am discovering qmail, is a way to get all the mail from the distant server to be sent to our machine with a minimum of fuss and if possible transparent to the users (just being late, extra headers don't hurt as long as they are of the kind lusers see by default in their mailer). I have started plunging into the really dense documentation of qmail and read some interesting contributions in the archive of this list, compiled maildircmd and taken a look at its doc as well. While I feel that there must be a simple solution short of writing a brute-force-and-ignorance-script with a complete list of maildirs to be processed, I lack the experience to figure this out on my own. Thanks in advance to the list for some pointers to intelligent solutions for my stupid problem. -- Best Regards André Morin
Re: how do I resync two machines after MX confusion ?
Wouldn't I have to delete most of the passwd file and the /var/qmail/alias directory in order for a .qmail-default to get looked at? And do you know of any reason why these queue-mucking techniques: Can I just move them into the remote directory, then run the queue? Or tar up the queue directory, move it onto the new machine in a temp directory, run qmail-qfix, and then rename the files over into their new locations? would or wouldn't work? Thanks much, -ScottG. [EMAIL PROTECTED] writes: On Thu, Jun 29, 2000 at 11:23:36AM -0400, Scott Gifford wrote: Interestingly, I'm in a similar situation, only my messages are still in the queue. Normally, I would just put ":new.server.name" in my smtproutes, and have it dump its queue, but it's already put all of the local messages in the "local" section of the queue, which doesn't look at smtproutes. Is there a clever way to make this work? Can I just move them into the remote directory, then run the queue? Or tar up the queue directory, move it onto the new machine in a temp directory, run qmail-qfix, and then rename the files over into their new locations? Assuming the local deliveries are currently failing temporarily (perhaps due to a home dir not existing or somesuch), then probably the easiest thing is to create a default alias that catches all those mails and delivers them to a Maildir, then use maildirtosmtp out of the serialmail package. I don't know of an easy way to change a local delivery to a remote delivery by twiddling the queue. That decision is made as part of the queue entry creation, not part of the rescan of qmail-send. Regards. Any suggestions would be much appreciated. -ScottG. [EMAIL PROTECTED] writes: It depends on where the mail is on this clone server. Is it in the mail queue or has it been locally delivered to users there? The former is much easier to deal with than the latter. Regards. On Thu, Jun 29, 2000 at 01:56:31AM +0200, Andre Morin wrote: First of all, this is a really stupid situation we should never have run into in the first place ; however : Due to some not so interesting reasons, for a couple of days our DNS has pointed to another machine with our cloned qmail-configuration on another IP in another town. I have complete root access to that machine. Now everything is back as before, but while this machine was MX for quite a bunch of virtual domains we host, the mail arrived there. What I need to do now, and I am discovering qmail, is a way to get all the mail from the distant server to be sent to our machine with a minimum of fuss and if possible transparent to the users (just being late, extra headers don't hurt as long as they are of the kind lusers see by default in their mailer). I have started plunging into the really dense documentation of qmail and read some interesting contributions in the archive of this list, compiled maildircmd and taken a look at its doc as well. While I feel that there must be a simple solution short of writing a brute-force-and-ignorance-script with a complete list of maildirs to be processed, I lack the experience to figure this out on my own. Thanks in advance to the list for some pointers to intelligent solutions for my stupid problem. -- Best Regards André Morin
Re: Re[2]: The most secure POP server
Gabriel Ambuehl [EMAIL PROTECTED] writes: It works exactly the same as SSL and IMAP. You can encapsulate any TCP connection in an SSL tunnel. This includes IMAP, POP3, telnet, or even ssh or another SSL session, although the last two are pretty pointless. May anyone explain me what sense a SSL tunnel for POP3 does have (I've been wondering about that for long...)? [ ... ] To protect the POP password. -ScottG.
Re: Re[4]: The most secure POP server
Gabriel Ambuehl [EMAIL PROTECTED] writes: Hello Scott, Monday, July 03, 2000, 5:54:00 PM, you wrote: May anyone explain me what sense a SSL tunnel for POP3 does have (I've been wondering about that for long...)? [ ... ] To protect the POP password. But wouldn't it be way easier to just use APOP? Or does that one have its own security implications? The only particularly nasty implication of using APOP are that it requires that the server have the password stored in plaintext. The security aspect of that is that if somebody can steal the password file from a system, they have direct access to all accounts, compared to storing one-way hashes of passwords, which would make them run crack first and they still wouldn't get well-chosen passwords. The maintainability aspect is that standard UNIX passwords aren't stored in plaintext, so you can't use APOP to authenticate against a standard UNIX passwd file. POP over SSL solves both of these, by making no changes to the POP protocol, but just encrypting the whole session. I haven't looked at APOP in awhile, and if what I've said is wrong, I know that nobody on the list will hesititate to correct me. :) -ScottG.
Re: Re[4]: The most secure POP server
"clemensF" [EMAIL PROTECTED] writes: Scott Gifford: [ ... ] POP over SSL solves both of these, by making no changes to the POP protocol, but just encrypting the whole session. i've checked around here in germany: isp's offer pop3 access plus web access. with freenet (mobile) i just had to change my fetchmailrc to use apop, germanynet (calisto) barked, thay would not change their entire setup for just one customer, when i asked them for apop. i dared to ask only because their greeting looks like an apop prompt, and it even changes on every dialup... so much for technical competence. They probably don't store plaintext passwords, which would make it impossible to support your request. Not a matter of technical competence as much as system design. -ScottG.
Re: Re[4]: The most secure POP server
"clemensF" [EMAIL PROTECTED] writes: Scott Gifford: to use apop, germanynet (calisto) barked, thay would not change their entire setup for just one customer, when i asked them for apop. i dared to ask only because their greeting looks like an apop prompt, and it even changes on every dialup... so much for technical competence. They probably don't store plaintext passwords, which would make it impossible to support your request. Not a matter of technical competence as much as system design. that i don't understand. i can get my password anytime from any provider, just askin', maybe answering "secret questions". what makes you think they don't store plaintext-passwords? Just a guess; if the provider that won't provide APOP can provide you with plaintext passwords, then I don't know what their excuse is. :) -ScottG.
Re: security issue
It is not an issue. I don't remember if qmail will silently drop these messages or return a bounce for them, but it most certainly will not run any programs as root because of them. ScottG. John Steniger [EMAIL PROTECTED] writes: Hello, Running a network test against my recent qmail installation, I get reports on the mailto programs hole, which allows users to telnet to port 25 and issue: MAIL FROM: root@this_host RCPT: any program This allows users to potentially execute any command with root authority. The warning came with the caveat that this may not be an issue, as some MTA's simply drop these messages silently. Does anyone know how qmail handles this? Is this an issue with qmail, or is qmail one of the exceptions? Thanks.
Re: aol mail bouncing
Is there anything about AOL or any of AOL's IP addresses in your tcpserver setup (especially the database that tcpserver uses to block connections and set environment variables)? And do you see anything in your logs about these messages? -ScottG. "Matt Taft" [EMAIL PROTECTED] writes: Helo, I have just recently switched from sendmail to qmail for our ISP and got everything working using qm 1.03 memphis, tcprules, vpopmail, big-dns.patch, bind.patch. Sending, Recieving, POPing Mail all seemed to be working ok. Then I found all mail from AOL and certain other asp's was bouncing most mail recieves fine and all mail sends ok but mail from aol is recieved then bounced usually for no such mail account at my mail server however obviously this mail account does exist and recieves mail fine from all other locations. And the second twist is if I send a mail to an aol member and they utilize reply it is recieved at my mail server with no problem but if they type a new mail and utilize the exact same address it bounces. lol Matt Taft Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
Re: Where is ref. site of ETRN
PipE [EMAIL PROTECTED] writes: Dear All i wanna find more detail about ETRN what it mean how to work who can give me information or Document ? See RFC 1985: http://www.geektools.com/rfc/rfc1985.txt Hope this helps, ScottG.
Re: Double Forwarding
"Neil D. Roberts" [EMAIL PROTECTED] writes: Right now, mail sent to "[EMAIL PROTECTED]" does not go to the mail queue but goes to "[EMAIL PROTECTED]". How could I duplicate this so that it also goes to the mail queue ? I can´t place "[EMAIL PROTECTED]" in the ".qmail-user" file because it would loop. Any ideas as to what I can do ? As the second line in the .qmail-user file, try ./Maildir/ I think that will give you the behavior you want. -ScottG.
Re: How to requeue messages?
Albert Hopkins [EMAIL PROTECTED] writes: The new location is on another (non-qmail) server. Basically this user is wanting her currently delivered email to be send to the other email address (the one I put in her .qmail). I'm not sure if it's called requeuing or what but basically I want qmail to re-process the delivered mail according to the new .qmail file. maildirsmtp in the serialmail package might do what you want it to. See: http://cr.yp.to/serialmail.html -ScottG.
Re: patch to require helo before mail from
"Darrell Wright" [EMAIL PROTECTED] writes: I have written a patch to force clients to say helo first. Out of curiosity and not unpleasantness, why would one want such a patch? I've seen that sendmail has options to do the same thing, and have never understood exactly what it accomplishes. Thanks for any insight, --ScottG.
Re: emacs rmail+maildir
Keith Warno [EMAIL PROTECTED] writes: One one my lusers insists on using emacs rmail for reading mail. I'm not an emacs user so I don't know a lick about it, but I do know it doesn't talk to the Maildir format. It wants mbox format. Three comments: 1. GNUS, another EMACS mail/news reader, has no problem with Maildir. They might want to just use that. 2. Searching around briefly, I see a message that rmail users can use 'maildir2mbox' to convert their Maildir into standard mbox format. rmail can be configured to run a program to check new mail, and if you set up a script that runs maildir2mbox in an appropriate way, then have it run that when it's checking mail, it should just work. See: http://lists.omnipotent.net/qmail/199707/msg00111.html 3. You might want to search around and see if there is a newer version of rmail than the one they're using, which perhaps supports Maildir natively. Hope this is helpful, --ScottG.
Re: emacs rmail+maildir
Keith Warno [EMAIL PROTECTED] writes: Thanks for the help from those who have assisted. I've not used maildir2mbox in the past; I know it "does not protect against simultanous access by another maildir2mbox" (from maildir(5)) but is it safe to use over NFS? NFS is only less safe than local storage for locking, and even then only if your NFS implementation really sucks. So I wouldn't worry about it. To prevent both, though, you could write a simple wrapper script for maildir2mbox that did some kind of file-based, NFS-aware locking (or just use fcntl/flock, if your NFS is non-horrible). ScottG.
Re: control files on an NFS share?
Ben Beuchler [EMAIL PROTECTED] writes: Our one qmail/vpopmail server is about to become a node in a load balanced pool of mail servers. I plan to mount the queue via NFS (I am now, in fact) but am wondering about the control files. It seems that at least SOME of them should be safe to share over NFS. Any thoughts or recommendations? We have stored all configuration files (save 'me') on NFS for about 8 months now, with no problem. It does put quite a bit of additional strain on the NFS server, though; I'm looking at moving control to a RAMdisk, and just copying from the NFS server when qmail is restarted. We also store spool on NFS with no problems. We've stored queue on NFS in the past, and while we didn't see any lost mail, we did see huge performance problems, and had to move it to local storage. --ScottG.
Re: Some assistance?
"Jonathan J. Smith" [EMAIL PROTECTED] writes: I need to be able to send/relay all of the messages in a maildir (the default/catchall for that domain) back out to that domain, there was a 'cessation' of the domains real mail server, and it is operational again so the desire is to hand these messages back to that machine. This should point you in the right direction: http://cr.yp.to/serialmail.html -ScottG.
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. For example, if there are 10 different patches against qmail-smtpd, then there are 1,024 different packages that would have to be available to support the various combinations of patches. Worse, as more patches come out, this number increases exponentially. If I come out with yet another patch to qmail-smtpd, all of a sudden we're up to 2,048 packages. And who is responsible for generating the additional 1,024 packages, me or the first 10 developers? If the 10 different packages are all maintained by different people, let's say A-J, obviously A is responsible for making qmail-smtpd-A available, and B for qmail-smtpd-B. But is A or B responsible for qmail-smtpd-AB? And what if A thinks B is an idiot, and B thinks A is? Either a third party will have to create qmail-smtpd-AB, or else an end user who wants qmail-smtpd-AB will be responsible for putting it together, probably by downloading all of the packages, producing patches with diff, and applying to the original qmail sources. Further, the base qmail source is well-tested. It's easy to see exactly how much is changed by a patch, and if there are problems, to investigate only those areas which a patch affects. With a full package, to isolate problems to just the patch's changes will require you to download the original and the modified version, and use diff to compare the changes, essentially giving you a patch file. Still further, patches which touch multiple parts of qmail (such as the ETRN patch) would require basically a redistribution of all of qmail, which would make the exponential patch growth problem even worse. And still further yet, it's not even clear that qmail's distribution terms allow this, without getting explicity permission from the author for each new package: DJB If you want to distribute modified versions of qmail DJB (including ports, no matter how minor the changes are) you'll DJB have to get my approval. This does not mean approval of your DJB distribution method, your intentions, your e-mail address, DJB your haircut, or any other irrelevant information. It means a DJB detailed review of the exact package that you want to DJB distribute. (from http://cr.yp.to/qmail/dist.html) If explicit permission is required for each new package, it would make the time required to produce a patch higher, which would discourage people from producing patches or packages. I think that the way it works now is the best it can currently be. A better option is to take all of the common qmail patches, and produce a new qmail package with them applied or available as options. This would mean that more obscure patches could be against this package, reducing the chance of conflicts, and that the package with modifications would be well-tested. This, I believe, is similar to the situation with ezmlm-idx. --ScottG.
Re: Possible problem with qmail-qmtpc patch
Russell Nelson [EMAIL PROTECTED] writes: Johan Almqvist writes: Hi! I think there may be a problem with the patches to qmail-remote that make it speak QMTP based on MXPS. If the QMTP connection fails (because the remote host doesn't have a qmtpd running That's a misconfiguration. I'd rather that the email bounced than it got delivered via SMTP silently. It could be that someone unaware of the MXPS standard (which admittedly includes 99.99% of the world's population) could have set their MX priority to 12801. If so, it's best to ask them to change their MX priority. I think that's probably the opposite of what the user who sent the message wants. Far better to deliver the message, and include an option for mail administrators who are concerned about these things to log the "downshift" to SMTP. If they're concerned, they can look through their logs (perhaps from a script run from cron), and fix their own system, or contact the administrator of the misconfigured system. The sender, who will receive the bounce message, can do nothing to correct misconfiguration on their side or the recipient's side. It does no good to send a message to *them* about the misconfiguration, which probably will never reach any of the involved mail administrators. And, since MXPS is not an accepted Internet standard, the (unlikely, but possible) situation where somebody has chosen an MX priority which isn't MXPS-compatible should be handled gracefully. The idea of multiple vendors introducing incompatible extensions to the mail delivery process, and having messages bounce if their conditions are not met, makes me very uncomfortable. A mail sysadmin should be able to read their own system's documentation, and all relevant mail RFCs, and have a complete working system. They should not be required to read the documentation of every existing mail system to find out about incompatible extensions. If MXPS was a standards-track RFC, the situation would be different, but I still see no reason to bounce messages that can be delivered. It's much more likely that someone intends that the email be delivered via qmtpd but it is failing to run for some reason. If we fall back to smtp, they'll never know that it's failing unless they're watching their qmail logs carefully. Then provide a script to analyze these logs and email the concerned parties. -ScottG.
Re: A firestorm of protest?
Russell Nelson [EMAIL PROTECTED] writes: Scott Gifford writes: Russell Nelson [EMAIL PROTECTED] writes: Try applying two patches to the same program. While this may require some manual reconciliation between conflicting packages, it's far better than needing a seperate full distribution of components of qmail for every possible combination of patches. Don't be ridiculous. Instead of producing a different package, you would send the patch to the author of the enhanced qmail-smtpd. If he refused to accept it, then you might consider creating your own package. It's not that ridiculous. Say you have patches to qmail-smtpd to support SSL/TLS via 'STARTTLS', to support 'ETRN', and to support the SMTP AUTH extensions (these patches probably exist, and I don't know how they're organized, so let's just use them as examples). Users could want any combination of these features, exclusive of any others. Either you combine them all into one package that supports all 3, or you need 8 different packages to support any possible combination. If you combine all common patches into one "uber-patch", then you're essentially producing a new version of qmail which is much larger and has many more features than Dan's. Some people will see this as progress, others as bloat. Personally, I think this is probably a good idea, as long as things are well-tested. Otherwise, you end up with exactly the exponential package growth I described in my previous message. -ScottG.
Handling an MX record of 0.0.0.0 or 127.0.0.1
We received an influx of mail today addressed to (probably bogus) users at the domain 'groupprojects.net'. This domain has the following MX record: groupprojects.net preference = 0, mail exchanger = 0.0.0.0 When we received the message, qmail connected to 0.0.0.0 to deliver the mail. 0.0.0.0 connects to 127.0.0.1, so qmail ended up connected to itself. It continued to deliver the message to itself, and because 127. is allowed to relay on my system, the message was accepted. Then qmail would immediately begin delivering the message to itself again. Wash, rinse, repeat. I stopped this from happening by denying connections from 127. in my TCP rules file for qmail-smtpd (I changed 127.:allow,RELAYCLIENT="",,RBLSMTPD=""DENYMAIL="DNSCHECK" to 127.:deny ), but this seemed like kind of a kludgey solution. So I have 2 questions. 1) Is there a better way to do this? Allowing 127. to relay is a convenient way for me to test. I'd like to be able to null-route to these addresses in smtproutes instead, but I don't see a way to do that. 2) Will anything bad happen as a result of blocking SMTP connections from 127.? I can't think of what this would break, but I've always had this address allowed to relay before . . . Thanks, --ScottG.
Re: Open relay access based on domain
Bjorn Nilsen [EMAIL PROTECTED] writes: I need to allow open relay on my mail server for a certain domain eg: *.somedomain.com. tcpserver does not seem to support domain names is there some other way that I can do this? You should be able to use =.somedomain.com:allow,RELAYCLIENT="" with the latest version of tcpserver. Earlier versions didn't support this without a patch. -ScottG.
Re: Multiple instances of qmail...
[EMAIL PROTECTED] writes: Henning Brauer wrote: On Thu, Jan 18, 2001 at 07:35:33PM -0500, [EMAIL PROTECTED] wrote: My question is, is it possible to run multiple instances of qmail, sharing the same disk structure, configuration, etc.. at least /var/qmail/queue/ must be local. Maildirs on NFS isn't that problem. I won't rely on linux NFS, but thats another thing. So let's say each cluster node was using something like /var/qmail/queue/_NODE_IP_HERE_/ on the NFS server, it wouldn't be a problem for the delivery or the Maildirs? If this is the case, is there a startup option I can give to qmail-smtpd to change it's mail queue path? (Or a simple hack) The simple hack is to make /var/qmail/queue a symlink to the real queue directory, somewhere on an NFS server. But unless your system is extremely small, NFS performance will be an issue. We were not able to use NFS-mounted queues for a 40,000 user system at all, with Solaris clients and a NetApp server, arguably two of the best NFS implementations out there. -ScottG.
Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Scott Gifford [EMAIL PROTECTED] writes:
We received an influx of mail today addressed to (probably bogus)
users at the domain 'groupprojects.net'. This domain has the
following MX record:
groupprojects.net preference = 0, mail exchanger = 0.0.0.0
When we received the message, qmail connected to 0.0.0.0 to deliver
the mail. 0.0.0.0 connects to 127.0.0.1, so qmail ended up connected
to itself. It continued to deliver the message to itself, and because
127. is allowed to relay on my system, the message was accepted. Then
qmail would immediately begin delivering the message to itself again.
Wash, rinse, repeat.
[ ... ]
Further investigation of this problem has led me to what seems to be a
subtle bug in qmail.
in ipme.c, qmail tries to decide what IP addresses will connect back
to itself. It does this by finding the IP addresses of all network
interfaces on the system, and putting them into an ipalloc structure
called ipme. Then, in qmail-remote.c, it deals with the situation
where the best-preference MX for a domain is itself, but this domain
doesn't appear in control/locals, by issuing a permanent failure for
the message, via perm_ambigmx(), which displays the familiar error
message:
Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)
This is necessary to prevent a tight internal mail loop, like the one
I encountered below. Otherwise, qmail will see that the message isn't
local, qmail-remote will connect to its own IP address, and the
message will be re-injected.
The problem is that 0.0.0.0 is a special IP address which refers to
"This host on this network" (RFC 1122, 3.2.1.3a), although it isn't
the address of any of the interfaces on a host. According to Paul
Vixie in the comp.protocols.tcp-ip.domains FAQ (Q5.15):
0.0.0.0 is just an alias for the first interface address assigned
after a system boot [ ... ]
The IP stacks I've checked (Solaris and Linux) behave consistently
with this.
Because qmail doesn't recognize 0.0.0.0 as an IP address which refers
to the local host, when it sees an MX record with that address, it
doesn't recognize it as being an address that will connect back to
itself. This causes the looping scenario that ipme is designed to
prevent.
The simple solution to this problem is to add 0.0.0.0 to ipme, by
adding something like:
ip_scan("0.0.0.0",ix.ip);
if (!ipalloc_append(ipme,ix)) { close(moreipme_fd); return 0; }
into ipme.c, around line 96.
The solution we actually used took advantage of an internal patch
which allows us to list additional addresses to be added to ipme in
"control/moreipme", which works around some other problems qmail has
when addresses that refer to it go through any kind of address
translation or proxying, and it can't recognize them as local. We
just added 0.0.0.0 to the beginning of this file, and all was well.
I'd be happy to hear any comments on this problem.
-ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Matt Brown [EMAIL PROTECTED] writes: This has been a feature of recent spam, which is probably why it's now an issue. Several spam senders are now having sender addresses of spammer@spamdomain, where spamdomain resolves via DNS to '0.0.0.0'. Eventually qmail rejects the message because it recognises that it's looped around too much, of course. Right, but it's a very effective (perhaps inadvertant) DOS tool. If you can generate a stream of 10 messages/sec of these, it's the equivalent of generating about 300 messages/sec --- a great way of turning a puny dial-up connection into a mail server crushing machine. We had a spammer sending a huge number of messages to users at this address (sigh their fake bounce addresses are now getting on each others' list...), which was causing our not-processed queues to hover around 100, which was causing regular messages to be processed very slowly. Since qmail works around this simple mail loop for other address referring to the local machine, it should do so for 0.0.0.0 as well. --ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 o r 127.0.0.1)
Greg Owen [EMAIL PROTECTED] writes: Well I guess that this one is definitely elligible for the "qmail security challenge". http://web.infoave.net/~dsill/qmail-challenge.html I don't think so. The challenge says: Obviously, the purpose of reporting this bug wasn't to win the expired qmail challenge. It's not a security bug, but a correctness bug, and a DoS bug (it seriously horked our mail servers). [ ... ] This attack merely causes messages to loop a bit before bouncing. This barely even qualifies as a DOS attack. A message sent into the system, sent to a user at a 0.0.0.0 MX host, from a user at a 0.0.0.0 MX host, passes through qmail-smtpd, qmail-queue, qmail-send, and qmail-remote 60 times before it's gone from your system (30 before it bounces, and another 30 trying to deliver the bounce). That means that if you have 2% of your messages addressed this way, deliberately or accidentally, you need 120% more power (over twice as much) to process the bounces. It means that a user sending a steady stream of 10 (small) messages/sec over a dialup connection makes your system deal with 600 messages/sec, which would normally take a T1. A user on a T1 or fast DSL sending 600 messages/sec makes your system deal with 36,000 messages/sec, which would normally take 2 T3s. It makes it possible for a home user with relatively few resources to take down a medium-sized qmail installation with no real effort. And they can even do it accidentally, if they're spamming or dealing with a mailing list. Our mail system at OneMain.COM processes over 23 million messages a day with no problem, and this bug brought it to its knees. It's a serious bug. But it's relatively easy to fix (in ipme.c), or to work around (don't allow connections from 127.0.0.1 to qmail-smtpd). ---ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Markus Stumpf [EMAIL PROTECTED] writes: On Thu, Jan 25, 2001 at 01:56:45PM -0500, Patrick Bihan-Faou wrote: Well failure to recognize that 0.0.0.0 is yourself is not quite DNS related exploit. It is a bug. If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. No it won't. qmail will give an error that the MX records points back to itself, and bounce the message. qmail knows that MX records that point back to you are a problem, it just doesn't know that 0.0.0.0 points back to itself. That's why it's a bug. --ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
Markus Stumpf [EMAIL PROTECTED] writes: On Thu, Jan 25, 2001 at 06:32:47PM -0500, Scott Gifford wrote: Markus Stumpf [EMAIL PROTECTED] writes: If AOL or hotmail would decide to change their MX records to your mailserver this will for sure also cause you problems. No it won't. qmail will give an error that the MX records points back to itself, and bounce the message. I don't think that any mailserver out there will be able to handle the load if AOL or Hotmail will change the MX record to point at that system (without prior notice). This would be a DOS just like the 0.0.0.0 is. Oh, I see. Yes, that's correct. There are all kinds of DOS attacks against any public Internet service. The ones to worry about are the ones that let a single user with a slow Internet connection deny service to a large number of people. The ones that require being singled out for destruction by large ISPs, there's nothing that can really be done about. -ScottG.
Re: Subtle qmail bug? (was Re: Handling an MX record of 0.0.0.0 or 127.0.0.1)
"D. J. Bernstein" [EMAIL PROTECTED] writes: Patrick Bihan-Faou writes: If you don't count that as a bug in qmail, then I don't know what is a bug... In fact, it's not a bug; it's a portability problem. If you were using OpenBSD, you'd see outgoing connections to 0.0.0.0 rejected with EINVAL. Although the proposed fix, adding 0.0.0.0 to ipme, doesn't pose any kind of compatibility problem. -ScottG.
Re: ipme.c patch
"James" [EMAIL PROTECTED] writes:
There was recently some talk on this list about about patching ipme.c
to add 0.0.0.0 to qmail's list of known local addresses.. and the
original poster supplied a patch. However, the patch was only _part_
of a bigger patch.. leaving those of us that aren't familiar with
qmail's code in the dark.
So.. my question is, could someone please post a complete patch to
work around this issue? Or at least a URL to their patch? Thanks.
Here's a patch that implements my recommendation. Note that for
reasons discussed in my earlier messages, this isn't the patch that we
actually use in production machines, so I can't guarantee it won't
break anything, but it looks like an obvious fix. Still, I would test
it on a development machine first.
You can verify that this patch has worked by running "ipmeprint" after
applying it. 0.0.0.0 should be printed out first, followed by all of
your IP addresses, each on their own line.
If anybody can report success or failure with this patch, I'd
appreciate it.
I'll put it up on my Web page and post the URL when I can.
--ScottG.
--- qmail-1.03/ipme.c Mon Jun 15 06:53:16 1998
+++ qmail-1.03-sg/ipme.c Mon Jan 29 02:27:38 2001
@@ -46,6 +46,11 @@
ipme.len = 0;
ix.pref = 0;
+ /* 0.0.0.0 is a special address which always refers to
+ * "this host, this network", according to RFC 1122, Sec. 3.2.1.3a.
+ */
+ byte_copy(ix.ip,4,"\0\0\0\0");
+ if (!ipalloc_append(ipme,ix)) { return 0; }
if ((s = socket(AF_INET,SOCK_STREAM,0)) == -1) return -1;
len = 256;
Re: ipme.c patch
Adi's patch is actually not correct. It adds "0.0.0.0" *instead of*
your other interfaces, instead of *in addition to* your other
interfaces.
ipmeprint shows this. Here's qmail's normal ipme:
[sgifford@sghome qmail-1.03]$ ./ipmeprint
127.0.0.1
10.0.0.8
here it is with Adi's patch:
[sgifford@sghome qmail-1.03-adi]$ ./ipmeprint
0.0.0.0
0.0.0.0
and here it is with the patch I just posted:
[sgifford@sghome qmail-1.03-sg]$ ./ipmeprint
0.0.0.0
127.0.0.1
10.0.0.8
Thanks for taking a stab at it, though, Adi! :)
-ScottG.
adi [EMAIL PROTECTED] writes:
On Mon, Jan 29, 2001 at 06:39:36AM +, James wrote:
So.. my question is, could someone please post a complete patch to
work around this issue? Or at least a URL to their patch?
Try this patch. Use with your own risk.
And don't forget to say thank to Scott Gifford @ tir.com.
Regards,
P.Y. Adi Prasaja
--- ipme.cMon Jun 15 17:53:16 1998
+++ /usr/local/src/qmail-1.03/ipme.c Mon Jan 29 13:48:00 2001
@@ -74,6 +74,7 @@
byte_copy(ix.ip,4,sin-sin_addr);
if (ioctl(s,SIOCGIFFLAGS,x) == 0)
if (ifr-ifr_flags IFF_UP)
+ ip_scan("0.0.0.0", ix.ip);
if (!ipalloc_append(ipme,ix)) { close(s); return 0; }
}
#else
@@ -84,6 +85,7 @@
if (ifr-ifr_addr.sa_family == AF_INET) {
sin = (struct sockaddr_in *) ifr-ifr_addr;
byte_copy(ix.ip,4,sin-sin_addr);
+ip_scan("0.0.0.0", ix.ip);
if (!ipalloc_append(ipme,ix)) { close(s); return 0; }
}
#endif
Re: ipme.c patch
adi [EMAIL PROTECTED] writes:
[ ... ]
Arggh.. thanks again!
Our mailserver currently being attack by navidad.exe ;-(
I didn't received your patch, yet. Anyway, I think this patch would
be more correct than previous one :-)
Yep, that patch looks fine; mine's pretty much the same, but puts the
IP address first instead of last, and uses byte_copy instead of
ip_scan to fill in the ix structure.
-ScottG.
% ./ipmeprint
127.0.0.1
10.0.7.21
10.0.7.20
10.0.100.1
10.0.100.2
10.0.100.3
10.0.100.4
10.0.100.5
0.0.0.0
Regards,
P.Y. Adi Prasaja
--- ipme.cMon Jun 15 17:53:16 1998
+++ /usr/local/src/qmail-1.03/ipme.c Mon Jan 29 16:09:15 2001
@@ -89,6 +89,8 @@
#endif
x += len;
}
+ ip_scan("0.0.0.0", ix.ip);
+ if (!ipalloc_append(ipme,ix)) { close(s); return 0; }
close(s);
ipmeok = 1;
return 1;
Re: QSBMF -
Dave Sill [EMAIL PROTECTED] writes: Chris McDaniel [EMAIL PROTECTED] wrote: I'm wondering what the consequences of breaking QSBMF are. My desire is to change the bounce messages to something more professional (we've had some complaints) Seriously? Sheesh. We got similar complaints for our mail system. and the req'd "Hi. This is the" would probably be the first thing to go. So, if I change it to something else, what will I break? Well, anything that parses QSBMF. I'm not sure offhand what the consequences would be, though. Most bounce handlers are pretty flexible, by necessity. I'll have to check the code to be sure. We made a change like this nearly a year ago, and have had zero issues. --ScottG.
Re: QSBMF -
Scott Gifford [EMAIL PROTECTED] writes: [ a bunch of stuff about changing qmail's default bounce message] We made a change like this nearly a year ago, and have had zero issues. I got a question off-list about how to make this change, from a person whose email is at usa.net. Since usa.net has, from all accounts, a completely insane policy of blocking mail servers, I cannot respond directly, so I'll send the response here. It might be of general interest anyways. Pretty much the whole trick is to go into qmail-send.c, around line 708 (search for "Hi"), and just change the message that is output. As with any source change, you'll want to test it first, and make sure the message is reasonably formatted, has all important information, and the proper headers and envelope. -ScottG.
Re: ipme.c patch
"James" [EMAIL PROTECTED] writes: There was recently some talk on this list about about patching ipme.c to add 0.0.0.0 to qmail's list of known local addresses.. and the original poster supplied a patch. However, the patch was only _part_ of a bigger patch.. leaving those of us that aren't familiar with qmail's code in the dark. So.. my question is, could someone please post a complete patch to work around this issue? Or at least a URL to their patch? Thanks. I have put a copy of the 0.0.0.0 patch (the same one I posted to this mailing list a week or three ago) in: http://www.tir.com/~sgifford/qmail/ at http://www.tir.com/~sgifford/qmail/qmail-0.0.0.0.patch That will be its permanent home, so feel free to link to it. --ScottG.
Re: RBL and ORBS
"Andrew Wafula" [EMAIL PROTECTED] writes: Hello, I was at the ORBS site the other day and I saw that as from 1st Feb 2001 relays.orbs.org would be deleted. This may seem dumb but here goes :). Now, does it mean that we can no longer use it to check for open relays No, they just split it up, to make it easier to pick and choose the parts of ORBS that you want to use. From the same part of the page that says that relays.orbs.org is going away (http://www.orbs.org/usingindex.html): * relays.orbs.org is going away and will be deleted by 1 February 2001. * Manual entries and netblock entries have already been removed from relays.orbs.org. * Use inputs.orbs.org for single stage relay filtering * Use outputs.orbs.org for immediate filtering of multihop relays. * Use delayed-outputs.orbs.org for multihop relay filtering using a 3-5 day grace period. and also the experimental zones: * manual.orbs.org - open relays tested manually and believed to be blocking the tester. Return code is 127.0.0.5. Updated: hourly * spamsources.orbs.org - direct spam sources. Returns 127.0.0.6. Updated: hourly * untestable-netblocks.orbs.org - netblocks known to contain open relays and which have been proven to be blocking the ORBS tester or who have demanded that ORBS not test. Returns 127.0.0.7. Updated: hourly * spamsource-netblocks.orbs.org - spam source and support netblocks. - Returns 127.0.0.8. Updated: hourly What this means is that you can configure your rblsmtpd to use: -routputs.orbs.org to get only use the actual, verified SPAM relays that ORBS does a good job of finding, and avoid all of their political bullshit. And you can use -rinputs.orbs.org on your customers to make sure you don't allow them to send spam through you as a third-party relay. On the whole, it should be a good thing, even if you hate ORBS. Makes it easier to pick and choose which parts of ORBS you agree with, and just filter based on them. And it makes it harder for people to drop mail that is blocked by the somewhat more biased parts of ORBS (like spamsource and untestable-netblocks) without realizing that's what they're doing. and if so what replacement do we have? Although ORBS isn't going anywhere, the RBL (www.mail-abuse.org) does similar things. --ScottG.
Re: 550 User Unknown
Herbie [EMAIL PROTECTED] writes: Am I right in think qmail-smtpd will never give this error? Yes. As I see it qmail-smtpd will only check the domain of the message to see if it is valid, ie it will accept any valid username for localhost whether the user actually exists on the system or not. Is that part handled by qmail-send? Yes. qmail-send will generate a bounce message if the user ends up not existing. qmail-smtpd just checks the domain, and then sticks it in the queue. --ScottG.
Re: qmail-0.0.0.0.patch not found
Claudio Nieder [EMAIL PROTECTED] writes:
www.qmail.org mentions Scott Gifford's patch making qmail recognize
0.0.0.0 as local IP address. But the link to the patch
http://www.tir.com/~sgifford/qmail/qmail-0.0.0.0.patch
is invalid:
Not Found
The requested URL /~sgifford/qmail/qmail-0.0.0.0.patch was not found on this server.
Does anybody know, where the actual place for this file is?
Yeah, I'm having trouble with my Web site this week. Here's a copy.
Things should be back up after this weekend, I hope.
-ScottG.
--- qmail-1.03/ipme.c Mon Jun 15 06:53:16 1998
+++ qmail-1.03-sg/ipme.c Mon Jan 29 02:27:38 2001
@@ -46,6 +46,11 @@
ipme.len = 0;
ix.pref = 0;
+ /* 0.0.0.0 is a special address which always refers to
+ * "this host, this network", according to RFC 1122, Sec. 3.2.1.3a.
+ */
+ byte_copy(ix.ip,4,"\0\0\0\0");
+ if (!ipalloc_append(ipme,ix)) { return 0; }
if ((s = socket(AF_INET,SOCK_STREAM,0)) == -1) return -1;
len = 256;
Re: New qmail version request
Charles Cazabon [EMAIL PROTECTED] writes: Chris Garrigues [EMAIL PROTECTED] wrote: Much of the common patches that are around fail in one of the tests above, at least when using the author's stringent tests. There's nothing wrong with this; he keeps qmail secure, reliable, efficient, and "correct", and anyone who wants to applies patches as they see fit. I, for one, am hoping that 2.0 will have LDAP support which meets his standards. As you said, the existing LDAP libraries are probably crap. But why does qmail have to be patched to use LDAP? Why not use a script which extracts user information from the LDAP database, puts it in passwd format, and feeds it to qmail-pw2u? Then cron it every hour or something. Voila, instant qmail+LDAP with no patches. If you want to set it up with virtualdomains-type use, have the script output qmail-users style output directly. In many environments (including ours), it's not acceptable to wait an hour or more (it takes our LDAP server about 2.5 hours to dump our 3 million user accounts into a text file, so significantly more) for a password change or a change to mail aliases to go through. Especially if you have users changing their own forwarding, who need to be able to test the changes. If they're waiting 2 hours for updates to take effect and are typo-prone, playing it by ear, or making changes for the first time, it could easily take an entire work day to get a mail forward or vacation right. This approach is also pretty hard on an LDAP server. Just to make a rough estimate, in an average hour, about 10% of our users check their mail, and about 10% receive messages, so you need to look at 20% of the entries in LDAP. If you dump it out, you need to look at 100% of the entries, so it's requires 5 times more power. While building a passwd-like file might work in some environments, it certainly doesn't work for everybody. That's why qmail-ldap exists, and is gaining popularity. --ScottG.
Re: New qmail version request
Peter van Dijk [EMAIL PROTECTED] writes: LDAP is not part of an MTA. It's an extension. LDAP may not be part of an MTA (although it certainly can be, if it contains aliases), but it's a quite reasonable part of an MDA, which qmail also includes in qmail-local. It's certainly as reasonable a place to store account information as /etc/passwd, which qmail supports without an extension. While LDAP support may or may not be appropriate for the primary qmail distribution, it's not so wildly inappropriate as to warrant a two-sentence dismissal. :-) --ScottG.
Re: qmail-pop3d bug
Peter van Dijk [EMAIL PROTECTED] writes: On Sat, Mar 10, 2001 at 01:12:13PM -0500, John R Levine wrote: The usual mailbox vs. maildir war has flared up on inet-access, and points out a bug in qmail-pop3d. When you do a LIST command, it gives you the size of each message. Pop3d just reports the file sizes, while it's clear from the RFC that it's supposed to report the wire size of each message, i.e., the size using cr/lf as a line terminator, so the sizes it reports are too small. [ ... ] Yes. This behaviour is known. Fixing it, however, involves a *huge* performance downgrade of qmail-pop3d. A solution I have considered is storing the messages in wire format. Especially for POP/IMAP-only clients, seems like it could be a medium-sized performance win, since the line-conversion is done only once, regardless of how many times the message is downloaded. If the message were kept in wire-format from SMTP through delivery, no line conversion would be required at either end, and a larger performance gain would be possible. Has anybody tried this, or anything like it? -ScottG.
Re: [Fwd: Administrivia: Mailing List Software]
Andre Oppermann [EMAIL PROTECTED] writes: Mark Delany wrote: [ ... ] Elias also talks about an emulation layer for LISTSERV. I've not heard of anyone providing that for ezmlm. I don't know if there is any mailing list software out there having an emulation layer for LISTSERV... Worst case he has to write one. the ezmlm-idx FAQ implies that this is possible and straightforward: FAQ 15.2 Setting up ezmlm to respond to host-centric FAQ commands. FAQ The ezdomo.tar.gz file included in the ezmlm-idx=0.31 FAQ distribution contains the basic files needed to set up ezmlm FAQ to respond to host-centric command syntax. See the following FAQ section for the format and utilization of such syntax for the FAQ major non-ezmlm mailing list managers available today. This FAQ section will set up majordomo@host as the example. The setup FAQ for other command addresses, such as listproc or listserv are FAQ the same, except the contents of DIR/inlocal and DIR/outlocal FAQ need to be changed appropriately. FAQ The ezmlm-idx=0.31 distribution also contains a script, FAQ ezmlm-glmake(1) that will set up the global interface for FAQ you. It works in a manner similar to ezmlm-make(1) and will FAQ in ezmlm-idx-0.32 be replaced with a special ezmlm-make(1) FAQ config file. See the description below for details on what FAQ ezmlm-glmake(1) does, or if you prefer to set this up FAQ manually. FAQ [ detailed instructions omitted ] FAQ 15.3 Commands of other mailinglist managers recognized by FAQ ezmlm. FAQ Listproc/Listserv. FAQ When set up as above, substituting ``listproc'' or FAQ ``listserv'' for ``majordomo'' as appropriate, ezmlm will FAQ recognize and respond to the following commands placed in the FAQ body of the e-mail with the syntax below. Note: ezmlm will FAQ only respond to one command per message. FAQ syntax: command listname [subscribe@host] FAQ Supported commands FAQ subscribe, sub, unsubscribe, unsub, list, help, review. FAQ Additional supported commands FAQ All ezmlm commands, such as ``thread'', ``index'' and FAQ ``get'' as well as the list owner's commands. FAQ This interfaced makes information available via command FAQ messages to the appropriate mailing list. Thus, ``list'' and FAQ ``review'' will send a subscriber list only to remote FAQ administrators and only if specifically allowed by the list FAQ owner. --ScottG.
Re: Does the current ucspi-tcp support hostnames in tcp.smtp?
Charles Cazabon [EMAIL PROTECTED] writes: Chris Johnson [EMAIL PROTECTED] wrote: On Tue, Apr 17, 2001 at 05:57:52PM -0700, Frank Precissi wrote: My question: Does ucspi-tcp support hostnames? If so, would they be added as: domain.com:allow,RELAYCLIENT="" or .domain.com:allow,RELAYCLIENT="" I would guess that this would work. To confirm it, I'd try it and see what happens. This is not the correct syntax. From http://cr.yp.to/ucspi-tcp/tcprules.html (I've marked hostname related rules with a *): Addresses tcpserver looks for rules with various addresses: 1. $TCPREMOTEINFO@$TCPREMOTEIP, if $TCPREMOTEINFO is set; * 2. $TCPREMOTEINFO@=$TCPREMOTEHOST, if $TCPREMOTEINFO is set and $TCPREMOTEHOST is set; 3. $TCPREMOTEIP; * 4. =$TCPREMOTEHOST, if $TCPREMOTEHOST is set; 5. shorter and shorter prefixes of $TCPREMOTEIP ending with a dot; * 6. shorter and shorter suffixes of $TCPREMOTEHOST starting with a dot, preceded by =, if $TCPREMOTEHOST is set; * 7. =, if $TCPREMOTEHOST is set; and finally 8. the empty string. tcpserver uses the first rule it finds. You should use the -p option to tcpserver if you rely on $TCPREMOTEHOST here. We use =.domain.com:allow,RELAYCLIENT="" =domain.com:allow,RELAYCLIENT="" to allow anything ending with "domain.com" to relay, and also allow the machine named "domain.com" itself to relay. I've never used this feature either, but the original poster should beware that allowing relaying based on hostname is insecure; the sender does (or can) have control over their reverse DNS resolution, and can therefore make their IP address resolve to a hostname in your domain, and proceed to spam the internet silly through your system. You then get added to ORBS, RBL, RSS, etc. Use the "-p" option to prevent this. It checks the reverse DNS to get a hostname, then looks up the hostname to make sure that one of the addresses is the original address. It takes care of the issue above. From http://cr.yp.to/ucspi-tcp/tcpserver.html: * -p: Paranoid. After looking up the remote host name in DNS, look up the IP addresses in DNS for that host name, and remove the environment variable $TCPREMOTEHOST if none of the addresses match the client's IP address. * -P: (Default.) Not paranoid. --ScottG.
RFC 2821 and 2822
Hadn't seen this mentioned here, and thought it might be of general interest. RFCs 2821 and 2822 were published today, obsoleting the venerable RFCs 821 and 822, covering SMTP and the Internet Message Format, respectively. They're available from the usual places, including: http://www.rfc-editor.org/rfc/rfc2821.txt http://www.rfc-editor.org/rfc/rfc2822.txt ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt No big changes; from what I've read so far (I've read half of 2821), they just do things like remove cruft (SEND, SOML, and friends), deprecate things that haven't been used in the real world for years (source-routing of email addresses), and clarify minor ambiguities. -ScottG.
Re: how to _delay_ failed authentication
Kittiwat Manosuthi [EMAIL PROTECTED] writes: Anybody know how to delay failed authentication attempts to prevent brute force pwd cracking on POP3 server using qmail vpopmail? You might be able to do this via PAM, if you have a checkpassword that supports PAM (available from www.qmail.org): http://www-uxsup.csx.cam.ac.uk/~pjb1008/project/pam_delay/pam_delay/pam_delay.html -ScottG.
Re: Problem with Bcc's 'for' line disappearing
Charles Cazabon [EMAIL PROTECTED] writes: Eric Bonharme [EMAIL PROTECTED] wrote: We have a problem with the 'for' line being stripped out when delivering Bcc'ed messages to the Bcc'ed recipient locally. qmail doesn't remove any headers. What is a for header? I've never seen such a beast. Eric is probably talking about the for clause of the Received header: Received: from muncher.math.uic.edu ([131.193.178.181]) (envelope-sender [EMAIL PROTECTED]) by smtp01.mail.onemain.com (qmail-ldap-1.03) with SMTP for [EMAIL PROTECTED]; 23 May 2001 10:10:26 - here ^^ Looking at the 'for' clause is a hack, and will only work under some circumstances. Particularly, if more than one person on the same mail server receives a message, the 'for' clause will not be present at all. Fortunately, qmail provides a better solution. Use the first 'Delivered-To' header; that will always be there, and will always be correct and unambiguous. -ScottG.
Re: qmail-popbull used w/ imap
Russell Nelson [EMAIL PROTECTED] writes: michael writes: This question I suppose is directed at Russell since he is the writer of qmail-popbull... We're trying to get courier-imap running and the desire is to also have bulletin ability. Since qmail-popbull is called as part of tcpserver startup for qmail I'm hoping it can be inserted into the startup string for imap. Can anyone think of a reason why it wouldn't be able to be done? I'd check it out now, but am still working on getting checkpassword converted for use w/ courier-imap since it appears to need a few extra environment variables set. I'd rather not have to add that functionality into a new piece of code. Won't work, because Mr. Sam chose not to use checkpassword for courier-imap. qmail-popbull requires the use of checkpassword. Here's the configuration I use to make courier-imap use checkpassword and qmail-popbull: http://www.ornl.gov/its/archives/mailing-lists/qmail/2000/04/msg01189.html Good luck, ScottG.
Re: Using Qmail as an exchange server ??
Tonino Greco [EMAIL PROTECTED] writes: [...] What the idea is - MS EXchange does not work that good :) - and we need to replace it - but the exchange server does a poll to another Primary server at a ISP. This hold the mail spool - and when the exchange server dials in - gets the mail and the distributes it locallly . Can this be done with qmail ??? You could probably do this with a combination of qmail and fetchmail. Fetchmail is at http://www.tuxedo.org/~esr/fetchmail/ -ScottG.
Re: Suspending an POP3 account.
Reid Sutherland [EMAIL PROTECTED] writes: [...] Most likely I'll have to store password somewhere and replace it in the shadow file with a 'x' when suspended, and put the crypt password back once the account is restored. Not qmail related, but a trick I like to use is to just prepend *LOCK* to their crypted password entry. Then to restore the account and put the correct crypted password back, you just remove *LOCK*. For example, if I have sgifford:abc12345: in /etc/shadow, it becomes sgifford:*LOCK*abc12345: That solves the problem of where to put the password, but maybe there is a more elegant qmail-based solution. Good luck, -ScottG.
Re: Speed up injecting
Gianni Campanile [EMAIL PROTECTED] writes:
[...]
My problem is to speed up the injection of mails.
The system I am setting up must send mail to different people
based on external triggers, so in peak times it must send
up to 1 different mails to different recipients as soon as possible.
Unfortunately, I have two constraints:
1) Solaris (Slowlaris);
We run qmail just find on Solaris...
2) Only one process can injects the mails, so there is
no concurrency on the injection phase.
It should be not-too-hard to make this one process fork off and run a
fixed number of qmail-inject processes simultaneously. Something to
the tune of:
#define MAX_FORKS 10
int process_count=0;
int kidstat;
while (more_messages())
{
if (process_count = MAX_FORKS)
{
wait(kidstat); /* Do some error checking, too. */
process_count--;
}
switch(fork())
{
case -1: /* Didn't work. */
/* Do some error checking, maybe try to recover */
exit(1);
case 0: /* Child */
send_message(); /* This would call qmail-inject */
exit(0);
default: /* Parent */
process_count++;
break;
}
}
while (process_count)
{
wait(kidstat);
process_count--;
}
This probably isn't exactly right, but should get you started.
If you can make your program use xargs to start up processes, GNU
xargs supports a command-line flag telling it how many processes to
run in parallel.
If all else fails, and the problem really is the overhead from
fork()/exec(), you could probably hack up qmail-inject or qmail-queue
to handle multiple messages at a time, but it looks like you'd be on
your own. Still, shouldn't be horrendously difficult.
Good luck,
ScottG.
Re: weird qmail-popup behaviour?
Peter van Dijk [EMAIL PROTECTED] writes: On Fri, Jul 06, 2001 at 11:00:12PM +0200, Arjen van Drie wrote: [snip] You will see this if you use `cat -ve' on the file. Thanks all. It works now. How does one read hexdumps? Is there a howto or a table somewhere? [...] For reading hexdumps without ascii side-output, you need to convert the hex codes to ascii. Google can teach you a lot about that, I don't have anything handy right now (and too much blood in my alcohol). On Linux, see the ascii(7) manpage. If you're not, search around for it, or email me off-list and I'll send you a copy. ScottG.
Re: selective relaying
~darkage [EMAIL PROTECTED] writes: [...] This is what my tcp.smtp.cdb looks like - 10.1.0.28.:allow,RELAYCLIENT= :allow Do you mean to say that's what your /etc/tcp.smtp file looks like? If that's really what's in /etc/tcp.smtp.cdb, that's your problem; it should be in /etc/tcp.smtp, and the tcprules command you list below will build /etc/tcp.smtp.cdb, which is a binary file. If it was just a typo, you'll need to post exactly what happens when you try to log (what you have looks right), and what the logs say when it happens. I've ran tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp /etc/tcp.smtp too.. [...] Good luck! ScottG.
Re: Mailing from One connection
Rodney Broom [EMAIL PROTECTED] writes: Charles Cazabon [EMAIL PROTECTED] D Rajesh [EMAIL PROTECTED] wrote: DR If in the total 20,000 mails, say 5000 are hotmail, 5000 are yahoo and the DR rest are to other domains. Then, is it possible to open a single DR qmail-remote process and dump all messages to be sent to hotmail on one DR connection and open another connection for all yahoo messages CC qmail is designed specifically _not_ to do this. sendmail does this. DR I guess this speeds up the mail delivery amazingly CC No, it slows it down tremendously. That's why qmail doesn't do it. * From Rodney: I haven't tested qmail against sendmail, infact I've barely even used qmail. But I have done a bit of network programming, so let me open a few points for consideration: [...] This has been hashed, rehashed, and re-re-hashed on this list. It inevitably ends in a flameware, somebody telling somebody else to profile rather then speculate, and a series of past analyses of these events supporting both sides of the argument being dredged up. Please don't continue with this unless you have read through the archives and know what you're getting into. :) -ScottG.
Re: Netgear RP114 Router doesn't work well with Qmail POP daemon?
Chin Fang [EMAIL PROTECTED] writes: [...] I then asked him to use telnet to port 110 to our POP server, and he still got the delay. So, I am quite sure it's most likely caused by the Netgear RP114, although I don't see any reason why this is so. A common cause of this can be your POP server taking a long time to resolve his IP address into a name, and possibly his name back into an IP address. If the RP114 is doing NAT or acting as a proxy, he could be connecting from a different IP address than before. To test this, when he is connected, use lsof(8) or fuser(1) to find out what address he's coming from. Then try using whatever name lookup tools you have at your disposal (probably nslookup came with your OS) to look up his IP address, then again to look up the resulting name. If either step is slow or fails, there's your problem. Otherwise, the way I usually diagnose these things is with strace(1) or truss(1) attached to the tcpserver process. This only works if it's a pretty slow day, or you have him connected to a test server of some kind; otherwise there's too much background noise. Good luck! --ScottG. [...]
Re: NetGear, was Re: I get timeouts
John Groseclose [EMAIL PROTECTED] writes: At 1:22 AM +0200 7/11/01, Henning Brauer wrote: The Realtek cards and in special the netgear ones are pure crap, but I'm not aware about such problems with them. The original revision of the NetGear cards apparently used a real tulip driver - I had two of the original cards, and two of the later ones (FA310TX) and the older ones work flawlessly, while the later ones do all kinds of bizarre things. On Linux 2.2.x, try switching to the newer National Semiconductor drivers: http://www.scyld.com/network/netsemi.html All of my weird problems disappeared when I switched to this driver. -ScottG.
