qmail and load balancers
Title: qmail and load balancers Does anybody have a qmail system setup in a farm behind a RadWare WSD Pro+ load balancer using NAT outbound? If so, have you had any issues with large concurrency from the qmail server disrupting service on the RadWare systems? When I let my qmail server loose, and have it send as much mail as it possibly can, it brings the load balancer to it's knees. Tech support has no idea what's wrong, and are presently trying to recreate the issue in their test environment. I'm just hoping somebody else has seen this problem before, maybe not even with a radware load balancer, but some other one? Any input is appreciated. Thanks, Mark
RE: What does this mean?
Title: RE: What does this mean? That's qmail delivering your messages, or the messages of your users. A normal occurrence, as long as you have users who should be sending mail. Otherwise, you need to look into your relaying rules. Mark -Original Message- From: Mike Jimenez [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 18:05 To: Qmail Subject: What does this mean? Is this something I should be concerned about or is this normal Qmail activity? Thanks Mike qmailr 808 0.0 0.0 1172 468 ? S 15:14 0:00 qmail-remote china.com [EMAIL PROTECTED] qmailr 809 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote mailstrom.virtumundo.com [EMAIL PROTECTED] qmailr 810 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote campaign.pointers.co.uk usera-168-s.gosling=binternet.c qmailr 811 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote WWWNode4.b7.co.uk [EMAIL PROTECTED] qmailr 815 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote WWWNode2.b7.co.uk [EMAIL PROTECTED] qmailr 819 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote WWWNode4.b7.co.uk [EMAIL PROTECTED] qmailr 824 0.0 0.0 1172 468 ? S 15:14 0:00 qmail-remote e-weekly.co.uk [EMAIL PROTECTED] qmailr 839 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote nms1.empowerhealth.com [EMAIL PROTECTED] qmailr 840 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote nms1.empowerhealth.com [EMAIL PROTECTED] qmailr 848 0.0 0.0 1172 472 ? S 15:14 0:00 qmail-remote WWWNode1.b7.co.uk [EMAIL PROTECTED] qmailr 849 0.0 0.0 1172 468 ? S 15:14 0:00 qmail-remote MYLISTMAILING.COM owner-al_alloydistlist@MYLISTMAILING.
qmail, tdma, logging (long)
Hi, I have a few questions regarding qmail and tdma, the tdma archives seem down at the moment (no dns service for libertine.org?) What I'm trying to do: 1) receive an email for any user at a domain 2) run my own process, if certain conditions are met, it passes through ok 3) otherwise (majority) it hands off to tmda i've got above three working ok and then 4) if user successfully responds to tmda, i need to run my own process again So far, I do it like this: |/home/myprivacy/inbound |/usr/local/tmda/bin/tmda-filter |/home/myprivacy/outbound The inbound program simply hands off to tmda-filter, conditionally, by writing the entire email to STDOUT, is this the proper way to do it? I was opening a pipe to tmda-filter but I couldn't figure out a way to then make successful responses to tmda challenges fall through to my outbound program. When I started writing to stdout to effect the fall through to tmda, I started also getting way too much info in the qmail logs, like the entire email, the environment, etc, is there any way to control that (example at end of post) Last, how do I set up tmda to function for multiple users? i.e. I will have a multitude of users at foobar.ca, and I need the tmda tags to apply to their own users only. Sorry to ask so many questions here, and the tmda related ones too, its just that the tmda list seems out of commission at the moment. example log overkill: Jul 18 00:31:39 tex qmail: 995434299.982280+/_myPrivacy.ca/_/_/_---_Below_th is_line_is_a_copy_of_the_message./_/_Received:_(qmail_16706_invoked_from_netwo rk);_18_Jul_2001_04:29:07_-/_Received:_from_r2d2.easydns.com_([EMAIL PROTECTED] 40.242)/___by_tex.privateworld.com_with_SMTP;_18_Jul_2001_04:29:07_-/_Rece ived:_from_localhost_(markjr@localhost)/__by_r2d2.easydns.com_(8.11.3/8.11.0)_w ith_ESMTP_id_f6I4T4t29545/__for_[EMAIL PROTECTED];_Wed,_18_Jul_2001_00: 29:04_-0400/_Date:_Wed,_18_Jul_2001_00:29:03_-0400_(EDT)/_From:_Mark_Jeftovic_ [EMAIL PROTECTED]/_X-Sender:[EMAIL PROTECTED]/_To:[EMAIL PROTECTED]/E rror_report_too_long,_sorry./ Jul 18 00:31:39 tex qmail: 995434299.982280+_(CIRA)_and_participating_.CA_regist rars_to_pass_through_to_myPrivacy.ca/_email_addresses_unimpeded._/_/_All_othe r_email_must_go_through_an_additional_step_which_vastly_decreases/_the_odds_of_ your_email_being_an_Unsolicited_Commercial_Email_(UCE_or_SPAM)./_/_To_complete _this_process_of_getting_your_email_to_the_end_user_holding_this/_myPrivacy.ca_ address,_you_need_merely_reply_to_this_email_or_send_a_message/_to_the_followin g_address:/___/_mailto:[EMAIL PROTECTED] a/_/_which_will_expire_in_5_days_(Mon_Jul_23_04:29:13_2001_UTC)./___ ___/_Fo r_more_informatiom_about_myPrivacy.ca_or_to_create_an_account_their/_for_yourse lf,_visit_http://myPrivacy.ca/_/_Regards, -- mark jeftovic http://www.easydns.com http://mark.jeftovic.net
tdma help
Does anybody know the disposition of tdma right now or the location of some tdma mailing list archives that are not at libertine.org? ObQmailQuestion: what sets EXT3? It appears as though it is the third segment of a dot-qmail file. I've created a userid on my system, foobar, then created a line in virtual hosts a la test.foobar.com:foobar then in ~foobar I can get all email @test.foobar.com with .qmail-default, how do I then get EXT3 set in that case? Looking at the tdma source it keys on that to detect a virtual host -mark -- mark jeftovic http://www.easydns.com http://mark.jeftovic.net
err, I mean tmda (was Re: tdma help)
Dyslexia...I meant tmda below, sorry. -mark On Wed, 18 Jul 2001, Mark Jeftovic wrote: Does anybody know the disposition of tdma right now or the location of some tdma mailing list archives that are not at libertine.org? ObQmailQuestion: what sets EXT3? It appears as though it is the third segment of a dot-qmail file. I've created a userid on my system, foobar, then created a line in virtual hosts a la test.foobar.com:foobar then in ~foobar I can get all email @test.foobar.com with .qmail-default, how do I then get EXT3 set in that case? Looking at the tdma source it keys on that to detect a virtual host -mark -- mark jeftovic http://www.easydns.com http://mark.jeftovic.net
Large queue and iowait
Title: Large queue and iowait I'm having some problems with my qmail server. It seems to be taking an abnormally large amount of time to do queue processing. A recent mailing list send of 250k e-mail's to the server had it stuck in queue processing with iowait at 80-100% the entire time, for over 36 hours. I assume this is not a normal timeframe for processing that amount of e-mail. The setup is as follows: Sun Netra t1 - 450mhz ultrasparcII processor 1024MB of memory, 1.5GB of swap 18GB SCSI disk. Solaris 8 qmail 1.03 with DNS and big-concurrency patch If any other information is pertinent, please let me know and I'll provide it. Any insight into what the problem could be would be greatly appreciated. Thanks, Mark -- s/root/Mark
RE: Large queue and iowait
Title: RE: Large queue and iowait -Original Message- From: Dave Sill [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 17, 2001 13:32 To: [EMAIL PROTECTED] Subject: Re: Large queue and iowait Jake Roersma [EMAIL PROTECTED] wrote: I would check to see if qmail-send has a defunct process.. You will need to restart it or restart qmail altogether and make sure there are no stray proceses that may interfere. I've had multiple instances where the queue becomes abnormally large because qmail-send is defunct.. That ain't right. qmail-send doesn't doesn't just go defunct. I'd suspect a kernel bug. What OS are you using? -Dave See my original e-mail for this info. (Quick answer: Solaris 8). Mark
Moving queue directory
Title: Moving queue directory I would like to move my queue directory to another location. Is there a feasible way to do this while qmail is running, or should I shut it down and move the directory, and then bring qmail back up? Thanks, Mark
Re: qmail won't accept incoming mail (i have no idea what i'm doing anymore :) )
- Original Message - From: Henning Brauer [EMAIL PROTECTED] To: qmail mail list [EMAIL PROTECTED] Sent: Monday, July 16, 2001 4:05 AM Subject: Re: qmail won't accept incoming mail (i have no idea what i'm doing anymore :) ) On Mon, Jul 16, 2001 at 12:02:15PM +0100, Paul Garrett wrote: Thanks, but when i run the smtpd part manually it hangs like below: root@Area79:/var/qmail/bin# ./qmail-smtpd 220 area79.cnm-uk.net ESMTP I then have to kill the process :/ Consult life with qmail again, really. If you had read it careful you would know not to start qmail-smtpd in this manner. -- * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * * Roedingsmarkt 14, 20459 Hamburg, Germany * Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: FYI: Windows is better
Excellent analogy!! I love it! Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time! -Original Message-From: Medi Montaseri [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 05, 2001 8:47To: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: Re: FYI: Windows is betterMicrosoft is like a little convertable sexy car, good for running to the store to buy a pack of cigarette. But if you decide to haul 18 tons of lumber, it is not the right vehicle. As such, how many average people use 18 ton trucks? And as such how much work is done by the trucking (or transportation) industry? "[EMAIL PROTECTED]" wrote: Subject: Windows vs Unix From:Charles Booher h-64-105-140-243.lnoclli.covad.net Tue Jul 3 12:25:05 My second computer was a VA Linux box. I tried to run SCO Unix on my first computer but that did not work out for a number of reasons. When Windows 3.0 was young I was working on various applications for Sun, HP, Silicon Graphics and all those other soon to be defunct Unix Workstation vendors. I was one of the first guys to write a P.O. for Rack mounted Linux boxes, and I have done a lot of developement with X-Windows, Motif, GNU, and all the GNU Toys. I started learning Windows 3.0 and worked my way through all the other MS developement tool kits starting with the C/C++ 7.0 compiler and Borland Compilers. I have been working in both Unix and Windows for the Last 10 years. Windows is a better software system. Linux is free and the only use I have had for it in the last four years was to set up a cheap router using an obsolete scrap computer. Unix does very little that is usefull to the average computer user. Unix is not a new technology. Linux is just a free rewrite of the Unix system. Where are the application packages for Linux? They are mostly a pile of student written science fair experiments scattered on a large number of obscure web site. So you can download the source to LaTex. Who cares? People buy computers to run applications. They don't buy computers to run compilers, although Microsoft does make better compilers for x86 than GNU. MSDN is a better development environment than GNU, Better software tools create better software. People don't care how well an operating system works if there are no useful applications. So how is Richard Stallman doing with his Hurd Operating system? The entire GNU-Linux system is nothing more than a science fair experiment run by various techno-geeks. As a science fair experiment GNU-Linux has its uses. I have looked very deeply into both systems and Microsoft has the better system. Regards, Charles -- === Medi Montaseri, [EMAIL PROTECTED], 408-450-7114 Prepass Inc, IT/Operations, Software Eng. ===
RE: FYI: Windows is better
Title: RE: FYI: Windows is better * Mark Douglas [EMAIL PROTECTED] [010705 14:52]: Ok. So we have: * 12 lines of signature Erm, 3 lines. * full quote (do you read from bottom to top? No? THEN WHY THE FUCK DO YOU NOT SET UP YOUR TRASHTOY CORRECTLY?) Sorry, do you like how I'm doing it now? * no quote string * no attribution line Corrected. * HTML to bloat your crap mail even more Fixed. * fucked up line width Due to above, fixed. Excellent analogy!! I love it! It's bullshit. And this is a technical mailing list. Your emotions are of no interest whatsoever. Go hug a tree, luser. My emotions are of no interest, and yet you feel free to bitch about the way I have my mail client setup. I find this to be a contradiction. Anyway, I don't want to plug up this beloved technical mailing list of yours with any more off topic garbage. 'Nuf said.
RE: Alter bounce messages?
Title: RE: Alter bounce messages? I'm looking for this same information, and although it has been answered earlier (edit the qmail-send.c file), I'll state what problem I'm trying to solve. I have a lot of users who are not English speaking, and I get a lot of replies to my bounce messages from them to MAILER-DAEMON asking what the hell the message says. I'd like to include a translated version of the message in the bounce message, as well as a note saying that it's not required for them to reply to the message (I get a lot of thanks for telling me replies, as well). If I leave the original bounce message in place, and just translate it and add my comments at the bottom, would that still be acceptable for QSBMF? Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time! -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 9:49 To: [EMAIL PROTECTED] Subject: Re: Alter bounce messages? Amanda [EMAIL PROTECTED] wrote: In particular I'd like to terminate with extreme prejudice the message that says something to the effect of, Hi. This is the [...] Please don't. That message has a very specific format, to allow it to be recognized and parsed automatically. The format is documented at: http://cr.yp.to/proto/qsbmf.txt As Russell says, What problem are you trying to solve? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ ---
RE: Alter bounce messages?
Title: RE: Alter bounce messages? peter green [EMAIL PROTECTED] wrote: Please don't. That message has a very specific format, to allow it to be recognized and parsed automatically. The format is documented at: http://cr.yp.to/proto/qsbmf.txt What is actually parsing that format these days? I can appreciate forward-looking policies like qsbmf, but that doesn't exactly fly with customers all of the time. What can I point to as a definite reason (*now*) to keep qsbmf? Peter van Dijk mentioned that ezmlm parses QSBMF. However, the bigger question is What is the the definite reason (*now*) for _not_ keeping QSBMF? I have seen lots of people who say they want to change the content of qmail's bounce messages, but no one has ever been able to give a good reason why. The current message is informative, clear, and concise. What else could you want? Charles -- See my earlier reply to this thread as to why I would like to change the message. In order to provide my customers with the best service possible, I consider those very good reasons to change the message. Mark
qmailanalog usage
Title: qmailanalog usage I'm trying to figure out how I should get the stats I want out of qmailanalog, along with some other things I'd like to do. My main issue is, if I wanted to do a daily log rotation, would it be feasible to do the following (using multilog): Set my logfile size to 100MB; at end of day, have a cron job run that copies the current file to another, dated file; echo /var/log/qmail/current to empty out the log file and start fresh. I realize it's not pretty, but the real issue is, would it cause problems? Thanks, Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time!
Re: qmail-remote (cry wolf?)
On Sun, Jun 17, 2001 at 08:56:13PM +0100, James R Grinter wrote: % I think it isn't relevant. qmail-remote doesn't seem to use select, % or at least it's nowhere in the path where my qmail-remote wedges. Go look at timeoutread(), which *is* in your path. The select is in the line right before where you wedge. % As to different OS behaviour, Solaris 2.6 (and 7) both say: [Man page claims it doesn't do this.] % whereas SunOS 4.1.4 (my usual 'old bsd system' benchmark) says: [Man page unclear.] % and I can tell you that I've not seen the problem happen with % qmail-remote on SunOS 4.1.4. Well, I don't necessarily trust man pages to tell the truth, especially if this was added accidentally (i.e. if it's a bug). And I still haven't seen anything to really convince me that any OS actually does this. I've only seen that a few people think some do, that it could easily happen as a bug, and that it could explain the hung qmail-remotes. And it's easily fixed if it is the problem. In other words, I'm not saying that this is the cause, only that it's possible. % Indeed, I think DJB's code (and most % other people's) compensates for both behaviours by setting the % necessary FD's each time anyway. It doesn't. (Don't know about other people's.) It assumes that the fd_sets will be cleared on timeout. Setting the fd_sets each time is always necessary and doesn't protect against this issue, anyway. In any case, since I did see (one) stuck process recently I built myself a test to see if I could reproduce it. I wasn't. At least on a RedHat linux 2.2.19-6.2.1 or -6.2.1smp, it looks like select acts sanely on a timeout, at least some of the time. I also put a debugging version of qmail-remote on my system, so if it ever decides to hang again I can fling gdb at it. Mark
Re: qmail-remote (cry wolf?)
On Mon, Jun 18, 2001 at 11:20:36PM -0400, Troy Settle wrote:
% How would I need to go about building a dubug version of qmail-remote?
I set conf-cc and conf-ld to 'gcc -g', edited timeoutread.c slightly
to save the return value of the select in a variable, then built
qmail-remote and put it in place of the live one. I'll attach a patch
matching what I did to timeoutread.c.
% Also, how to terminate the process so that I can 'fling' gdb at it?
I wasn't planning on terminating it. Rather I was thinking of using
gdb's attach command to take over the process, and then start
examining variables. Mostly, I was going to wing it.
I expect the full attachment sequence to look something like this:
(gdb) attach pid-of-stuck-qmail-remote
(gdb) symbol-file /var/qmail/bin/qmail-remote
(gdb) directory path-to-qmail-source-with-modified-timeoutread.c
(gdb) bt
(gdb) up -- repeat until at timeoutread() stack frame
(gdb) p res
(gdb) p fd
(gdb) p rfds -- or something like that
% With a little I can probably have output from gdb within a couple hours.
Good luck, then.
Mark
--- timeoutread.c Mon Jun 15 03:53:16 1998
+++ timeoutread.c Mon Jun 18 22:23:24 2001
@@ -7,6 +7,7 @@
{
fd_set rfds;
struct timeval tv;
+ int res;
tv.tv_sec = t;
tv.tv_usec = 0;
@@ -14,7 +15,8 @@
FD_ZERO(rfds);
FD_SET(fd,rfds);
- if (select(fd + 1,rfds,(fd_set *) 0,(fd_set *) 0,tv) == -1) return -1;
+ res = select(fd + 1,rfds,(fd_set *) 0,(fd_set *) 0,tv);
+ if (res == -1) return -1;
if (FD_ISSET(fd,rfds)) return read(fd,buf,len);
errno = error_timeout;
Re: qmail-remote (cry wolf?)
I came across the following, which *might* explain some of these deadlocking problems: http://kt.zork.net/kernel-traffic/kt20010611_121.html#6 [Summary: Some systems leave the fd_sets alone when select times out.] If I read this right, timeoutconn/read/write (and anything else that uses select) have to check for a result of 0 explicitly to be completely portable. Even if an OS doesn't do this intentionally, it's quite easy to see someone forgetting to clear the fd_sets on a timeout by accident, so some defensive coding against the problem (explicitly checking for a result of 0) may be worthwhile. Or this may just be a red herring... Mark N.B. Although someone claimed to have seen a BSD man page reporting that it wouldn't clear the fd_sets on a timeout, I was unable to find any evidence of such a thing with Google. And at least one standard (Single UNIX Specification v2) has forbidden this kind of weirdness. P.S. And I just found one of these bloody hung qmail-remotes on one of my systems!@#$! Stuck in read of fd 3; directed at email.com (who clearly have no clue how to set up DNS records for email, and are down anyway). Redhat Linux kernel 2.2.19-6.2.1smp.
Re: Suspending an POP3 account.
On Mon, Jun 11, 2001 at 05:58:19PM -0400, Reid Sutherland allegedly wrote: Hi, I'd like to be able to suspend a POP3 account without changing the client's password. Is there anything I can do to the home directory or Maildir to accomplish this? What I'm doing the for incoming mail is a simple .qmail file that creates a message and spits back an error saying the account is suspended (sort of like a vacation program). So I want to make sure the .qmail is usable but also prevent the client from logging in via POP3. I've attempted changing the ownership of the Maildir to someone else, but that didn't work and only defered incoming messages. Do you still want incoming mail delivered for such accounts? If so, the easiest thing to do is change the name of Maildir to, say, Maildir.suspended and then in the .qmail file go: ./Maildir.suspended/ | bouncesaying Account suspended When they become active again, remove the .qmail file and rename Maildir.suspended back to Maildir. Don't forget the chmod +t $HOME to defer any deliveries while you are making these changes. If you do not want the incoming mail delivered, then a permission change plus a .qmail file that only generates a bounce message is fine. Mind you, the POP error message they get wont be very friendly and maybe that's the intent. If it's not, you could additionally create a hand-crafted Maildir that has just one message in it regarding the suspension. Regards.
Re: Multiple recipients to remote domain
On Mon, Jun 11, 2001 at 05:12:44PM -0600, Bruce Guenter allegedly wrote: On Mon, Jun 11, 2001 at 12:09:40PM -0600, Roger Walker wrote: Thanks, Peter and Charles. Looks like I'll have to script a solution that telnets to port 25 on the remote host and issues 10,000+ (650,000+ actually) rcpt to: lines. You can also use qmail-remote manually to do this. And Net::SMTP from your local CPAN makes life pretty easy if you want to have a more programmatic interface. Regards.
Re: qmail-remote (cry wolf?)
Is it possible that some external devices s.a. switch/router/firewall/anything could be causing this problem? Yes, very possble. Some firewalls do transparent SMTP or POP proxying, and there have been many bugs in such implementations. No. Regardless of what the other end does, a conforming OS should not wedge qmail-remote forever. Why do people keep suggesting this? You have three choices: 1. Show the bug in the code containing the select() and read() 2. Show an interpretation error regarding the semantics of read() and select() If you can do either of those, we can conclude that qmail-remote is coded incorrectly and needs fixing. If you can do neither of these, then this leaves you with the inescapable conclusion that qmail-remote *is* playing by the rules, in which case you are left with the only alternative: 3. the other side of the C code is not playing by the rules: ie a bug in the compiler, libraries or OS. I will note that no one has done 1 or 2 yet, so that leaves 3. Regards.
Re: qmail-remote (cry wolf?)
On Fri, Jun 08, 2001 at 08:11:21PM -0400, Yevgeniy Miretskiy allegedly wrote: On Fri, Jun 08, 2001 at 09:47:16PM +, Mark wrote: Then it's an OS bug. qmail-remote only gets to the read() if the OS (via select() ) says that the read will not block. Ergo, the OS is lying. If it's OS bug, anybody heard/knows of such severe network related bug in RedHat 6.2? What about FreeBSD 4.2 (I believe somebody reported problem with FreeBSD as well)??? What are the chances of _such_ bug in _both_ OSes? I'd like to mention, that I ran qmail of FreeBSD (starting from 3.x all the way to latest) for couple years and _never_ observed this behaviour on FreeBSD. I ran it on Solaris 2.5/2.6 for years and did experience this sort of behaviour. It went away on 2.8. So what? No one has shown that qmail-remote is doing anything wrong. If it's not doing anything wrong, them maybe the problem is somewhere else? Conversely, every reading of the code in question suggests that qmail-remote is doing everything right. The fact that this problem occurs on at least two OSes simply suggests to me that the TCP/IP interaction is a boundary condition perhaps triggered by distance connections and perhaps also by an uncommon remote TCP/IP stack. Regardless of which, if an OS renegs on the fd-will-not-block promise, then it can *only* be an OS bug. Regards.
Re: qmail-remote (cry wolf?)
As far as I can tell, this is a problem between qmail-remote and the kernel. Correct. This is happening on multiple operating systems, so that leads me to believe that this is not an OS bug. But many OSes share TCP/IP implementations or mis-interpretations of the protocol. Many coders of TCP/IP stacks look at other implementations to work out what to do. There is a *lot* of commonality between OSes in this regard. Eg, the Linux crowd and the FreeBSD crowd reguarly refer to each others implementations to decide how to do something (or not do something as the case may be). ** To find out a bit more about what a stuck qmail-remote is doing, you ** may want to ktrace it and show us the output. Find the process id of the ** stuck qmail-remote and then as root go: ktrace -p thepid ** ** Leave that running for at least an hour and show us the output. Yes, I ** mean at least an hour. ** Ok, I meant to come back in an hour and stop the trace, but after running ktrace for 9 hours (while I slept), the resulting ktrace.out file is exactly 0 bytes in length. Would you like me to send a copy? g It's a bummer that ktrace is like that on FreeBSD. It doesn't show the *current* system call that the process is sitting on. Conversely, truss on Solaris does this nicely... You can conclude though that qmail-remote wasn't sitting on the select() as that has a timeout and should show the system calls associated with the reading loop. If it's not sitting on the select() what is it sitting on? If it's the read() well, how could that be if select() said the read would not block? Regards.
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 09:05:00AM -0700, Greg White allegedly wrote: I think we may have red-herringed on the OS thing -- if RH6.2, as deployed, had this sort of problem, I think we would have run across it before this, no? The inclusion of a FreeBSD-4.2-STABLE in the mix seems to nix a RH specific bug as well (althought it obviously does not rule it out entirely*). Perhaps we're overlooking some other, more subtle commonality between these four setups? Indeed. Using commonality to solve a problem is a fine technique. However the underlying assumption is that it is a single problem that is being solved here. We have no certainty of that, all we do have is a single *symptom* - qmail-remote wedges on some systems, on some occassions. If it is a single problem, here are some commonalities that might be explored: 1. Bug in qmail-remote 2. Common compiler (think optimization error) 3. Common clib error (think semantic error or bug) 4. Common OS (think semantic error or bug) 5. Common TCP/IP stack 6. Common network interface code (perhaps all derived from a vendor reference implementation) All of which *may* only be triggered by a certain set of TCP/IP events initiated from the peer end. Indeed the peer may be an uncommon OS/TCP/IP combo which reduces the occurence of this problem to isolated situations. And you can be very certain that this is a very very rare event. Just consider how many invocations of qmail-remote have successfully completed in the last 3 years on many many thousands of OSes in many thousands of locations around the world. What does that mean? It's probably a tough problem to nail down without access to the interaction history between all of the above components. Regards.
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 03:11:59PM -0400, Russell Nelson allegedly wrote:
Greg White writes:
I think we may have red-herringed on the OS thing -- if RH6.2, as
deployed, had this sort of problem, I think we would have run across it
before this, no?
Hmmm I wonder. I could do a denial of service attack on
qmail-remote by receiving email very, very slowly,
You'd also have to set the TCP/IP receive window size down, otherwise
you may think you're only receiving at one byte every, say, 20
minutes, but in fact your TCP/IP stack got a window full of data at
one time.
But yes, you could slow it down considerably and if you got to the
extreme limit of 20 minutes per byte, a 1M email will take about 9
months...
It sure is the case that some sort of gross delivery timer makes sense
and it would work around the problem that initiated this thread...
and by sending
email to a server which is guaranteed to be received and guaranteed to
bounce. qmail doesn't keep track of very slow hosts, but only hosts
that time out.
Of course it has to be your server that accepts the traffic slowly so
it's a DOS on yourself at the same time. Not the typical MO for a
successful DOS.
This is only proof of concepts, but to implement a gross timer, you
might use this program as a wrapper to qmail-remote (which of course
you move to qmail-remote.real):
main(int argc, char **argv)
{
alarm(5*60*60); /* Max of five hours for a remote delivery */
execv(/var/qmail/bin/qmail-remote.real, argv);
_exit(1);
}
This wrapper gives qmail-remote an arbitrary 5 hours to make a
delivery at which point qmail-remote gets a SIGALRM which it happens
not to have registered a handler for and thus the OS takes the default
action which is to terminate the process.
Regards.
Re: qmail-remote (cry wolf?)
Perhaps something like a maxlifetime control file for qmail-remote and (Serendipity strikes again - I just posted sample code for this). qmail-smtpd? At process startup, set an alarm for X seconds -- if the ALRM is received, abort the connection as gracefully as possible (i.e. try to send RSET and QUIT in qmail-remote, issue a 4xx error in qmail-smtpd) but quit regardless of whether these attempts to quit gracefully are successful or not. Why bother with a graceful exit? You'd have to set yet another alarm for the (likely) case that your graceful exit fails. That's seems like unnecessary complexity for a connection that is almost certainly dead. Regards.
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: It's a bummer that ktrace is like that on FreeBSD. It doesn't show the *current* system call that the process is sitting on. Conversely, truss on Solaris does this nicely... But FreeBSD does have a (procfs-based) truss. Right. But it suffers from the same problem that ktrace does in that it starts with the next system call, not the current one. Leastwise it does on a 4.3 I have access to, do you get something different? Regards.
Re: qmail-remote (cry wolf?)
processed those 1500 messages in less than 30 minutes. However, it left behind another handfull of stuck qmail-remote processes. Other messages were undeliverable and left in the queue, and still others were sent back to sender with permanent errors. What do you mean by stuck? Do you mean they *never* go away - even after a day or two? As others have pointed out, a slow delivery can take a long, long time. That's not necessarily a problem, that's just the way it is. To find out a bit more about what a stuck qmail-remote is doing, you may want to ktrace it and show us the output. Find the process id of the stuck qmail-remote and then as root go: ktrace -p thepid Leave that running for at least an hour and show us the output. Yes, I mean at least an hour. Regards.
Re: qmail-remote (cry wolf?)
On Fri, Jun 08, 2001 at 03:51:18PM -0400, Yevgeniy Miretskiy allegedly wrote: One more time, I did tcpdump and strace on stuck qmail-remote for over an hour. strace shows that qmail-remote is stuck on: 'read(3', and tcpdump shows that nothing comes in. One more time. Then it's an OS bug. qmail-remote only gets to the read() if the OS (via select() ) says that the read will not block. Ergo, the OS is lying. Regards.
RE: ACL
I would think the easiest way to do this would be: a) make a group that the three accounts are part of (if this isn't already in place) b) chgrp the mailbox so that all accounts have access to it c) set the MAIL environment variable for all the accounts to point to that mailbox voila, finished. However, I haven't done this before and it's just a guess. Can anyone on the list confirm this? Or have a better way? Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time! -Original Message-From: marco1 [mailto:[EMAIL PROTECTED]]Sent: Thursday, June 07, 2001 11:49To: [EMAIL PROTECTED]Subject: ACL I'm using Qmail + Vpomail + Courier-Imap and would like to enable Acl on mailboxes. I nedd to enable tree different users(accounts) to gain access toa single mailbox. How can i do that? Thanks, Marco
Re: qmail-remote (cry wolf?)
On Thu, Jun 07, 2001 at 07:36:53PM +0200, Jörgen Persson allegedly wrote: Sorry, but I'm not all comfortable with this... There's been 4 similar reports of qmail-remote not behaving properly to this list during the last month. http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg00558.html http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg01332.html http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/06/msg00283.html http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/06/msg00426.html We still haven't been able to help any of them... This doesn't look like a coincidence to me since two of the reports concerned the same recipient server (outblaze.com). Unfortunately it seems related to network programming, which I know very little about. Any other thoughts about this? If it's an unpatched qmail-remote, then remain suspicious of some OS bug. I spent a long time looking at qmail-remote when a similar problem occured on a Solaris 2.5 system (or maybe 2.6, I forget now). Here are the two lines of code: if (select(fd + 1,rfds,(fd_set *) 0,(fd_set *) 0,tv) == -1) return -1; if (FD_ISSET(fd,rfds)) return read(fd,buf,len); That's about as simple as you can get! I don't see any way that the read() call will occur without select() returning the fdset bit. So, if select() says that a read can occur, then the only reason that the read() can then block is if the OS is lying... So, it's kinda hard to see a problem with qmail-remote here. Do OSes ever get it wrong? Sure. If this is a relatively widespread problem, then you might want to put an alarm() handler into qmail-remote, but if you can't rely on the OS, all bets are really off, right? Regards.
Re: qmail-remote (cry wolf?)
What are the probabilities of the Sendmail server being the one causing the problems? What if the mail admin of mg.hk5.outblaze.com has used some sort of patch that is causing qmail-remote's to hang? Has anyone communicated with outblaze.com's postmaster? There is nothing a remote system can do that will hang qmail-remote on a correctly functioning OS. If the local TCP stack has accepted data and indicated available via the select() return, then the remote system has no further say as the read() only fetches the data previously received. I'll bet it's an OS bug - most likely in the TCP stack. Eg, it may be that the local TCP stack - in some circumstance - discards unread data, *then* marks the local socket as unreadable, rather than around the other way. That sort of window would wedge the select/read sequence in qmail-remote. Regards.
Re: qmail-remote (cry wolf?)
On Thu, Jun 07, 2001 at 04:39:25PM -0700, David Lowe allegedly wrote: Mark et. al. - It *is* possible, though, for qmail-remote to move slowly enough that it appears to hang (yes, even for hours or days). timeoutremote applies to every read() and write() - in the very worst case, each of these system calls might move only a single byte. Consider a 5000 byte message and a timeoutremote set to 1200 seconds (the default). The worst case just for sending the data alone - not including smtp overhead and reading responses from the remote server - is almost 70 days (1200 * 5000 / 60 / 60 / 24 ~= 69.44). Granted, this is extremely unlikely, but you get the idea - some scenarios can cause qmail-remote to move extraordinarily slowly, while still functioning correctly - that is, within the limits imposed by timeoutremote. Right. But in that case, the syscall trace would show qmail-remote blocked on the select() not the read(). The read() only gets executed if select() says there is data in which case the read does not block and the code immediately loops back on the select() again. As I recall, the original syscal trace showed qmail-remote blocked on the read(). Regards.
Re: ANNOUNCE: qmail now works with the diet libc
On Wed, Jun 06, 2001 at 10:54:33PM +0200, Felix von Leitner allegedly wrote: I recently did a few updates to my diet libc (http://www.fefe.de/dietlibc/) and it can now compile and link qmail. Since the diet libc can also compile and link openssl, the STARTTLS patch also works. What's the difference, you ask? This ps listing is on a box with qmail dynamically linked against the glibc: USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND qmaill 29527 0.0 0.1 1228 224 ? S N Mar 12 0:16 splogger qmail qmailq 29543 0.0 0.0 1208 104 ? S N Mar 12 0:03 qmail-clean qmailr 29529 0.0 0.1 1216 176 ? S N Mar 12 0:00 qmail-rspawn qmails 29521 0.0 0.1 1260 172 ? S N Mar 12 0:22 qmail-send root 29528 0.0 0.0 121680 ? S N Mar 12 0:08 qmail-lspawn ./Maildir/ Please note the drastically reduced memory requirements. As you can see, the process are running for many days on the first box, so unused memory is already swapped out. Not so on the second box. Why is this significant? Because it allows a much larger concurrency on the same hardware. More POP3 users, more concurrent local and remote deliveries, more incoming SMTP connections. Er, what's the chance of have a ps which compares qmail-popd, qmail-smtp and qmail-remote then? Kinda relevant doncha think? Regards.
qmail troubleshooting
Title: qmail troubleshooting Hi, I'm having some issues with my qmail server. :) However, instead of dumping all my problems on this list, I think it would be more beneficial for me to do my own troubleshooting so I can learn the ins-and-outs of qmail. Are there any good web-pages or anything dedicated to common/not-so-common problems encountered with qmail, and ways to troubleshoot those problems? For those of you who are curious, my current problem is that my queue has come to a crashing halt. I had about 15000 messages in it, and I was doing some kernel tweaks and the big concurrency patch to make it push 500 messages at a time. It ate through the 15000 messages in about 45 seconds, but left me with about 370 messages in the queue. Ever so slowly those messages have trickled out over the past 16 hours, but it's only sent about another 150 messages, leaving about 220 remaining. Now, my suspicion is that these are deliveries that failed the first time and have been set to retry again at a later date. However, I can't find a way of confirming this, apart from the deferred statements in the log files. I assume the deferred statement is confirmation of what I suspect. What I'm wondering, is if there's a way to reset the deferred status of these messages and try sending them all out again? Or is there a way of monitoring the queue (other than qmail-qstat) ? I've tried installing qmailanalog, but once again, I'm having problems with Solaris 8. (qmailanalog simply complains it 'cannot execute'). So, a breakdown of what I'm looking for: 1) A website detailing different troubleshooting situations for qmail 2) A way to look at the status of the queue, other than qmail-qstat 3) A way to force all messages in the queue to send again immediately 4) A statistics monitoring program that will work on Solaris 8(sparc), or a way to make qmailanalog work on Sol8Sparc Thanks, Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time!
RE: qmail troubleshooting
Title: RE: qmail troubleshooting Excellent, you show initiative. Most good qmail resources can be found by either following links from qmail.org, or by doing a Google search. qmail.org is down for me presently. Anybody else having this problem? As for google, I'm all over that all the time. :) Thanks, Mark
Re: qmail troubleshooting
On Tue, Jun 05, 2001 at 12:05:57PM -0500, Virginia Chism allegedly wrote: I am still a newbie and unable to find a lot of things I think my qmail should have. Some things I can find, but not where they should be. At any rate, when suggestions come up as quoted below, I try them out and often discover hidden elements. When I tried this one, `find /var/qmail/queue/remote -type f` ? the returned message was: /var/qmail/queue/remote/0/277955: Permission denied. I guess my question now is, what permission is higher than root? Nothing on most unixen unless /var/qmail happens to be on an NFS mount. If it is, that is a problem as it should be on a local disk. Regards.
Re: ORBS, and RFC-ignorant blacklists
On Mon, Jun 04, 2001 at 09:17:50AM +0200, Piotr Kasztelowicz allegedly wrote: On Sun, 3 Jun 2001, Peter van Dijk wrote: Furthermore, Alan Brown's activities are not illegal - the ORBS relaytester runs in The Netherlands, where this is not illegal by any law. Maybe in Netherlands is not illegal, but in Netherlands even euthanasia is legal by any law, in other countries not! The tester is in Netherlands but it otucomes follow results in other countries, where performing such lists and testing, which seeks the vulnerabilities in servers and helps hackers at attacks, is illegal. From corespondence on this list can be considered, that in US, NZ is illegal, in my country (Poland) too. So, if Netherland will be right to others, probably shall give this same injunction as NZ High Court - this want only a lot time I'm confused. Isn't the use of ORBS entirely voluntary? I don't see how any site on the Internet is obliged to accept any traffic at all. So, if a site chooses to reject traffic based on a list - regardless of how flawed it may be - what's the big deal? But I fail see the relevance to qmail... Regards.
big-concurrency patch
Title: big-concurrency patch I'm having problems applying this patch. I can't find any documentation for it, and the patch file itself seems to be rather chopped up. I did my best to put it into appropriate patch files, but when I run patch -p1 big-concurrency.patch it asks me what file I want to patch. I'm not a programmer, and have no idea what files need to be patched. I don't want to screw anything up (although I have made a backup of my current source directory). Can anybody point me in the right direction? This is the big-concurrency.patch I'm using: http://www.glasswings.com.au/qmail/big-concurrency.patch Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time!
RE: big-concurrency patch
Title: RE: big-concurrency patch I've tried all kinds of -p options, and left it out, and it doesn't help. Also, as for it not being the standard big-concurrency patch, would you tell me which one is? Even the one right on qmail's home site is that same patch muddled in with the e-mail. Thanks, Mark -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 15:04 To: '[EMAIL PROTECTED]' Subject: Re: big-concurrency patch Mark Douglas [EMAIL PROTECTED] wrote: I'm having problems applying this patch. I can't find any documentation for it, and the patch file itself seems to be rather chopped up. I did my best to put it into appropriate patch files, but when I run patch -p1 big-concurrency.patch it asks me what file I want to patch. That's a clue that you're using the wrong argument to the -p option. However, it could have another cause -- the patch you pointed to isn't the standard big-concurrency one; the message above the patch states: This is the patch that I use at suse.com. We do almost 1 million messages a day with this patch and concurrencyremote set to 400. This patch comes with the standard disclaimer. No warranty, it may not work, etc. But it works for me :) It's also not pretty. It's against qmail-1.03+verh-0.02 (the ezmlm patch l and h patch). So the offsets may be off a little bit. So it's not against standard qmail; it's against qmail 1.03 after the verh patch has been applied. If you're not using that patch as well, it's not surprising it won't apply cleanly. Try against a vanilla qmail 1.03 source tree. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
RE: big-concurrency patch
Title: RE: big-concurrency patch No, I can make this patch cleanly on a linux based system no problem, but when I try the same approach on the solaris system, it doesn't work. Was the test you're doing from a solaris system? At this point I'm just kind of wondering what the problem is with the solaris system, because I took the patched version from the linux box and moved it to the solaris one and recompiled without any problems. Thanks, Mark -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 16:27 To: '[EMAIL PROTECTED]' Subject: Re: big-concurrency patch Mark Douglas [EMAIL PROTECTED] wrote: I've tried all kinds of -p options, and left it out, and it doesn't help. Also, as for it not being the standard big-concurrency patch, would you tell me which one is? Even the one right on qmail's home site is that same patch muddled in with the e-mail. I tried it here, and it applies cleanly: [charlesc@charon qmail-test]$ wget http://www.qmail.org/big-concurrency.patch --14:19:19-- http://www.qmail.org:80/big-concurrency.patch = `big-concurrency.patch' Connecting to www.qmail.org:80... connected! HTTP request sent, awaiting response... 200 OK Length: 9,331 [text/plain] 0K - . [100%] 14:19:24 (9.19 KB/s) - `big-concurrency.patch' saved [9331/9331] [charlesc@charon qmail-test]$ ls -l -rw-r--r-- 1 charlesc qcc 9331 Aug 12 1999 big-concurrency.patch [charlesc@charon qmail-test]$ tar xzf qmail-1.03.tar.gz [charlesc@charon qmail-test]$ cd qmail-1.03 [charlesc@charon qmail-1.03]$ cat ../big-concurrency.patch | patch -p1 patching file `chkspawn.c' patching file `conf-spawn' patching file `qmail-send.c' patching file `spawn.c' [charlesc@charon qmail-1.03]$ You must be using patch incorrectly. For this patch, you should be in the unpacked qmail source tree top directory, and strip one directory component (-p1). Perhaps you were in the wrong directory? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: big-concurrency patch
On Mon, Jun 04, 2001 at 05:14:00PM -0400, Mark Douglas allegedly wrote: No, I can make this patch cleanly on a linux based system no problem, but when I try the same approach on the solaris system, it doesn't work. Was the test you're doing from a solaris system? At this point I'm just kind of wondering what the problem is with the solaris system, because I took the patched version from the linux box and moved it to the solaris one and recompiled without any problems. Solaris has it's own patch program. Try installing and using the real one. Regards.
Re: What about www.mail-abuse.org ?
On Sun, Jun 03, 2001 at 09:04:22PM -0700, Tupshin Harper allegedly wrote: My test of your server indicates that you appropriately block relaying. (Let me say beforehand that I don't know anything about mail-abuse.org and whether they do or do not have this address listed, or indeed whether they have this address listed for valid reasons). The fact that some IPs are not accepted for relaying does not mean that all are. It may well be, for example, that the IP in question relays mail from, say, all 202. addresses or all 202.96 addresses. Of course this is not a qmail related issue unless the original poster has a problem understanding relay protection with qmail and starts with a posting of his tcpserver rules and his expectations of what they do. Regards. -Tupshin - Original Message - From: daiyuwen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 03, 2001 9:11 PM Subject: What about www.mail-abuse.org ? Hi, Dear All Somebody are talking about www.orbs.org. What about www.mail-abuse.org? I think they're abusing their influence. Many sites are using their blacklist. So they should be very responsible for every IP address their list. For my instance, my server is on the RSS list because it WAS an open-relay server. Then I fixed the problem and sent a removal request. But mail-abuse.org said I blocked their mail server (I didn't. I don't know why). Now they even refuse my removal request on the web. According their order, I had to mail to [EMAIL PROTECTED], explaining why I blocked their server. But I just got an auto-relay that said I should submit removal request on the web. Dead loop :-( Any body kind enough to test if my server is third-party relay? Its IP address is 202.96.230.197 Best regards, Dai Yuwen __ === ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn) ʹÓÃÊÖ»ú¶ÌÐÅ¡°ÓʼþÌáÐÑ¡±¹¦ÄÜ£¬ËæʱÁ˽âµÄÊÕÐÂÐÅÇé¿ö£¡ (http://sms.sina.com.cn/docs/sina_mailalert.html) ¶©ÔÄÊÖ»ú¶ÌÐŶ¥¼¶ÐÂÎÅÿÌìµÃпîÊÖ»ú´ó½±£¡ (http://dailynews.sina.com.cn/c/266499.html)
Re: qmail on SCO OpenServer
On Mon, Jun 04, 2001 at 02:16:20PM +1000, Jason Heskett allegedly wrote: Hi there, I am probably opening a long-running topic here, but here goes... I have just successfully compiled qmail on SCO OpenServer. However, it seems that my outgoing mail queue is getting stuck. Is that true for all outgoing mail or just some? The log includes, Connected_to_..._but_connection_died._(#4.4.2)/ Running a ps shows qmail-remote sitting there, trying to deliver the queue. Does SCO has a truss or strace or some similar system call trace? If so, attach to the qmail-remote and show us the output. Yo may also want to get a tcpdump/snoop of the tcp traffic. Local deliveries work just fine. I know similar messages have been posted to the list, and I apologise for the duplication, You'll also note that SCO in general is not well loved/supported by djbware. The problem seems to be that the tcp/ip stack sucks - to use a technical term. Before you say anything I can't move to Linux just yet... That still leaves any of the BSD variants then : Regards.
Re: do I need to log
On Tue, Jun 05, 2001 at 02:28:31AM +, NewBiePortal allegedly wrote: Hi I'm wondering, do I really need to log anything. Is this must or is it extra for debugging purpose. I just feel that there would be much improvement with the sending mail if my cpu did not have to bother with logging every email that's leaving my mailer. I mean I have millions of junk emails which none of them are important at all. I'm kinda of newbie but can someone confirm that It's okay to get rip of qmail-smtpd/log/run It's entirely up to you. I wish I was lucky enough to work on an email system that has millions of junk emails and which required no analysis or problem diagnosis or anything, ever! Just remember most problems have to be looked back at which is only possible with some sort of log. Of course the fact that your system does have millions of junk emails suggests that something is very wrong in the first instant - something like being abused as an open-relay that a log might well identify.. But as I say, it's your server. There is the final point that you don't know what your logging really costs. How much of a bother is it to your CPU? Have you measured it or are you speculating? Is the bother greater than that or the millions of junk emails that you might be able to eliminate? Regards.
Re: Oops,I guess Sendmail wasn't secure after all...
On Sat, Jun 02, 2001 at 05:20:01PM +0200, Boris allegedly wrote: Hello Johan, JA Not quite. More like someone inspects your free car and finds a button JA that can make it explode. Maybe he pushes the button, maybe not. Maybe he JA pushes the button on someone else's car. Are you willing to take that JA risk? I can imagine two situations where that would be the case: either Well, there is no button with a text like press me here -) for the public. Of course there is, silly. Tell us, your mail progam seems to be The Bat! (v1.48f) Personal - did you write this program from scratch yourself or did you simply click a few buttons and install the work of someone else? Now, what do you think most script kiddies do? They don't scour the code for exploits as you imply with there is no button. They simply download the hard work of one or two people and install the pre-built button. It's trivial. So, press me here is as far away as a download. You're not seriously suggesting this is a serious secruity barrier are you? If we are talking about the security of a product, we have several things to take a look at. Internal security (a mailserver-only solution, mailserver+webserver, n mailservers, persons who access the mail queue as root). External security. Buffer overflows, chroot problems, jail problems, password problems. Design specific topics, what is secure, what is not secure, what can be implemented, what is not secure. You are obscuring definition with implementation (and jargon for that matter). As root i can read all the messages in clear text, sendmail or qmail - a security risk? An attack to privacy? Or just a design problem? Or is it not a design problem, its just normal? Security is relative. No it's not. You're futzing and confused. This is real simple. The security of a product is defined as a set of claims about providing certain protection. A security problem exists when the product does not meet a stated claim. Eg, qmail never claimed to protect clear text messages on disk from root, so why did you bring it up? However, both qmail explicitly and sendmail (somewhat less explicitly) do make claims about protecting against a user gaining elevated priviledges. This thread started from yet another alert about being able to corrupt the memory of sendmail. Corrupting memory is a tried and true method of gaining elevated priviledges and time and again this method *has* been used to gain elevated priviledges via sendmail. In other words, sendmail has repeatedly failed to live up to it's security claims and it looks like this current announcement may be just another example. So, inspite of what you say, you do not have to have several things to take a look at and you don't have to understand sentences full of buzzwords like chroot problems and jail problems... You simply ask the question has sendmail failed to live up to it's security claims. The answer is a repeated yes bordering on recidivism and no amount of obfuscation by you will change that fact. Your sole defense is that sendmail doesn't make such security claims explicitly and thus people are silly to infer such security. This is indeed a strong argument. Regards.
Re: expn
On Sat, Jun 02, 2001 at 09:02:08AM -0700, Rob Genovesi allegedly wrote: Hello List, Is this expn (expand) command completely disabled in Qmail (1.03)? If so, are there any patches out there to enable expn from certain hosts on a Qmail server? It's not disabled as such, it's merely not implemented in the standard product for a variety of reasons - one of which is that the design does not lend itself readily to expn (but there are good privacy reasons too). Having said that, there are patches to do this and a search of the archives should reveal where they are. I'm trying to find a solution for a remote product to find the pop3 account behind a catch-all virtual account and a limited-access expn would certainly do the trick. It sounds like you'll be adding non-standard code to both ends of this solution so why not do something more specific that doesn't involve patching qmail, such as a protected access web page? Or a protected access finger port? Or a periodic rsync of the user list? Regards.
Re: Oops,I guess Sendmail wasn't secure after all...
On Sat, Jun 02, 2001 at 05:01:57AM +0200, Boris allegedly wrote: bugs are fixed fast. Its just some C-Code, everyone knows this. This is a troll, right? I have a lock on my front door that I know can be opened with a paperclip, but heck, those nice people who make the locks will supply me with a new lock soon, so what's the problem? When I was using sendmail on my FreeBSD Server, it has never been hacked, very strange ugh? This is a troll, right? I left my front door unlocked last night and no one walked in and stole anything, ergo, front door locks are a complete waste of time. Ok. It is a troll, no one could be silly enough to say those things and believe them. Regards.
Dynamic allow of relay
Title: Dynamic allow of relay Is there a way to setup qmail such that it will dynamically allow relay hosts based on their previous login to the qmail-pop3d? Namezero has their mail servers set up this way, so that as long as you've checked your mail within the last 10 minutes from that IP, you can use the server to send mail through. My mail server is not local to my workstations, and the workstations are on a DSL PPPoE connection which changes ip's every time I connect. Making a setup like this would greatly simplify how things work for me. Anyone have any ideas on how to do this? Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time!
Re: Limiting bandwidth usage
On Thu, May 31, 2001 at 11:13:56PM +0200, Roger Svenning allegedly wrote: Ok I see, so traffic shapers like altq and dummynet are made by people that don't understand the basics of tcp/ip ? :-) I didn't mean blocked literally, what I want is to make sure that smtp traffic, when qmail gets several thousand of mails dumped into it's queue, doesn't slow down http traffic too much, by putting some sort of a limit on qmail I want to avoid packetloss. We understand what you want. Do you understand that qmail has no facility for doing this? The only way is to use a traffic shaper external to qmail. Regards. -Roger -Opprinnelig melding- Fra: Russell Nelson [mailto:[EMAIL PROTECTED]] Sendt: 31. mai 2001 22:25 Til: '[EMAIL PROTECTED]' Emne: Re: Limiting bandwidth usage Roger Svenning writes: Anyone have some advice on how to limit the bandwidth usage for qmail ? We have a mail/web server sitting on a 2mbit and several times a week we need to push out 3+ mails and don't want this to totally block the web traffic to the same server. You don't understand how TCP/IP works. A sustained load through a network doesn't cause anybody to be blocked. It causes their transfers to slow down. TCP/IP interprets a lossy connection as an overloaded connection. That's why your IP connection must only lose packets when it is congested. -- -russ nelson [EMAIL PROTECTED] http://russnelson.com Crynwr sells support for free software | PGPok | Microsoft rivets everything. 521 Pleasant Valley Rd. | +1 315 268 1925 voice | Linux has some loose screws. Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | You own a screwdriver.
Re: Limiting bandwidth usage
On Fri, Jun 01, 2001 at 02:38:04AM +0200, Karsten W. Rohrbach allegedly wrote: Mark Delany([EMAIL PROTECTED])@2001.05.31 22:32:26 +: On Thu, May 31, 2001 at 11:13:56PM +0200, Roger Svenning allegedly wrote: Ok I see, so traffic shapers like altq and dummynet are made by people that don't understand the basics of tcp/ip ? :-) I didn't mean blocked literally, what I want is to make sure that smtp traffic, when qmail gets several thousand of mails dumped into it's queue, doesn't slow down http traffic too much, by putting some sort of a limit on qmail I want to avoid packetloss. We understand what you want. Do you understand that qmail has no facility for doing this? The only way is to use a traffic shaper external to qmail. qmail indirectly contains instrumentation for that. it is called remote concurreny. No it doesn't. you might echo 2/var/qmail/contro/concurrencyremote svc -t /service/qmail which would limit the running qmail-remote processes to two which leads to less bandwidth consumption for outgoing mail. Not necessarily and certainly not predicatably. Tell me what happens with the following scenarioes: Scenario one: You have a concurrencyremote of 1 You have one email in the queue That email is MXed to a yahoo.com address which has perhaps a 1Gb or more of inbound connectivity That email is 100MBytes in size A qmail-remote is scheduled to delivery the email Scenario two: You have a concurrencyremote of 100 You have 100 emails in the queue All emails are address to a dinky.connectivity.com. that has perhaps 14.4Kb of inbound connectivity Each email is 1MB in size A qmail-remote is scheduled for every message in the queue Question 1: What is the likely bandwidth consumption during delivery for Scenario one? Question 2: What is the likely bandwidth consumption during delivery for Scenario two? Bonus question: what part of qmail do you change to reduce the bandwidth consumption for Scenario one? Regards.
Re: recipient limit for qmail-inject?
On Thu, May 31, 2001 at 06:59:07PM -0600, Roger Walker allegedly wrote: On InterMail systems we use their mass mail program to send out some 650,000 newsletters to customers. The application batches them into a single message with a BCC containing somewhere between 40 and 100 recipients each (not sure of the exact number at this time). I would like to do similar on a Qmail system. Sounds good. Would anyone know the limit for qmail-inject? Is there a practical limit? Is there another another recommended way of doing this? There is no practical limit. Perhaps one qmail-inject per 50,000 recipients? I certainly would go a *lot* higher than your current 40-100. Remember, each inject creates a separate copy of the email in the queue. At 100 recipients per inject, that's 650,000/100 = 6,500 copies on disk. At 50,000 recipients per inject, that's 650,000/50,000 = 13 copies on disk. I specifically require that every message on a particular mailout have an identical Message-id, due to the storage setup on the receiving Intermail system - saves on disk space. Easy, just set the message-id in the header of the submitted email. qmail-inject only adds a message-id if one is not present. Regards.
SMTP doesn't respond
Title: SMTP doesn't respond Hi, I've read up a little on this, but couldn't search the archives (maybe the server is down?) for any more information. Anyway, from my understanding, if the qmail server can't resolve it's DNS entry, it will have problems with SMTP, and I believe that to be the problem. However, I haven't been able to find a resolution for my situation. Here's how things are configured in my environment: The server is using a private ip address (192.168.x.x) behind a load balancer. The load balancer runs NAT so the server can send data out. The load balancer also contains a routable ip address, for which, all traffic passes back to the private ip. There is a DNS entry for the routable ip, but not for the private ip. The qmail server is setup with the same name as the DNS entry for the routable ip. As qmail runs on DNS entries, I would assume this would make everything ok. It doesn't. When I telnet to the localhost on port 25, I get a connection and it just sits there. No response, ever. Below is the output of qmail-showctl just to make sure I haven't done anything wrong. Any suggestions? qmail home directory: /var/qmail. user-ext delimiter: -. paternalism (in decimal): 2. silent concurrency limit: 120. subdirectory split: 23. user ids: 101, 102, 103, 0, 104, 105, 106, 107. group ids: 100, 101. badmailfrom: (Default.) Any MAIL FROM is allowed. bouncefrom: (Default.) Bounce user name is MAILER-DAEMON. bouncehost: (Default.) Bounce host name is slgpmail1.sl.ca. concurrencylocal: (Default.) Local concurrency is 10. concurrencyremote: (Default.) Remote concurrency is 20. databytes: (Default.) SMTP DATA limit is 0 bytes. defaultdomain: Default domain name is sl.ca. defaulthost: (Default.) Default host name is slgpmail1.sl.ca. doublebouncehost: (Default.) 2B recipient host: slgpmail1.sl.ca. doublebounceto: (Default.) 2B recipient user: postmaster. envnoathost: (Default.) Presumed domain name is slgpmail1.sl.ca. helohost: (Default.) SMTP client HELO host name is slgpmail1.sl.ca. idhost: (Default.) Message-ID host name is slgpmail1.sl.ca. localiphost: (Default.) Local IP address becomes slgpmail1.sl.ca. locals: Messages for slgpmail1.sl.ca are delivered locally. me: My name is slgpmail1.sl.ca. percenthack: (Default.) The percent hack is not allowed. plusdomain: Plus domain name is sl.ca. qmqpservers: (Default.) No QMQP servers. queuelifetime: (Default.) Message lifetime in the queue is 604800 seconds. rcpthosts: SMTP clients may send messages to recipients at slgpmail1.sl.ca. morercpthosts: (Default.) No effect. morercpthosts.cdb: (Default.) No effect. smtpgreeting: (Default.) SMTP greeting: 220 slgpmail1.sl.ca. smtproutes: (Default.) No artificial SMTP routes. timeoutconnect: (Default.) SMTP client connection timeout is 60 seconds. timeoutremote: (Default.) SMTP client data timeout is 1200 seconds. timeoutsmtpd: (Default.) SMTP server data timeout is 1200 seconds. virtualdomains: (Default.) No virtual domains. defaultdelivery: I have no idea what this file does. concurrencyincoming: I have no idea what this file does. Thanks, Mark Douglas - Architecture Sympatico-Lycos Inc. All your base are belong to us! Make your time!
RE: SMTP doesn't respond
Title: RE: SMTP doesn't respond
Here is the script I'm using (straight out of Life with Qmail):
#!/bin/sh
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
export PATH
case $1 in
start)
echo -n Starting qmail: svscan
cd /var/qmail/supervise
nohup env - PATH=$PATH svscan
echo $! /var/run/svscan.pid
echo .
;;
stop)
echo -n Stopping qmail: svscan
kill `cat /var/run/svscan.pid`
echo -n qmail
svc -dx /var/qmail/supervise/*
echo -n logging
svc -dx /var/qmail/supervise/*/log
echo .
;;
stat)
cd /var/qmail/supervise
svstat * */log
;;
doqueue|alrm)
echo Sending ALRM signal to qmail-send.
svc -a /var/qmail/supervise/qmail-send
;;
queue)
qmail-qstat
qmail-qread
;;
reload|hup)
echo Sending HUP signal to qmail-send.
svc -h /var/qmail/supervise/qmail-send
;;
pause)
echo Pausing qmail-send
svc -p /var/qmail/supervise/qmail-send
echo Pausing qmail-smtpd
svc -p /var/qmail/supervise/qmail-smtpd
;;
cont)
echo Continuing qmail-send
svc -c /var/qmail/supervise/qmail-send
echo Continuing qmail-smtpd
svc -c /var/qmail/supervise/qmail-smtpd
;;
restart)
echo Restarting qmail:
echo * Stopping qmail-smtpd.
svc -d /var/qmail/supervise/qmail-smtpd
echo * Sending qmail-send SIGTERM and restarting.
svc -t /var/qmail/supervise/qmail-send
echo * Restarting qmail-smtpd.
svc -u /var/qmail/supervise/qmail-smtpd
;;
cdb)
tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp /etc/tcp.smtp
chmod 644 /etc/tcp.smtp*
echo Reloaded /etc/tcp.smtp.
;;
help)
cat HELP
stop -- stops mail service (smtp connections refused, nothing goes out)
start -- starts mail service (smtp connection accepted, mail can go out)
pause -- temporarily stops mail service (connections accepted, nothing leaves
cont -- continues paused mail service
stat -- displays status of mail service
cdb -- rebuild the tcpserver cdb file for smtp
restart -- stops and restarts smtp, sends qmail-send a TERM restarts it
doqueue -- sends qmail-send ALRM, scheduling queued messages for delivery
reload -- sends qmail-send HUP, rereading locals and virtualdomains
queue -- shows status of queue
alrm -- same as doqueue
hup -- same as reload
HELP
;;
*)
echo Usage: $0 {start|stop|restart|doqueue|reload|stat|pause|cont|cdb|queu
|help}
exit 1
;;
esac
exit 0
I haven't gotten a handle on qmail logging yet. Where are the log files stored? I look at /var/log/qmail and the files that are there contain these lines:
from /var/log/qmail/current
@40003b1518da292b19c4 status: local 0/10 remote 0/20
from /var/log/qmail/smtpd/current
@40003b1518da3494b75c tcpserver: status: 0/0
I don't think there is a load balancer problem with SMTP, as there is another mail server running sendmail right beside this one. It's just that it was setup by somebody else, who no longer works here, and I'm much more a fan of qmail than I am of sendmail, so we're moving forward with qmail installs now.
If I can provide any further information to you, please let me know.
Thanks,
Mark
-Original Message-
From: Charles Cazabon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 12:19
To: '[EMAIL PROTECTED]'
Subject: Re: SMTP doesn't respond
Mark Douglas [EMAIL PROTECTED] wrote:
The server is using a private ip address (192.168.x.x) behind a load
balancer. The load balancer runs NAT so the server can send data out. The
load balancer also contains a routable ip address, for which, all traffic
passes back to the private ip. There is a DNS entry for the routable ip, but
not for the private ip.
This could be part of the problem.
The qmail server is setup with the same name as the
DNS entry for the routable ip. As qmail runs on DNS entries, I would assume
this would make everything ok. It doesn't. When I telnet to the localhost on
port 25, I get a connection and it just sits there. No response, ever.
Ever? Or not in the first 60 seconds? Or what?
Below is the output of qmail-showctl just to make sure I haven't done
anything wrong. Any suggestions?
This looks good (thanks for including it). What would help would be a copy of
the script you're using to start qmail-smtpd. tcpserver may be trying a
reverse lookup on your IP address and timing out, as well as some other DNS
lookups which happen. They can all be fixed with changes to your qmail-smtpd
script.
Also, are any error messages ending up in the qmail-smtpd log? Does outgoing
mail work? Are there errors in the main qmail log?
I've tried to telnet to the SMTP port myself (thanks for using real DNS
information and not obscuring it), and you seem to be correct -- I've got a
connection, but not the welcome banner, even after several minutes. If it's a
problem with your qmail-smtpd script, there should be errors in the log from
the tcpserver instance for it. Another possibility, I suppose, is that the
load balancer is somehow broken in regards to SMTP?
Charles
--
---
Charles Cazabon
RE: SMTP doesn't respond
Title: RE: SMTP doesn't respond No error messages in either of the logs. Here is the content of the run file for smptd: #!/bin/sh QMAILDUID=`/usr/xpg4/bin/id -u qmaild` NOFILESGID=`/usr/xpg4/bin/id -g qmaild` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` exec /usr/local/bin/softlimit -m 400 \ /usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb -c $MAXSMTPD \ -u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd 21 Thanks for all the help! Mark -Original Message- From: Charles Cazabon [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 13:18 To: '[EMAIL PROTECTED]' Subject: Re: SMTP doesn't respond Mark Douglas [EMAIL PROTECTED] wrote: The qmail server is setup with the same name as the DNS entry for the routable ip. As qmail runs on DNS entries, I would assume this would make everything ok. It doesn't. When I telnet to the localhost on port 25, I get a connection and it just sits there. No response, ever. This looks good (thanks for including it). What would help would be a copy of the script you're using to start qmail-smtpd. Here is the script I'm using (straight out of Life with Qmail): [...] echo -n Starting qmail: svscan cd /var/qmail/supervise nohup env - PATH=$PATH svscan echo $! /var/run/svscan.pid echo . ;; Okay. This script starts svscan. svscan will run another set of scripts to actually start the various qmail services. You'll have a service directory (probably /service, but possibly elsewhere) containing symlinks to other directories. Look for one called smtpd or qmail-smtpd. Inside that directory will be a script named run. We now need the contents of that script. I haven't gotten a handle on qmail logging yet. Where are the log files stored? I look at /var/log/qmail and the files that are there contain these lines: from /var/log/qmail/current @40003b1518da292b19c4 status: local 0/10 remote 0/20 Yes, that's one line from the logs of qmail-send (the main qmail process, which actually is responsible for the delivery of messages). from /var/log/qmail/smtpd/current @40003b1518da3494b75c tcpserver: status: 0/0 And that is indeed the log from qmail-smtpd (well, from its tcpserver instance, anyway). Were there any error messages in this log? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
RE: SMTP doesn't respond
Title: RE: SMTP doesn't respond I'm not very familiar with tcpserver options. I tried adding the -R and -H as a suggestion from somebody else. As per your e-mail, I tried switching -p to -P (which as I understand, is NON-paranoid mode) and it didn't help. I also removed the -p option altogether, it didn't help either. Anyone have further suggestions? -Original Message- From: Alexander Jernejcic [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 14:27 To: Mark Douglas; [EMAIL PROTECTED] Subject: RE: SMTP doesn't respond hi, Mark Douglas wrote: /usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb -c $MAXSMTPD \ there is some mixture in the options i am not able to understand: with -H and -R you are telling tcpserver not to optain TCPREMOTE and to do no reverse lookup. on the other hand you tell it to be paranoid -p and check up ip and hostname. i am confused about that, maybe tcpserver too? hope that helps alexander
RE: SMTP doesn't respond
Title: RE: SMTP doesn't respond SWEET! That was it, THANK YOU VERY MUCH! Posting this back to the list so people know what my problem was. I had an empty concurrencyincoming file. -Original Message- From: Greg White [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 30, 2001 14:00 To: Mark Douglas Subject: Re: SMTP doesn't respond On Wed, May 30, 2001 at 01:29:36PM -0400, Mark Douglas wrote: No error messages in either of the logs. Here is the content of the run file for smptd: #!/bin/sh QMAILDUID=`/usr/xpg4/bin/id -u qmaild` NOFILESGID=`/usr/xpg4/bin/id -g qmaild` MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` exec /usr/local/bin/softlimit -m 400 \ /usr/local/bin/tcpserver -R -H -v -p -x /etc/tcp.smtp.cdb -c $MAXSMTPD \ -u $QMAILDUID -g $NOFILESGID 0 smtp /var/qmail/bin/qmail-smtpd 21 Thanks for all the help! Please see my later message to the list -- I'm sending this direct to save some time. This script is definitely LWQ. I think maybe /bin is not in your PATH for the script, or /var/qmail/control/concurrencyincoming is empty or '0'. If concurrencyincoming has '40' in it, try fully qualifying the path to 'cat' in the script -- like '/bin/cat' or '/usr/bin/cat', whichever is appropriate for your machine. If I'm correct, please feel free to quote any or all of this message to the list... I checked your earlier message, and qmail-showctl and this script seem to agree that 'concurrencyincoming' is the right file -- I can't count the number of times I couldn't figure out what was up when I got zero connections with '40' in /var/qmail/control/concurencyincoming ;) (Look closely at that filename) ;) HTH, -- GW
Re: Vpopmail+qmail pop3 has lost it's mind!
On Wed, May 30, 2001 at 03:50:58PM -0400, Dave Sill allegedly wrote: Henning Brauer [EMAIL PROTECTED] wrote: You want to sync the clocks... qmail-pop3d won't list messages from the future. Somebody refresh my memory... Why does it care? Apart from the enigmatic don't want to mix up the order, you could construe it as a feature that would make a bulletin *visible* to everyone at exactly the same time... Apart from that, I cannot think of a POP related reason why an mtime in the future would be a problem. Regards.
Re: Advanced masquerading
I'm not sure its relevant. The whole address-rewriting thing is a sendmail-ism that should just go away; it must have originated in an effort to compensate for other, unrelated sendmail design flaws. It's all a historical thing. The problem that sendmail was designed to solve back in the uucp days is different from the problems that modern MTAs are designed to solve. The hardest part of uucp mail was the address rewriting, so sendmail went through amazing contortions in order to solve this problem. Internet mail doesn't need to do any rewriting at all, so the bulk of the code in sendmail is there to solve a problem most of us don't have. I was fortunate in never having actually been stuck on the end of a uucp link, but even in those days sendmail's rewriting rules often got in the way of just getting the mail there. Absolutely. I used to do a lot of uucp with qmail and the best thing you can do is forget about rewriting and ! addresses. uucp does not insist on this, though it's as ingrained as many other myths surrounding mail (and dns). What uucp does do well is transfer a file and execute a command remotely - so conceptually one simple wants to transfer the email contents and run a command at the other end that injects it into qmail. The best thing to do is just use FQDN addresses and avoid all rewriting. There is some references to this on www.qmail.org and I'm sure much of this has been previously discussed and thus archived. Regards.
Re: Qmail remote process never drops problem
On Tue, May 29, 2001 at 03:10:24PM -0700, Eric Wang allegedly wrote: Nope, the response from those machine machine are pretty good, these qmail connections are just never dead. the is really confusing though. Can you trace the qmail-remote processes? truss -p, ktrace -p, ?? Regards.
Re: limiting databytes per user
On Mon, May 28, 2001 at 11:55:38AM -0300, Eduardo Augusto Alvarenga allegedly wrote: If your users inject mail via SMTP from their workstations to your smarthost, and you can map IP addresses to usernames, it's trivial -- tcpserver's tcprules files can be used to set all environment variables (including DATABYTES) on a per-IP basis. Charles Great idea, I'm using dhcp. Can I use a classless rule like? 192.168.0.:allow,RELAYCLIENT=,DATABYTES=2 for 2MB users and 193.168.0.:allow,RELAYCLIENT=,DATABYTES=10 for 10MB users? That's a good strategy, though 193.168 are not good addresses to use as they are real, routable addresses. How about: 192.168.0-127.:allow,RELAYCLIENT=,DATABYTES=2 192.168.128-255.:allow,RELAYCLIENT=,DATABYTES=10 Or somesuch? Regards.
Re: Qmail remote process never drops problem
Which OS? Not Solaris 2.8? On Mon, May 28, 2001 at 06:53:38PM -0700, Eric Wang allegedly wrote: Hi , Guys, I have a qmail server with very heavy load, and I noticed recently my qmail server have a bunch of outbound connection to some domains like outblaze.com, and the email send to their mail server , the tcp process state after become ESTABLISHED then seems never drops. I am wondering if there is anybody have similar problem and how you solved it. Thanks a lot!
postfix/qmail best for message tracking through system
Hi all I am in the process of evaluating MTA/mailing list engines for the purpose of building a robust mail engine for commecial use. A central requirement of the mailing engine is that it can be used to track the delivery status of messages through the system (i.e. if I send message A and then message B to [EMAIL PROTECTED] and message A bounces, whilst message B is received, I need to know this via logs/API whatever). It seems that qmail and Postfix are by far the best performing MTAs for Linux, so the differentiating factor for us will be which can provide our required functionality with the minimum of modification. If anyone has any experience of this type of use for Qmail or Postfix, I would appreciate any comments/advice/opinions. Thanks Mark smime.p7s
Re: setting a custom environment var
On Fri, 25 May 2001, Dave Sill wrote: You can parse that from the Received fields. That's my plan of last resort. I didn't want to do this unless I really had to because of the different formats the Received headers can have, and that there can be any number of them. My life would be made a lot easier if I had ready access to the hostname/IP that is giving me the email without doing the guesswork (which is what parsing the Received headers will amount to in the end) Not much of a source hacker I did go into received.c and tried adding Stop right there. Do NOT hack qmail's source unless you *really* know what you're doing. Hey, it's not like I was going to ship it anywhere. (All the other kids are doing it...) So I guess there is no readily available way to do this? -mark P.S. I take it you are using tmda for your reply-to? I stumbled on this in the course of researching and it looks like just what the doctor ordered for my purposes. -- mark jeftovic http://www.easydns.com http://mark.jeftovic.net
Re: change password for virtual users.
Hi, I mean vmailmgr + qmail + omail-admin ??? Mark - Original Message - From: Andrea Cerrito [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 25, 2001 7:16 PM Subject: R: change password for virtual users. omail-admin with vpopmail? How can it be possible? --- Cordiali saluti / Best regards Andrea Cerrito ^^ Net.Admin @ Centro MultiMediale di Terni S.p.A. P.zzale Bosco 3A 05100 Terni IT Tel. +39 744 5441330 Fax. +39 744 5441372 -Messaggio originale- Da: Mark Lo [mailto:[EMAIL PROTECTED]] Inviato: giovedi 24 maggio 2001 8.43 A: [EMAIL PROTECTED] Oggetto: change password for virtual users. Hi, I am using qmail + vpopmail + omail-admin. I would like to write a simple program to change the virtual user's password on the web by using the vpasswd function. I know omail-admin has the function to change password. But, I would like to disable the forward filed. So, I decide to write one by myself. Anybody has any idea to do it. Thank you Mark
RE: postfix/qmail best for message tracking through system
Thanks Dave That sounds like it might go some of the way to solving my problem. What I need to ensure though is that I can differentiate between multiple bounced emails from a a single address, or in fact, more importantly, a single bounce when I have sent multiple emails to an address. Do you know if there's any way I can extend the VERP thing so that I can insert a unique message-ID into the return address or similar? Thanks Mark -Original Message- From: Dave Sill [mailto:[EMAIL PROTECTED]] Sent: 25 May 2001 03:05 To: [EMAIL PROTECTED] Subject: Re: postfix/qmail best for message tracking through system Mark Gebhardt [EMAIL PROTECTED] wrote: A central requirement of the mailing engine is that it can be used to track the delivery status of messages through the system (i.e. if I send message A and then message B to [EMAIL PROTECTED] and message A bounces, whilst message B is received, I need to know this via logs/API whatever). It seems that qmail and Postfix are by far the best performing MTAs for Linux, so the differentiating factor for us will be which can provide our required functionality with the minimum of modification. Both qmail and Postfix log complete delivery information including all sucessful and failed delivery attempts. Depending upon your application, you might be able to take advantage of qmail's variable envelope return path (VERP) mechanism, which allows reliable bounce processing by encoding the bouncing address in the return address. -Dave smime.p7s
Re: setting a custom environment var
On Fri, 25 May 2001, Dave Sill wrote: No, Received fields aren't randon junk. You can trust the ones added by qmail. I guess I will do this after all, I tried uncommenting the call to env_unset on TCPREMOTEHOST in tcp-env hoping that would do the trick but it doesn't seem to (I know you said don't touch the source but it got in my head and I had to try it, you know how it is...) Nothing easier that parsing the Received fields. E.g., it took me about a minute to come up with: 822field received msg|sed '1d'|sed '2,$d'|sed 's/.*(//' Which uses 822field from DJB's mess822 to extract the IP address of the sending host from a message. That's really cool. Will grab that package and take a look, thanks. P.S. I take it you are using tmda for your reply-to? I stumbled on this in the course of researching and it looks like just what the doctor ordered for my purposes. It's great. I've received almost no spam since implementing it. The only spam that's gotten through has gone through our helpful relay which fixes unqualified addresses by tacking on ornl.gov, which is on my whitelist, of course. It took me a couple days to come up with a sendmail rule that bounced email with a Probably not local error instead of fixing it like that. Cuts down on spam drastically, especially on a mail forwarder for thousands of domains. But not without collateral damage though, vixie cron job output gets bounced because the from address is hardcoded as From: root into the binary. -mark -- mark jeftovic http://www.easydns.com http://mark.jeftovic.net
RE: postfix/qmail best for message tracking through system
Thanks James OK, that sounds like just what I need. The question now is what is used to do it? Qmail, obviously, plus ezmlm it looks like? Is this unique message-id thing a function of Ezmlm? Or is there some other software/scripts/whatever that sits over it and runs the show? Also, does this technique only work with VERP-compliant MTAs on the receiving (other) end? Cheers Mark -Original Message- From: James Raftery [mailto:[EMAIL PROTECTED]] Sent: 25 May 2001 04:25 To: [EMAIL PROTECTED] Subject: Re: postfix/qmail best for message tracking through system On Fri, May 25, 2001 at 03:47:49PM +0200, Mark Gebhardt wrote: Do you know if there's any way I can extend the VERP thing so that I can insert a unique message-ID into the return address or similar? In essence, yes. This mailing list, for example, uses just that. The return address for your message as it was delivered to me was: [EMAIL PROTECTED] which includes a message number (68498) and my delivery address (james-qmail=now.ie). This allows the mailing list software to determine the message which bounced and the recipient to which it was addressed. Regards, james -- James Raftery (JBR54) It's somewhere in the Red Hat district -- A network engineer's freudian slip when talking about Amsterdam's nightlife at RIPE 38. smime.p7s
Re: changing concurrencyremote based on available bandwidth
In general. It's very hard to use concurrency to control bandwidth usage. If your system is concurrently sending a 100 messages to one server that's on the other end of a modem link, does that use more of your bandwidth than one MP3 email going to a high capacity site like Yahoo? No. The single email to Yahoo will probably blast out and fill your capacity. You need to dive into the world of traffic shapping which is done at the network level if you really want to control the bandwidth consumed by email. Oh, I don't understand why you'd get bounces due to limited bandwidth. Most qmail installations retry a mail if the delivery fails, what does your qmail do? Regards. On Fri, May 25, 2001 at 08:06:26AM -0600, Charles Cazabon allegedly wrote: Smith, Lisa [EMAIL PROTECTED] wrote: What I'd like to know is if anyone has come up with a script that can modify qmails concurrencyremote setting on the fly based on available bandwidth? Not to my knowledge. I've seen people mention the possibility before, but never seen a proposed solution. Basically what I am looking for (and we may write in-house if no one has something similar out there), is a script that would be able to detect the available bandwidth, and adjust qmail's concurrencyremote setting, so that we're not sending too much (or too little) traffic out that pipe. Changing the remote concurrency is fairly simple; write your new value to /var/qmail/control/concurrencyremote and restart qmail. It might take a minute or two to stop if there are remote deliveries in progress. You could theoretically do this in a shell script called from cron every ten minutes or so. Measuring available bandwidth is, of course, the tricky part. The problem that we're running into is that our machines are either sending out too much at once (concurrency set 'too high'), causing failed connections, and bounces, else the machines are throttled back (concurrencyremote set 'too low') not taking advantage of the available bandwidth. Why not just pick the highest value that still leaves you sufficient bandwidth for other purposes? qmail may not use all the available bandwidth, but it will keep moving the mail out throughout the slow times, and should even out. Charles -- --- Charles Cazabon[EMAIL PROTECTED] GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
change password for virtual users.
Hi, I am using qmail + vpopmail + omail-admin. I would like to write a simple program to change the virtual user's password on the web by using the vpasswd function. I know omail-admin has the function to change password. But, I would like to disable the forward filed. So, I decide to write one by myself. Anybody has any idea to do it. Thank you Mark
setting a custom environment var
I'm playing with a privacy gateway for whois records. To make a long story short I want to be able act based on which remote mail server is sending me the message. Looking at the environment when I pipe to a perl script I see nifty settings such as DTLINE, RECIPIENT, LOCAL and HOST. What I also need is something like REMOTE_SMTP, which would contain the hostname or IP of the mail hub giving us the email. Not much of a source hacker I did go into received.c and tried adding char renv[16]; strcpy(renv, REMOTE_SMTP); setenv(renv, remotehost,1); to received() but it doesn't seem to be doing the trick. I'm also quite inexexperienced at qmail so sorry if this is well known but I haven't found it in the doccage yet. -mark -- mark jeftovic http://www.easydns.com http://mark.jeftovic.net
Re: sending mail using qmail-inject
On Thu, May 24, 2001 at 05:55:44PM -0700, Qmail allegedly wrote: Is it possible to script qmail-inject to send a full bodied message from the command line? I'm trying something like this: ( echo to: alerts@XYZnet ; echo from: [EMAIL PROTECTED] ; echo subject: logs ; grep '@customer.com' /var/log/qmail/* ) | /var/qmail/bin/qmail-inject I get the header, ok, but no body? I bet you got all the matching log entries in the header. Make sure you put an empty line between the headers and the body. ( echo to: alerts@XYZnet ; echo from: [EMAIL PROTECTED] ; echo subject: logs ; echo; grep... ) | .. Regards.
Re: Problems with SMTP connections
qmail does this on its own -- if DNS isn't working, you shouldn't be able to send mail anywhere remote (well, except for those domains you've hardcoded This is where my question of a local DNS server came in. Do I have to run something like djb-dns on my machine? I figured that I would be able to use my ISP's server. I'm on dial-up, by the way. Well, yes you can use your ISPs name servers, they should be in /etc/resolv.conf Having said that, as a dialup you should configure qmail to send all of your email to your ISPs SMTP server and let it worry about it. That's worth doing for two reasons: First, many sites purposely reject SMTP connections from dialup addresses mainly because spammers often send directly from throw-away dialup accounts. Second, if the site you are trying to send mail to happens to be down at the instant you try and send, the mail may sit on your server until you next dial in, which could be days I guess. If you send it to your ISP, their server will repeatedly try. To send all mail to your ISP, simple put their SMTP server in /var/qmail/control/smtproutes, Something like this: :smtp.cnmnetwork.com Regards.
Re: High Availability, High Volume and NFS
I don't want to start an OS war, but if you want to use NFS on an Intel box, I strongly suggest one of the BSDs. I was in a situation where I had to use Linux NFS servers - that was until they failed miserabled. They were replaced with FreeBSD and the problems went away. Regards. On Wed, May 23, 2001 at 01:40:13PM -0500, Duane Schaub allegedly wrote: I want to set up multiple qmail machines to access an NFS backend. We have about 10,000 users (running maildir) and an average of 5 emails/user/dat and av. 10K in size. On average, there are 6 simultaneous pop sessions with approx. 200 new sessions/min. We have tried a Redhat6.1 backend on the NFS with Redhat 6.1 NFS clients. The result was that the qmail machines were BARELY able to keep up. If there were any pauses on the NFS server, the POP sessions would build to 50-60 very quickly with qmail crashing at about 300 sessions. Once qmail exceeded about 70 sessions, it was beyond the point of return and would not recover. The NFS server was nothing special (P350/IDE 256Mb RAM). We also tried a Dell 2300 (Dual 400/RAID5) NT server running Intergraph NFS But the performance was abysmal! Performing an ls in a user/new directory took 21 seconds for a response. I think NFS would work, but I don't really want a Netapp F5 ($50,000). What NFS experiences are out there? If you wish - respond privately [EMAIL PROTECTED] Duane. President, | Terra World, Inc. Terra World, Inc.| 200 ARCO Place, Suite 252 (888)332-1616| Independence, KS 67301 (620)332-1616| When your work counts, Use www.terraworld.net |T E R R A W O R L D
10 Million Messages per day
Hi, If I have 10 Million messages per day. What system requirement do I need for a qmail server. Etc. Memory.. CPU.. Bandwidth... Thank you Mark
Re: 10 Million Messages per day
Yeh.. 10 Million outbound messages... - Original Message - From: Alex Povolotsky [EMAIL PROTECTED] To: Mark Lo [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, May 22, 2001 11:34 PM Subject: Re: 10 Million Messages per day On Tue, May 22, 2001 at 11:15:48PM +0800, Mark Lo wrote: If I have 10 Million messages per day. What system requirement do I need for a qmail server. Etc. Memory.. CPU.. Bandwidth... 10 000 000 of inbound, outbound or transit EMails? What is typical size? do you need also POP3/IMAP? What is expected load on POP3/IMAP? Are you sure you're going to get 10 000 000, not 100 000? Alex.
Re: Using fetchmail with qmail
On Mon, May 21, 2001 at 12:20:36AM +0300, Mikko Hänninen wrote: David Talkington [EMAIL PROTECTED] wrote on Sun, 20 May 2001: There's really nothing special about such a configuration; fetchmail just delivers mail to whoever is listening on 25. As long as qmail will accept deliveries for localhost, it works great. I do this on my laptop. There is one gotcha, you have to enable the forcecr option in your .fetchmail configuration, if you're using delivery via localhost port 25. This is documented as a qmail quirk (or something) in the fetchmail documentation, but it *is* documented at least... Without this setting, qmail will reject the emails due to the CR/LF line ending issue. Hmm. The fetchmail man page seems to say it quite well: The `forcecr' option controls whether lines terminated by LF only are given CRLF termination before forwarding. Strictly speaking RFC821 requires this, but few MTAs enforce the requirement it so this option is normally off (only one such MTA, qmail, is in significant use at time of writing). FWIW. This problem cannot occur if the pop server is qmail-pop3d. I've used fetchmail on a variety of non-qmail pop servers and have never needed forcecr. I hasten to add that that doesn't mean that Mikko is wrong, just that the you probably don't need this option excepting when you fetch from dodgy pop servers! On a related note, it seems that fetcmail has made some effort to support qmail in a variety of ways, including the -Q option which is specifically designed to extract envelope addresses from Delivered-To: addresses created via virtualdomains (See the fetchmail -Q option). Regards.
Re: Still want to use fetchmail with qmail
On Sun, May 20, 2001 at 06:26:36PM -0300, Alexandre Gonçalves Jacarandá wrote: Hi again!!! I follow some tips, but I can get fetchmail working with qmail. But now I will give more details... I installed qmail following Life with qmail and it's working. I configured Mailbox delivery in my system and I've ISP that use sendmail and when I tried to fetch mail mails this error occurs: client/server synchronization error. My fetchmailrc is: # Configuration created Sun May 20 18:04:12 2001 by fetchmailconf set postmaster alex set bouncemail set properties poll pop3.superonda.com.br with proto POP3 user 'clark_vr' there with password 'xx' is alex here options forcecr dropdelivered warnings 3600 antispam 571 550 501 554 Thanks, Alexandre Gonçalves Jacarandá This is no doubt a fetcmail - popserver issue and has nothing to do with qmail, but try running fetchmail with the option that gives debugging output. The fetchmail manpage tells you which option. Regards.
Re: help for show time zone
On Sun, May 20, 2001 at 01:42:12PM +0800, new wrote: hello, qmail uses GMT to show time zone,like this: Received: (qmail 9258 invoked from network); 19 May 2001 23:25:42 - How can I let it use GMT+8 or PRC to show time zone. Change to code. There is no configuration setting for this. Regards. PS. Check the archives. This has been discussed many, many time.
Re: unauthorized relay :-(
On Fri, May 18, 2001 at 06:55:59AM -0600, Roger Walker wrote: On 18 May 2001, Mark Delany wrote: So you are saying that you've checked the qmail-send logs and there is no injection that matches the headers of the bounce? Are you sure? If you found a match, then the uid trail will tell you who did it. The log portion I supplied is indicative of all of the stuff related to the aol mail. The PID associated with those messages was not there when I became aware of what was happening, so I can't definitively trace it. UID != PID And, er, qmail-send (with UID) and (tcpserver with PID) unconditionally log their UID and PID, so what exactly do you mean by was not there? But, AOL doesn't help matters as their bounces don't return any original header information, blah. Regards.
Re: unauthorized relay :-(
On Fri, May 18, 2001 at 08:37:37AM -0600, Roger Walker wrote: UID != PID Sorry, I was distracted. The UID was for apache, further evidence that this was done through a formmail script. Ok... And what did your apache logs say at the time? They are logging IP addresses, right? Here's the tcpserver invocation: tcpserver -p -x /etc/tcpserver/tcp.smtp.cdb -u 301 -g 300 0 smtp \ /usr/local/bin/rblsmtpd \ -rrbl.maps.vix.com \ -rinputs.orbs.org \ -routputs.orbs.org \ -rspamsources.orbs.org \ -rspamsource-netblocks.orbs.org \ -runtestable-netblocks.orbs.org \ -rmanual.orbs.org \ -rdialups.mail-abuse.org \ -rrbl.rope.net \ /var/qmail/bin/qmail-smtpd 21 \ | setuidgid qmaill tai64n | setuidgid qmaill tai64nlocal \ | setuidgid qmaill multilog +\* /var/log/rbl Superficially that looks ok, again kinda different from what one usually sees. So there are not entries in /var/log/rbl/current like: @40003b053761268c7a14 tcpserver: pid 16838 from 131.193.178.181? Regards.
Re: qmail-inject internals question
On Fri, May 18, 2001 at 10:16:41AM -0500, dan . kelley wrote:
hi-
I've started to hack around with qmail-inject.c a bit. i'm trying to modify
the file to optionally look for a control/addmessage file, the contents of
which will be appended to every locally generated message.
Right. So that won't catch messages submitted via SMTP from your local
(windows) clients. I presume that's ok? If you're not sure about where
qmail-inject and friends fit into the scheme of things, carefully read
and understand all of the PIC.* files in the qmail source before
proceeding.
I also assume you're aware of the MIME related issues in trying to do
this. It's been discussed many times on this list - the archives are
your friend.
i'm having some difficulty tacking the addmessage onto the message as it
passes through qmail-inject, so i'm trying to insert some simple logging
messages so i can follow the execution of qmail-inject.
one thing that i'm having a difficult time following: it looks like Dan
Berenstein's logging architecture for qmail is broken down into 3 pretty
simple calls:
Well, qmail-inject doesn't log particularly. It's meant to be invoked
from a shell and thus informs you of results via stderr and the exit
code.
(from qsutil.c)
void log1(s1) char *s1; {
substdio_putsflush(sserr,s1); }
void log2(s1,s2) char *s1; char *s2; {
substdio_putsflush(sserr,s1);
substdio_putsflush(sserr,s2); }
void log3(s1,s2,s3) char *s1; char *s2; char *s3; {
substdio_putsflush(sserr,s1);
substdio_putsflush(sserr,s2);
substdio_putsflush(sserr,s3); }
from what i gather, all of these just write messages to stderr,
and multilog/splogger are responsible for collecting them.
multilog is *nothing* like syslog. You just can't make a call to write
to stderr in one process such as qmail-inject and magically have it
show up with the output of some other process such as qmail-send.
this line placed in void main(), before any other function.
log1(qmail-inject: started);
You might want to actually copy the way qmail-inject generates its
messages. Hint: search for the string memory.
Regards.
Re: Lotsa messages with qmail-remote?
On Thu, May 17, 2001 at 08:29:37AM +, Greg Cope wrote: I used IO::select to handle running multiple qmail-remotes at the same time. qmail-remote has a really small footprint so you can run 1000s of them concurrently on a modest sized server. It takes a fair amount of code to manage multiplexed pipes in conjunction with handling stdout and stderr (execution errors) responses and exit conditions. (I see that there is an IO::Poll in which case I'd probably use that in preference to IO::Select because of some of the select limit issues on some OSes). Can you shed any more light on this. I am very interested as I may write something similar soon, and any ideas / help would be much appreciated. Well, that's more a perl/Unix issue than a qmail one so this isn't the right place to discussed it. If you're asking about the benefits of poll vs select, there is plenty of material on the net about this. (Now if kqueue gets into enough Unixen and someone write a perl interface for it, well, that'd be something to talk about : ) Regards.
Re: Problem due to prepend in virtualdomain file
Do you have a user called ttk? Remember, ~alias is the *last* place that qmail looks for instructions. If a user exists with that name, it delivers to that user. The man page for qmail-lspawn is a good place to start. Regards. On Thu, May 17, 2001 at 09:36:00PM +0530, [EMAIL PROTECTED] wrote: I am facing a strange problem , I am haivng a domain called ttk-lig.com in my virtualdomain file with prepend ttk. eg. ttk-lig.com:ttk I have created a default alias for ttk-lig.com by the name .qmail-ttk-default and having below text in it |forward $[EMAIL PROTECTED] And for ttklig_ch_notes.ttk-lig.com i am having below entry in my smtproutes file. ttklig_ch_notes.ttk-lig.com:[192.168.100.1] Ideally it should forward all the mails for ttk-lig.com to 192.168.100.1 But when i am sending a mail to anyuser it is getting bounced back. I send a test mail to [EMAIL PROTECTED] and i got below msg in my logs 990115095.554767 info msg 829190: bytes 237 from [EMAIL PROTECTED] qp 13835 u id 0 990115095.556688 starting delivery 329454: msg 829190 to local [EMAIL PROTECTED] 990115095.556700 status: local 1/10 remote 3/120 990115095.799451 delivery 329454: failure: Sorry,_no_mailbox_here_by_that_name._(#5.1.1)/ But if i change the prepend from ttk to ttk1 and make my alias file by the name .qmail-ttk1-default then my mails start working. Can any one tell me why its not taking the word ttk ? Regards Lokesh
Re: Lotsa messages with qmail-remote?
Can you shed any more light on this. I am very interested as I may write something similar soon, and any ideas / help would be much appreciated. Well, that's more a perl/Unix issue than a qmail one so this isn't the right place to discussed it. If you're asking about the benefits of poll vs select, there is plenty of material on the net about this. (Now if kqueue gets into enough Unixen and someone write a perl interface for it, well, that'd be something to talk about : ) What I was interested in was using perl to drive qmail-remote, not a discussion of poll vs select, although that would be handy. Well, it's no different from running any other program within perl. The interface to qmail-remote is completely documented in the qmail-remote manpage. The only trap is that you cannot use open(... |qmail-remote) as you need to set up a bi-directional pipes. I did it the hard way with fork/exec and manipulated the fds, but you could possibly use IPC::Open2 available from your friendly CPAN server. But this is mostly perl/Unix talk, not qmail. Regards.
Re: qmail ignores my sorry ass part II...
On Thu, May 17, 2001 at 12:25:43PM -0700, Brett wrote: Ok, thanks. Here's some more info: I'm trying to send the mail with qmail-inject from the command line. I checked and the exit code I'm getting is 65280. I meant 5600 addresses, not messages, and yes, that's more or less how I'm placing the addresses except I'm doing it from a perl script that puts the addresses in a Bcc field and then makes a system() call which is just like calling from the Bcc field? Do you mean these address are on the command line or in the headers of the message? The difference is a lot more than more or less. In fact the difference is critical. If the latter then you have a different problem from what I suggested. If the former, then change to the latter as that's the best way as you cannot normally increase the command line limits without kernel rebuilds. Regards. command line. I think you may be onto something here with your theory of my being over the limit of command line arguments. The question is how do I increase that limit? And now I'm suddenly off-topic for this list, I know. Nevertheless, I'm sure I won't be the last qmail user to run into this problem and therefore it'll be useful to have this knowledge in the archives. Thanks again. -Original Message- From: Mark Delany [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 6:17 PM To: [EMAIL PROTECTED] Subject: Re: qmail ignores my sorry ass... You need to tell us a little more. Well, actually a lot more. How are you trying to send them? qmail-inject, smtp, qmail-queue? If you are running a command such as qmail-inject, what sort of exit code are you getting? Any error message? Do you mean 5600 emails or an email to 5600 addresses? If the latter, are you placing all the recipients on a command line, something like: /var/qmail/bin/qmail-inject recipient1@dom1 recipient2@dom2 ... ? If so, have you perhaps exceeded the maximum length of the command line for your system? Are you perhaps exceeding the maximum number of command line arguments for your system? To check the exit status from the shell, go echo $? immediately after the command. The number is zero if all is well and other numbers indicate different types of errors. Regards. On Wed, May 16, 2001 at 04:37:41PM -0700, Brett wrote: ... when I try to send more than 5600 emails in one go. I mean, it completely ignores me. There's no mention of anything occuring in the logs whatsoever. Since I'm giving you so little to go on here, I'm mostly hoping for a general direction to start looking for a problem rather than a complete solution. Or hopefully this has happened to somebody before and they can tell me what they did to fix it. I've successfully recompiled the kernel and applied the big concurrency patch but not the big-todo one yet. I posted this before but didn't get much of a response except to check qmail-inject's exit status. Assuming I know how to do this, what will this prove? Thanks for any and all help. Brett. A big F you to all the unhelpful flamers in advance.
Re: qmail ignores my sorry ass part II...
On Thu, May 17, 2001 at 01:57:11PM -0700, Brett wrote:
Here's how I'm calling qmail-inject:
$mail_prog = '/var/qmail/bin/qmail-inject';
$mail = To: $to_name $to_email\r\n;
$mail .= From: $from_name $from_email\r\n;
if ($bcc) {
$mail .= Bcc: $bcc \r\n;
}
$mail .= Subject: $subject\r\n\r\n;
$mail .= $body\r\n;
system (echo '$mail' | $mail_prog);
The Bccs are in the header but they're still being inserted into the command
line which is what I meant by more or less. I actually don't really see
another way of getting all the bccs to qmail-inject.
Ahh. You've got them on echo's command line. I've never quite seen it
done that way before...
There are *much* better ways that avoid such limits. Try this:
OPEN(MP, | $mail_prog) or die ...
print MP To: $to_name $to_email\r\n;
print MP From: $from_name $from_email\r\n;
if ($bcc) {
print MP Bcc: $bcc \r\n;
}
print MP Subject: $subject\r\n\r\n;
print MP $body\r\n;
close(MP) or die ...;
No command line limit, no echo, no lumpy $mail variable. I'd also be
inclined to print a separate Bcc: header for each recipient, but
that's just my must always scale mentality.
Hmm. It must be unix/perl day on the qmail list.
Regards.
Re: unauthorized relay :-(
On Thu, May 17, 2001 at 10:32:41PM -0600, Roger Walker wrote: I understand completely. I administer mail servers for a major ISP, so the principles are not a problem. I run qmail on my own servers, but there could always be something that I'm overlooking in the config. I know it sure looks as if the message originated locally, but I have my doubts - I've been checking the system over very carefully for intrusions and have gone over the log files, but I don't see anything out of the ordinary to suggest that someone has gotten access to a shell. So you are saying that you've checked the qmail-send logs and there is no injection that matches the headers of the bounce? Are you sure? If you found a match, then the uid trail will tell you who did it. Thanks, all, for your speculations so far... Well, if you showed us the headers and corresponding log entries from qmail-send and tcpserver, we wouldn't have to speculate would we now? Surely as a person who administer[s] mail servers for a major ISP you realise the value that concrete data has in reducing speculation. Regards.
Re: Lotsa messages with qmail-remote?
On Wed, May 16, 2001 at 02:38:38PM -0400, John R Levine wrote: I have a spam-like application that will be sending out thousands of customized single-recipient messages. (It's spam-like because it says you wrote to us about on , but unlike spam, they really did write and I have the saved messages to prove it.) Rather than dumping them all into qmail-inject or qmail-queue which would cause constipation unless I install the big-todo patch which is a pain, I was thinking of calling qmail-remote directly, then qmail-queue if qmail-remote didn't work, with a bunch of remotes going at once. The addresses come out of a database and the customization is trivial, so I was planning to write it in perl. (The main bottleneck is the network delays for qmail-remote.) But before I do, has someone already written this? I recently did one of these - it was more designed for mass customized mailings and used a pool of sender servers and a distributed queue - we're talking millions and millions of email per day here... It's a complex system and I haven't the code, but I have some experiences that I can share. I used IO::select to handle running multiple qmail-remotes at the same time. qmail-remote has a really small footprint so you can run 1000s of them concurrently on a modest sized server. It takes a fair amount of code to manage multiplexed pipes in conjunction with handling stdout and stderr (execution errors) responses and exit conditions. (I see that there is an IO::Poll in which case I'd probably use that in preference to IO::Select because of some of the select limit issues on some OSes). The next thing you have to worry about is managing your own queue and retries for delivery failures. This can be much simpler and faster than a full qmail-send type queue of course, such as a single flat file for the whole delivery run with an occassional sync. Bounces of course you'll handle with some sort of VERP address. Having said all that, are you talking less than, say, 10,000 mails? If so, one simple strategy is to inject each mail at the rate of say 1 per second. At that rate 1000 mails are injected in about 16 minutes, ten thousand in a little less than 3 hours. That sort of injection rate should not require bigtodo patches so if you don't mind your delivery script running for 3 hours, then that might be the easiest strategy. Regards.
Re: failure notice
SMTP traffic is completely forgeable. You need to check the logs on your dialin bank to find out who the real identity is. Your modem bank does authenticate and log logins doesn't it? Regards. On Wed, May 16, 2001 at 03:27:17PM -0400, Kirti S. Bajwa wrote: Hi: Somebody is using our company's mail server to send Spam mail. Following is a copy of the bounced message. I have received hundreds of these messages. I have looked into qmail-send logs and find bounced messages but the from address is garbage. It seems that person who is sending SPAM is a regular dial-in customer. For example, the message below, this person logged in as a dial-in customer and was assigned an IP address of 63.113.255.43, which is a valid IP address for the dial-in modem bank. From this message or from qmail-send logs, I can't find out the user id of this person. Is there any way I can stop it or better to find out who this person is (sending SPAM)? Kirti -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 16, 2001 3:17 PM To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at ns2.tibonline.net. I tried to deliver a bounce message to this address, but the bounce bounced! [EMAIL PROTECTED]/A: Sorry, I couldn't find any host named centerfind.com/A. (#5.1.2) --- Below this line is the original bounce. Return-Path: Received: (qmail 21618 invoked from network); 16 May 2001 19:16:59 - Received: from unknown (HELO pavilion) (63.113.255.43) by 63.113.255.3 with SMTP; 16 May 2001 19:16:59 - From: Hahaha [EMAIL PROTECTED] Subject: Snowhite and the Seven Dwarfs - The REAL story! MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=--VEXI78D6Z4DYZC9IVKXQNKPMFW9AR85UF VEXI78D6Z4DYZC9IVKXQNKPMFW9AR85UF Content-Type: text/plain; charset=us-ascii Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... VEXI78D6Z4DYZC9IVKXQNKPMFW9AR85UF Content-Type: application/octet-stream; name=dwarf4you.exe Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dwarf4you.exe TVqQAAME//8AALgAQAAA gLRMzSEA AABQRQAATAECAOAADwELAQAAAFYAABAA AAAQAABQAgAABAAEAACAAgIAABAA ABAAEAAAEBhwAAAo AC50ZXh0AGAQAACoVAIA ACAAAOAucmRhdGEQcAAAWgBYAABAAADA AADr FqhUAABEQUlKSEpMTgARCUhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8XqE1Cifa HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/ lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA Vv+UJHwCAACFwHQcVWiAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW V/+UJMACAACFwA+FQv///8eEJLwCxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT /5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm 90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+It67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg 99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z 9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe AACL0IcEr0Urwi3eiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0llKJk29fhf91Covy ibN06x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0 JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW /7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA
Re: failure notice
On Wed, May 16, 2001 at 09:14:57PM +, Mark Delany wrote: SMTP traffic is completely forgeable. Er, sorry everyone. I didn't realise the original quote had a whole lot of crud in it. On Wed, May 16, 2001 at 03:27:17PM -0400, Kirti S. Bajwa wrote: VEXI78D6Z4DYZC9IVKXQNKPMFW9AR85UF Content-Type: application/octet-stream; name=dwarf4you.exe Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dwarf4you.exe TVqQAAME//8AALgAQAAA Regards.
Re: qmail ignores my sorry ass...
You need to tell us a little more. Well, actually a lot more. How are you trying to send them? qmail-inject, smtp, qmail-queue? If you are running a command such as qmail-inject, what sort of exit code are you getting? Any error message? Do you mean 5600 emails or an email to 5600 addresses? If the latter, are you placing all the recipients on a command line, something like: /var/qmail/bin/qmail-inject recipient1@dom1 recipient2@dom2 ... ? If so, have you perhaps exceeded the maximum length of the command line for your system? Are you perhaps exceeding the maximum number of command line arguments for your system? To check the exit status from the shell, go echo $? immediately after the command. The number is zero if all is well and other numbers indicate different types of errors. Regards. On Wed, May 16, 2001 at 04:37:41PM -0700, Brett wrote: ... when I try to send more than 5600 emails in one go. I mean, it completely ignores me. There's no mention of anything occuring in the logs whatsoever. Since I'm giving you so little to go on here, I'm mostly hoping for a general direction to start looking for a problem rather than a complete solution. Or hopefully this has happened to somebody before and they can tell me what they did to fix it. I've successfully recompiled the kernel and applied the big concurrency patch but not the big-todo one yet. I posted this before but didn't get much of a response except to check qmail-inject's exit status. Assuming I know how to do this, what will this prove? Thanks for any and all help. Brett. A big F you to all the unhelpful flamers in advance.
Re: tcpserver -p and smtpd and DNS
On Mon, May 14, 2001 at 10:10:21AM -, David Killingsworth wrote: I have narrowed this to one simple item. Could someone, possibly you Gerrit I know you have answered one way to get around this I just wanna understand why I have to get around it, explain to me why qmail has delivered an email to me that contains the following header: Received: from unknown (HELO dali.onevision.de) (@212.77.172.50) by mail.myweb.net with SMTP; 14 May 2001 08:59:56 - I have tcpserver -DUvp wrapping smtpd for qmail. Shouldn't tcpserver drop the connection when $TCPREMOTEIP is DNS'd to a hostname and $TCPREMOTEHOST is DNS'd to an IP. if $TCPREMOTEIP can't be resolved or if $TCPREMOTEHOST can't be resolved, shouldn't this cause a FATAL in tcpserver? and it will drop the incoming connection? tcpserver *only* rejects connections if told to do so by the rules supplied with -x or -X. What rules have you tried? You should be able to get tcpserver to drop connections that do not have TCPREMOTEHOST set by putting these entries in your rules: =.:allow :deny Regards. David. On Mon, 14 May 2001 10:51:33 +0200, Gerrit Pape [EMAIL PROTECTED] wrote : On Mon, May 14, 2001 at 06:30:44AM -, David Killingsworth wrote: I have been running qmail for about 8 months, It works great. So far I have not been able to resolve on problem. When an smtp connection comes in we only want to connect with servers who have forward and reverse DNS that match. I allready anwered your question in alt.comp.mail.qmail some days ago. What is wrong with my answer? Gerrit. -- [EMAIL PROTECTED] innominate AG the linux architects tel: +49.30.308806-0 fax: -77 http://www.innominate.com
Re: queue life time
On Mon, May 14, 2001 at 10:54:30AM +, Walid Kassab wrote: Dear All I would like to modify failure notice time queuelifetime to be 14400 ( 4 hours) instead of 604800 ( 7 days) should i just create a file named queuelifetime under /var/qmail/control directory and restart qmail or is there any additional processors I should follow The best way to understand what to do after creating or changing a control file is to find out which commands are affected by the control file. To do this, have a look at the qmail-control manpage. It has a list of every control file and which command uses it. Once you know which command uses queuelifetime it's a simple matter of reading the man page for that command to find out the specifics regarding when that particular command notices the control file. In this particular case, the man page has a whole section called, oddly enough, CONTROL FILES. Regards. regards Walid -- Best Regards Walid Kassab Technical Department Manager Palestinian Internet Services, Co., Ltd. http://www.p-i-s.com Tel. +9708-2843197 Fax +9708-2843377
Re: qmail does not handle timezones properly?
On Sun, May 13, 2001 at 05:47:46PM +0200, Patrick Starrenburg wrote: Code bloat?? Doesn't seem like an excuse to me to (**possibly** we haven't determined this yet) have a fundamental error in a system because someone doesn't feel like adding code to internationalise something. Why do you suggest that there may be a fundamental error in a system? Seems like a pretty unlikely conclusion just because the date is in a format that you don't expect. As it happens this topic has been done to death many times - you may want to check the archives. It is not a bug nor is it a fundamental error in a system. Rather, it is a known and conscious decision by the author and is allowed by the standard. The only way to change this behaviour is for you to patch your version of qmail - I vaguely recall someone announced a patch here, but the archives have a better memory than me. Regards.
Re: qmail does not handle timezones properly? - More Info
Your problem is almost certainly not qmail related. First off you may want to learn how Unix/Linux keeps time. Believe it or not, Unix/Linux don't know anything about timezones. They all keep time internally in UTC (nee GMT). Yes, every Unix server on the planet current has the same time. To see what it is, run this command from the shell: perl -e 'print time,\n' You should get a number back that reflects the number of seconds since 00:00UTC, Jan 1, 1970. When you run something like the date command, it takes this internal number, looks up your current timezone setting and *converts* the internal number to an external representation that matches your timezone. So, what you've shown us with your date command is simply that the combination of the internal time of your server + the timezone setting gives you the correct display. Now, qmail does not do *any* conversion when it generates it's timestamp, it takes the raw internal time value and prints it without looking at any timezone info. So, to answer your question: Received: (qmail 6078 invoked from network); 13 May 2001 **18:56:24** - [[[ Where does 18: come from ??]]] The 18 comes from the internal time value maintained by your kernel. Your kernel believes that it is currently 18:56:24 UTC. If that is not the current UTC time then the internal value in your kernel is set wrong. You can find out what your kernel thinks is UTC by going: TZ=GMT date from your shell. I'll bet that the output from that command matches the date/time in the qmail header. Regards.
Re: qmail does not handle timezones properly? - More Info
On Sun, May 13, 2001 at 06:28:53PM +0200, Patrick Starrenburg wrote: % *Linux box* % [root@linuxbox patrick]# date % Sun May 13 17:02:55 GMT+2 2001 - Check Your clock seems to be set wrong. According to Solaris and at least one web page I dug up, http://www.bsdi.com/date, GMT+2 is a posix time zone equivalent to GMT-0200 (!). Your linux box thinks that you are sitting somewhere in the Atlantic Ocean. Try setting your local TZ to Europe/Amsterdam, and reset your clock. Mark
Re: html based email
On Wed, May 09, 2001 at 09:33:56AM -0500, John Hogan wrote: i was, in a former life, a sysadmin for a major-league list-hosting outfit... no way, no how - don't believe them... it's not possible to float two 'copies' of the message, with reception being dependent on the user's MUA Well, that is, apart from multipart/alternative. Not supported on all MUAs, but it's one way to do it. As an aside, I believe that AOL mail does support HTML, but the idea of doing content on a domain is pretty flawed. Regards. (very difficult to detect on MTA 'send') - also, a lot depends on the end-user's reader -- that's possible to detect (difficult) and absolutely impossible to predict set up two lists: html-listname and text-listname - have your users state their preference when they subscribe - hogan At 08:49 AM 5/9/2001, Meuse, Andy wrote: Hey All, Is there a way anyone knows of to send one email in both html and plain text format? This is so the recipient will get the html version if their mua supports it, and the plain text version if it doesn't. I know of a service that does this, www.roving.com, but don't know of a way to do it myself. Except scripting my mailing list to send only plain text to like AOl and other domains I know don't support html. Thanks, Andy _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: mailing list
On Wed, May 09, 2001 at 11:28:16AM -0700, ed lim wrote: Hi, I need a mailing list to send to our millions of subscribers... I am already using ezmlm but I'm still open for suggestions on a much simpler or better one. Any specifics on what constitutes simpler or better? You'll be hard pressed to find anything simpler or better than ezmlm, btw. You may want to look at ezmlm-idx for increased functionality. Regards.
Re: Mail Stuck in Queue
Is qmail running? What does ps aux | grep qmail show? (Or whatever ps is appropriate for your OS?) Regards. On Wed, May 02, 2001 at 09:30:17PM -, Aaron Goldblatt wrote: After resolving the POP slowdown issue with the help of some of the more polite folks here, I have developed a new problem. All mail that gets queued for delivery simply sits in the queue and doesn't get delivered. It doesn't matter if the mail is for local delivery, or is relay mail headed for a remote mail server. What I am aware of changing: I added -R and -H to tcpserver's command line, and I added my 10.x.x.x network to tcp.smtp.cdb. I can now deliver mail via SMTP to rblsmtpd, and it does queue the mail, so I doubt the issue is in my tcp connection rules. I am accepting connections with rblsmtpd with the no-TXT-records patch, and logging is being done by splogger to /var/log/messages. There are no messages indicating anything related to qmail in syslog since the issue began, except for one notation where rblsmtpd rejected a message from a black holed site. The line invoking rblsmtpd is (beware wordwrap): /usr/local/bin/tcpserver -R -H -x /etc/tcprules/tcp.smtp.cdb \ -u 1004 -g 2108 0 smtp /usr/local/bin/rblsmtpd -r blackholes.mail-abuse.org \ -r dialups.mail-abuse.org \ -r 'relays.mail-abuse.org:Open relay problem - see URL:http://www.mail-abuse.org/cgi-bin/nph-rss?%IP%' \ /var/qmail/bin/qmail-smtpd 21 | /var/qmail/bin/splogger smtpd 3 I can see messages queueing in /var/qmail/queue/mess/*, but they are not delivered either locally or to a remote host (mail.swbell.net). Through testing with other mail servers, I have determined that mail.swbell.net is operating normally -- it both sends and receives mail. I've sent test messages to my problem machine via mail.swbell.net and found them in my queue, waiting for local delivery. /var/qmail/queue/lock/trigger has permissions as described in LWQ. The home directories of the users on the system are owned by themselves. Some are world-readable, some are not. None are world-writable: drwx-- 5 aaronusers4096 Feb 24 07:37 aaron drwx--x--x 5 bluerose users4096 Feb 24 07:37 blueroses drwx--x--x 5 boby users4096 Apr 11 21:32 boby drwx--x--x 5 dhwork users4096 Mar 16 01:48 dhwork drwx--x--x 5 djh users4096 Feb 24 07:38 djh drwx--x--x 5 dnslog users4096 Mar 24 08:25 dnslog drwx--x--x 5 ebay users4096 Feb 24 07:38 ebay drwx--x--x 5 friendof users4096 Feb 24 07:39 friendofbillw drwx--x--x 5 gtg users4096 Mar 29 09:37 gtg drwx--x--x 5 listsusers4096 May 2 12:44 lists drwx--x--x 6 netgeek users4096 Apr 13 21:37 netgeek drwx--x--x 6 rc5 users4096 Feb 25 08:56 rc5 drwx--x--x 17 rnbwpnt users4096 Apr 29 05:56 rnbwpnt drwx--x--x 6 shewolf users4096 Apr 23 18:42 shewolf drwx--x--x 5 shik users4096 Feb 24 07:41 shik drwx--x--x 5 thesaint users4096 May 2 14:24 thesaint drwx--x--x 5 vendors users4096 Feb 24 07:42 vendors drwx--x--x 5 viquiusers4096 Feb 24 07:42 viqui This is the output from qmail-showctl: qmail home directory: /var/qmail. user-ext delimiter: -. paternalism (in decimal): 2. silent concurrency limit: 120. subdirectory split: 23. user ids: 1003, 1004, 1005, 0, 1006, 1007, 1008, 1009. group ids: 2108, 2107. badmailfrom: (Default.) Any MAIL FROM is allowed. bouncefrom: (Default.) Bounce user name is MAILER-DAEMON. bouncehost: (Default.) Bounce host name is wndrgrl.goldblatt.net. concurrencylocal: (Default.) Local concurrency is 10. concurrencyremote: (Default.) Remote concurrency is 20. databytes: (Default.) SMTP DATA limit is 0 bytes. defaultdomain: Default domain name is goldblatt.net. defaulthost: Default host name is goldblatt.net. doublebouncehost: (Default.) 2B recipient host: wndrgrl.goldblatt.net. doublebounceto: (Default.) 2B recipient user: postmaster. envnoathost: (Default.) Presumed domain name is wndrgrl.goldblatt.net. helohost: (Default.) SMTP client HELO host name is wndrgrl.goldblatt.net. idhost: (Default.) Message-ID host name is wndrgrl.goldblatt.net. localiphost: (Default.) Local IP address becomes wndrgrl.goldblatt.net. locals: Messages for localhost are delivered locally. Messages for wndrgrl.goldblatt.net are delivered locally. Messages for virtualhost.goldblatt.net are delivered locally. Messages for goldblatt.net are delivered locally. me: My name is wndrgrl.goldblatt.net. percenthack: (Default.) The percent hack is not allowed. plusdomain: Plus domain name is goldblatt.net. qmqpservers: (Default.) No QMQP servers. queuelifetime: (Default.) Message lifetime in the queue is 604800 seconds. rcpthosts: SMTP clients may send messages to recipients at goldblatt.net. SMTP clients may send
Re: I messed up my QMQP Client Config...
On Tue, May 01, 2001 at 10:12:36PM -0700, Tyrone Mills wrote: Hello All, I made a stupid mistake and left a QMQP Client machine with a bad IP in the qmqpservers file. I'm re-reading the Installing mini-qmail doc on http://cr.yp.to/qmail/mini.html and if I am reading it correctly, I'm screwed when it comes to getting those messages back. Am I right? Correct. It's the same as qmail-inject returning a non-zero exit code. The client that sent the mail should have noticed the failed injection and kept the original and alerted the user. There was only about 10 messages that should have been generated today and I can grab the info out of the MySQL DB and manually generate the E-Mails, but I'd like to know, more from a learning perspective than anything. It sounds like you are using a script to create/inject the emails. Maybe that script should pay closer attention to the exit code of whatever program it is using to inject the email. Regards.
