Re: Drive out of space
On Mon, Aug 13, 2001 at 02:55:35PM +0100, John Portwin allegedly wrote: Our /var drive partition ran completely out of space earlier; it houses the queue and the logs. /home is on a different partition, and has plenty of space. A quick rm -rf sorted that one out, and a new drive is on its way in, but.. How would this have affected qmail? Could we have lost any mail, or would it be deferred (to our secondary MX)? You will not have lost any mail that comes via qmail-smtpd. Whether these attempted deliveries were deferred or sent to your secondary MX is a decision that the sending end makes. Probably a mixture of both. One issue that this sort of problem brings up is that very few scripts/local programs properly check the results of an email submission via qmail-inject (or the sendmail wrapper). So, if you had scripts or cronjobs that submitted mail during that time, that mail may have never made it to the queue. Regards.
Re: qmail-queue question
3. When the queue shows the message arriving on 30 Jul 2001 15:08:23 I tend to think that it actually arrive at 3:08 on Jul 30 of 2001, that is unless qmail is doing something funking with date and time stamps. ;) But you didn't show the log entry that corresponds to this message. As a consultant with 8 years experience you have probably deduced that *all* messages inserted into the queue create a new msg log entry. Where is it? 5. To get the logs I went to /var/log/qmail/send and did a grep on the message id number like so: grep 112535 * If you know something I don't know, then please tell me, but as far as I How long does the system keep the logs for? Has it been rolled off by, eg, newsyslog? Any real help on this issue would be appreciated from anyone. We want all the log entries associated with the message. If your log system has rolled them off, then stop the log rolling so you can retain all the information. Then pick an example that shows us the full life-cycle of the message and how it exceeds queuelifetime after the last delivery attempt. It may simply be that the delivery program is not exiting. It's only at the point that qmail-send looks at queuelifetime. Regards.
Re: qmail-queue question
On Thu, Aug 09, 2001 at 12:39:28PM -0500, Edward McLain allegedly wrote: -Original Message- From: MarkD [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 12:23 PM To: [EMAIL PROTECTED] Subject: Re: qmail-queue question 3. When the queue shows the message arriving on 30 Jul 2001 15:08:23 I tend to think that it actually arrive at 3:08 on Jul 30 of 2001, that is unless qmail is doing something funking with date and time stamps. ;) But you didn't show the log entry that corresponds to this message. As a consultant with 8 years experience you have probably deduced that *all* messages inserted into the queue create a new msg log entry. Where is it? There was no new msg log entry. Best I can tell the logs only go back maybe 3 or 4 days and the messages originated 9 days ago.. Thus the problem. It probably would have been helpful if you'd told us about this at the start. It seemed like you were trying to suggest that the log entry never existed. I guess that's a lesson for next time. I took Richard's advice and added the socket keep-alive patch and that actually seems to have fixed the problem. The old messages seemed to have mysteriously disappeared after replacing the qmail-remote exec. Mysteriously? Since we've stressed the importance of looking at logs for answers, I'm sure you've checked the logs to solve the mystery. What did they say? I'm sure if you bother, you'll see that it's not a mystery at all. Unless of course you kill -9 qmail-send, but no one or no docs have ever told you to do this, right? In any event, as I said in the the last post; queuelifetime applies *after* the last delivery attempt has exited. It's almost certainly the case that you killed qmail-remote (or it exited of its own accord) at which point qmail-send would notice that queuelifetime is exceeded and bounce the mail. The logs show this stuff by the way. Not to start anything else, but is there any better way to stop qmail when using tcp-daemonts than svc -d /service/qmail-send ? This doesn't seem to always work and I can't ever seem to get all the It always works. But qmail-send won't exit until all current deliveries have exited - in fact it logs an entry each time an outstanding delivery completes. Did you see different when you checked the logs? If so, show us. Edward, for someone with 8 years experience, you should rejoice that so many of your mysteries and misunderstandings can be solved by examining and understanding the logs. If the log messages are a mystery to you, there are plenty of archived posts explaining the messages. Regards.
Re: qmail-queue question
Ok.. so as someone pointed out I have to now search by the deliver number.. So I ran: [root@mail send]# grep delivery 366 * | /usr/local/bin/tai64nlocal 2001-08-09 13:41:28.533103500.s:@40003b72c36a2839ff1c starting delivery 366: msg 112603 to remote [EMAIL PROTECTED] [root@mail send]# Ok.. so the last attempt started at 1:41PM.. So what happened to the one before it? [root@mail send]# grep delivery 26: * | /usr/local/bin/tai64nlocal 2001-08-09 10:17:31.319774500.s:@40003b72a32e0b08b30c starting delivery 26: msg 112603 to remote [EMAIL PROTECTED] 2001-08-09 13:41:28.533103500.s:@40003b72c33a3620be2c delivery 26: deferral: qmail-remote_crashed./ [root@mail send]# Ok.. so qmail-remote crashed.. but why? Unless something very unusual is happening to your system, I'd say that someone or something killed it. An unpatched qmail-remote has no record of crashing in the last, oh, 3 years of people using it. It had also been running for over 3 hours? That's not necessarily a problem. Mail is allowed to get stuck. Is any mail getting thru to these sites or are they all failing? Well to test it out I did the following: [root@mail qmail]# telnet mx09.mindspring.com 25 Trying 207.69.200.36... Connected to mx09.mindspring.com. Escape character is '^]'. 220 pickering.mail.mindspring.net EL_3_4_0 /EL_3_4_0 ESMTP Earthlink Mail Service Thu, 9 Aug 2001 16:20:40 -0400 (EDT) helo mail.highspd.net 250 pickering.mail.mindspring.net Hello mail.highspd.net [208.62.90.230], please to meet you mail from: [EMAIL PROTECTED] 250 [EMAIL PROTECTED] Sender ok rcpt to: [EMAIL PROTECTED] 250 [EMAIL PROTECTED]... Recipient ok data 354 Enter mail, end with . on a line by itself this is a test. please disregard . 250 tn5s62.1dc.37kbi14 Message accepted for delivery quit 221 pickering.mail.mindspring.net closing connection Connection closed by foreign host. Ok.. so I can send mail directly just fine.. So what in the heck is going on here? This is what is puzzling me the most..? Hard to say. It could be that the contents of the mail are a problem for mindspring, are they large? Do they have binary data? It could be that qmail-remote is connecting to an MX that's particularly slow or dead. It could be that you have an smtproutes entry for that domain that points incorrectly. BTW.. this was happening with stock qmail also before I patched it with the qmail-queue patch for qmailscanner. If you are saying you are sure that qmail-remote was crashing with a stock qmail install, then I'd be highly suspicious of a library/compiler/OS problem. I know that might sound like a cop-out, but a crashing qmail-remote is virtually unheard of. It's also possible that there is some sort of system resource that is becoming unavailable causing the kernel to kill the qmail-remote. Does this happen to all qmail-remotes or only those sending to mindspring? Does it happen to all qmail-remotes or only those that run for a long time? If you can reliably determine which ones are going to crash in advance of them crashing, then do a system call trace on one of them to see why it's dying. Show us the trace. Regards.
Re: Can anyone explain this?
pm0.net are a notorious spammer. They presumably are spamming many invalid users at this site. The saving grace is their IP address can be determined and tcpserver (deny) is your friend. Regards. On Wed, Aug 08, 2001 at 03:34:44PM +, eric allegedly wrote: The following is something I've noticed as a recurrent problem that I'm having. qmail-send processes just seem to get stuck. I assumed they were waiting on a response from a slow MX, but in order to try to avoid this I have set /var/qmail/control/timeouremote to 180 seconds $ date ; ps ax | grep qmail-remote | grep -v grep Wed Aug 8 08:51:45 CDT 2001 18813 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 27933 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 30405 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 5784 ?S 0:00 qmail-remote hmr.pm0.net [EMAIL PROTECTED] 9924 ?S 0:00 qmail-remote msn.com [EMAIL PROTECTED] 10980 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] $ date ; ps ax | grep qmail-remote | grep -v grep Wed Aug 8 09:19:27 CDT 2001 18813 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 27933 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 30405 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 5784 ?S 0:00 qmail-remote hmr.pm0.net [EMAIL PROTECTED] $ ps ax | grep qmail-send 688 ?S 20:37 qmail-send 13381 pts/5S 0:00 grep qmail-send $ sudo kill -ALRM 688 $ date ; ps ax | grep qmail-remote | grep -v grep Wed Aug 8 09:21:21 CDT 2001 18813 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 27933 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 30405 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 5784 ?S 0:00 qmail-remote hmr.pm0.net [EMAIL PROTECTED] 13314 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] 13376 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] 13398 ?S 0:00 qmail-remote hmr.pm0.net [EMAIL PROTECTED] 13408 ?S 0:00 qmail-remote usa.com [EMAIL PROTECTED] 13442 ?S 0:00 qmail-remote newsletter.ourhouse.com OurHouse.com___ 13462 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] 13479 ?S 0:00 qmail-remote anon.lcs.mit.edu [EMAIL PROTECTED] mail 13483 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] 13495 ?S 0:00 qmail-remote yaho.com [EMAIL PROTECTED] play4money@ya 13503 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] 13512 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] 13531 ?S 0:00 qmail-remote norman.bay9.com [EMAIL PROTECTED] $ date ; ps ax | grep qmail-remote | grep -v grep Wed Aug 8 09:40:48 CDT 2001 18813 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 27933 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 30405 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 5784 ?S 0:00 qmail-remote hmr.pm0.net [EMAIL PROTECTED] ~$ date ; ps ax | grep qmail-remote | grep -v grep Wed Aug 8 10:22:42 CDT 2001 18813 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 27933 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 30405 ?S 0:00 qmail-remote ofr.pm0.net [EMAIL PROTECTED] 5784 ?S 0:00 qmail-remote hmr.pm0.net [EMAIL PROTECTED] The four processes that I'm worrried about are 18813, 27933, 30405, and 5784. They've been active for about 2 hours and maybe longer (who knows how long they had been running when I started this log). Anyone else seeing similar stuff happening? I'm running qmail-1.03 without any patches under RedHat 6.1 (kernel 2.2.12-20smp) Eric Calvert
Re: Fix for qmail-remote process hanging on Linux (and possibly o ther s)
On Mon, Aug 06, 2001 at 02:17:22PM +0100, Richard Underwood allegedly wrote: And if you don't like this behaviour: write a patch (or find one), or stop using qmail. Nobody is forcing you to use qmail. Perhaps, but using this list to tell people (often quite forcefully) that the behaviour they are experiencing is as it should be, and it's the rest of the world that's broken, and that qmail is perfect already isn't going to encourage anyone to help. If I had the time, I'd write a patch. I wouldn't do it without discussing it on a mailing list first, though ... Has it been suggested/done before? Does anyone have any suggestions for better algorithms? What features would people want? Has this been discussed before? Yes. Endlessly. Check the archives. You are breaking no new ground here at all. I wonder how many other people have been put off like that? Only those who make technical decisions based on the personality of some random Joe on a mailing list. If you're put off doing something by the comment of a complete stranger on the net, then you're going to have a lot of free time on your hands. I think I've been quite reasonable with the messages I've sent. I've said that I like qmail numerous times. I've said I want to improve it ... and people have told me it needs no improvement. I simply think that this is short-sighted. I'll leave you all alone now. If you want to be truly helpful, you might want to read the archives on this matter and then suggest/do something beyond what has been already been discussed ad nauseum. Regards.
Re: Fix for qmail-remote process hanging on Linux (and possibly o ther s)
On Tue, Aug 07, 2001 at 12:05:12PM +1200, Jason Haar allegedly wrote: On Mon, Aug 06, 2001 at 02:16:00PM +0200, Peter van Dijk wrote: On Mon, Aug 06, 2001 at 01:07:36PM +0100, Richard Underwood wrote: When the exchange server comes back up, I kick the qmail-send process to get it to deliver the queue. At this point I should be able to go off and do other things. Why are you kicking qmail-send? That should never be necessary in a production environment. It is absolutely necessary. We have exactly the same issue here. Exchange goes down. Mail backs up on Qmail servers. Exchange comes back up. USERS ARE TOLD ITS WORKING AGAIN. Users then wonder why it takes up to 2 hours for queued mail to get to them. USERS COMPLAIN THAT SOMETHING IS WRONG. One wonders what your users think of the Exchange server? Love it do they? Be that as it may, if Exchange is that unreliable, why not change your qmail server to send to it via serialmail? You'll then get the desired effect. Trigger it once a minute out of cron or some such. Just watch out for the possibility of two serialmails running concurrently on the same Maildir, I recall that djb put locking in to protect against this, but it may not be immediately obvious. Reality is that some things are better at some things than others. Wow - there's a shocker :-) Yeah and qmail can work around unstable Exchange servers. Wow! Regards.
Re: Flame Bait: Using Qmail as a front-line mail server
1. Is it possible to list the Qmail server as the primary MX record and still forward the mail to its final destination? All my research says no, but I need to be certain. It's trivial. smtproutes is your friend. 2. If #1 is possible, could your generously provide some real world suggestions on how this can be done? It'd be helpful to know the real names of the domains and machines involved, then we could give you a real world config entry, but assuming the MX domain is example.com and the ultimate mail server running sendmail is sendmail.example.com, then: echo example.com:sendmail.example.com /var/qmail/control/smtproutes No restarts are needed. Just change your MX to point to the qmail machine and you're done. Of course you need to make sure that example.com isn't in locals and virtualdomains. It'll be interesting to know how you plan to catch Sircam with this though... Regards.
Re: Dial-up Fails to Connect to SMTP Server
Is your ISP blocking port 25 outbound traffic? What happens if you try to telnet directly to those smtp servers, eg: telnet serveraddress 25 Numerous ISPs only let you send outbound SMTP via there SMTP server as a measure against spammers - if that's the case with you then you'll need to look into smtproutes. Regards. On Thu, Aug 02, 2001 at 04:14:26PM -0400, Jeff Hill allegedly wrote: I know this is not strictly a qmail problem, but . . . Dial-up connections (using Outlook Express 5.00) can no longer connect to the SMTP server to send out e-mail (repeatedly times out), but nothing has been changed on the server or dial-up machines. There is no problem with dial-ups connecting to cucipop to pick-up mail, and all other Internet connections work fine on dial-up machines. Mail sent directly from the server works without any visible problems. The only thing I see in the qmail-send logs is quite a few I_wasn't_able_to_establish_an_SMTP_connection, but the mail seems to go through eventually. I did recently upgraded to use rblsmtpd. I'm using supervise for qmail-send, running ucspi-tcp 0.84; qmail 1.03, Debian potato [kernel 2.2.19]. There isn't a heavy load of traffic: Qstat currently says there are 28 messages in queue, 0 not yet preprocessed. Thanks for any leads. Best Regards, Jeff Hill
Re: TLS implementation.
On Wed, Aug 01, 2001 at 06:34:53PM -0400, McHugh, Sean allegedly wrote: However, after thinking about it. I send and recieve over 75000 messages a day. I do not want to use TLS indiscriminately for every SMTP host. I have only a few places to send to where mail _needs_ to be encrypted. so how do _selectively_ tell qmail to use tls for certain hosts and not others ? and how do i tell qmail to use normal SMTP for everyone, but force TLS for certain smtp servers sending in ? MMDF has this functionality. Remember, this is a patch to qmail, not part of qmail proper. I don't believe the patch has the capability you ask for. Have you considered contacting the author of the patch? If they can't help you, and this is important to you, then you may have to use MMDF. Regards. PS. I'm on the list so I don't need a separate copy of this email. sean -Original Message- From: MarkD [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 31, 2001 4:38 PM To: '[EMAIL PROTECTED]' Subject: Re: TLS implementation. TLS negotiated after the connection is established (basically they send STARTTLS and take note of the response code). You should not need to configure anything. What makes you think you need to do this? Regards. On Tue, Jul 31, 2001 at 04:24:53PM -0400, McHugh, Sean allegedly wrote: We almost have qmail with TLS.patch working on Solaris 8 (x86). Server allows starttls command and patch installed fine. We are a little stuck at the point where we specify what host we want qmail-remote to invoke TLS for and what hosts we want qmail-smtpd to force to use TLS in sending to us. The patch documentation is not clear on how this is done. Can anyone give me clue ? Is there a HOW-TO:Qmail/TLS for dummies like us ? sean
Re: Problems with qmail-remote hanging
Setting an alarm is a nasty hack in my opinion, but I have to admit that it's something I considered. Well, the qmail-remote connection is well and truly wedged once it's in this state and if the select() timed out as it's meant to, qmail-remote would exit with a delivery failure indication, so it's not that bad a hack. It's also very easy to code - just a single alarm() call at teh top of main(). A slightly neater solution might be to use the SO_KEEPALIVE socket option - if it works (and there isn't a good reason not to use it) that is. It'll be interesting to hear if this works. What would be better is finding out why this happens, of course. Indeed. Does Linux offer tools/syscalls that would tell you why the select worked, but the read failed? P.S. If anyone is keeping track, Linux 2.2.19, concurrencyremote set to 200 I hesitate to say this, but Linux kernels seem to predominate in this regard, but that just may be that qmail is running on more Linux out there than other Unixen. Regards.
Re: TLS implementation.
TLS negotiated after the connection is established (basically they send STARTTLS and take note of the response code). You should not need to configure anything. What makes you think you need to do this? Regards. On Tue, Jul 31, 2001 at 04:24:53PM -0400, McHugh, Sean allegedly wrote: We almost have qmail with TLS.patch working on Solaris 8 (x86). Server allows starttls command and patch installed fine. We are a little stuck at the point where we specify what host we want qmail-remote to invoke TLS for and what hosts we want qmail-smtpd to force to use TLS in sending to us. The patch documentation is not clear on how this is done. Can anyone give me clue ? Is there a HOW-TO:Qmail/TLS for dummies like us ? sean
Re: Problems with qmail-remote hanging
I've been running qmail on a number of platforms quite happily for a while - until now I've had no problems at all. However, I am now experiencing a problem with qmail-remote hanging. The problem I see is with qmail-remote failing to terminate when a connection times-out. If left alone, the number of stuck processes will slowly climb, after about a month I had about 25 such processes. The network connections remain in the ESTABLISHED state. Looking at the process list right now, I have one stuck: # ps -ef | grep qmail-remote qmailr 12278 662 0 13:13 ?00:00:00 qmail-remote xx.co.uk xx qmailr 19876 662 0 16:09 ?00:00:00 qmail-remote xx.com root 19912 19489 0 16:10 pts/000:00:00 grep qmail-remote # strace -p 12278 read(3, unfinished ... ... all socket read()s in qmail-remote should be protected by a select and therefore should not block as this one is doing now. After recompiling with debugging and symbols, I get ... Exactly. This problem's been reported before. If your OS says that an fd is readable via select(), then the read() should not block. As you observe though, the read is blocking so your OS is probably not telling the truth when it returns from the select(). The archives have plenty of discussion on this and the simplest solution is to put a large-value alarm() handler in qmail-remote. No one as yet seems to be able to narrow down which OSes do this and under what circumstances. Regards.
Re: Fastforward question (was Re: Mail Forwarding Service)
On Sat, Jul 28, 2001 at 09:35:32PM +0800, Adrian Ho allegedly wrote: On Sat, Jul 28, 2001 at 07:28:04AM -0400, Philip Mak wrote: I wonder if in the future, they'll make an alias delivery option in qmail; that is, it calls an external program, but instead of sending the entire message to the program, it just sends the RCPT TO: address to the program and the program returns to it which mailbox(es) should be delivered to. That's trivially done today -- no extra options required: |forward `my-redirector $RECIPIENT` Nope. You cut too much out of the original posting. He said: So it would still have the overhead of having to read a message from qmail, and then write that message back to qmail. That overhead would be unavoidable if I'm doing program delivery, I guess. In other words he doesn't want each mail to go thru the queue twice as your solution implies. To answer Philip's question: Yes, that overhead is unavailable as there is no standard qmail solution for redirecting mail without it going thru the queue at least once. Having said that your concern about overhead may be misplaced. What sort of volume are you expecting on what sort of system? Regards.
Re: Fastforward question (was Re: Mail Forwarding Service)
That's not what he means. This still reads the message and reinjects it. His proposal (which I have been pondering about for months already :) means that a program can tell qmail 'send this mail you are trying to give to me, to this address' without reinjection. This could save a lot of disk bandwidth, IMHO. The qmail architecture does not lend itself well to this though does it? qmail-remote is the only code that knows how to remotely deliver a message and qmail-smtpd would have to be (extensively) modified to call that instead of qmail-queue. It would have been a cute touch if DjB had made the interface to qmail-remote the same as qmail-queue. In fact, one wonders whether all the inter-program delivery of mail in qmail should use some sort of common protocol such as that used by qmail-remote. Better yet would be to universally use QMTP/QMQP between programs. Anyway, even overcoming the interface obstacles, you have the nasty problem of inbound multiple recipients to deal with. qmail-remote only handles multiple recipients if they all happen to be going to the same domain. You could simply punt to qmail-queue of course if there is more than one recipient, but now it's starting to get messy as your delivery paths will be substantially different for the same recipient simply depending on whether they are part of an inbound multiple recipient mail or not. Regards.
Re: Fastforward question (was Re: Mail Forwarding Service)
24000 total users on a Pentium III 850MHz with 768 MB of RAM (not sure how many are active though...at least a couple thousand). By volume I meant how many emails per hour. Number of users is largely irrelevant. Upon activating this system, the load average of the machine has increased from 1-2 to 10! I suspect most of the time is being spent compiling the perl script and connecting to the MySQL database, though. If I switch to If you're doing this per delivery, I'm not surprised. But it should be easy to measure for sure with vmstat/top/acct, etc. fastforward (or if I rewrite the script in C, and use a persistent database connection handle somehow, maybe by storing it in an flock'd file) maybe the load average will drop back down to normal. Maintaining a persistent connection across multiple local deliveries is possible with some skull-hackery and a cooperating peer process, but it's not easy, it's not possible using flock and it does raise the issue of multiple deliveries using the same connection at the same instant. Tell us more about the deliveries? How many per hour, what is your concurrencylocal? Are the deliveries keeping up? An unadulterated snapshot of your qmail log would tell us a lot. At this stage, periodic rebuilding of a fastforward file sure sounds easiest - perhaps triggered by database changes. Regards.
Re: Fastforward question (was Re: Mail Forwarding Service)
The qmail architecture does not lend itself well to this though does it? qmail-remote is the only code that knows how to remotely deliver a message and qmail-smtpd would have to be (extensively) modified to call that instead of qmail-queue. You are missing the point. We are just saying that a program invoked by qmail-local should have a way to communicate back to qmail 'change the address to blah', instead of having to reinject it. This would then still happen for every recipient like it does now. Ug. That's even harder and it saves less than half of your queuing costs! That approach means that the message changes from a local to a remote delivery - the queue structure does not lend itself to making this change easily without incurring most of the cost of a queue injection. It also likely that the length of the recipient address will change - again the queue structure is poorly suited to this for multiple recipient emails as recipients are stored as a series of \0 terminated strings. It'll be interesting to see how you propose to atomically make such queue changes while incurring a worthwhile queueing cost saving. Regards.
Re: Fastforward question (was Re: Mail Forwarding Service)
My rough guess (see grep | wc above) is 7000 deliveries per hour. About 2 a second, that's not huge, but it's starting to get busy when you have to invoke multiple programs and establish a socket each time to your database. I see status: local 10/10 a lot. It goes back down in a few seconds, then can come back up in a few seconds too. (Should I increase concurrencylocal?) No. quite the opposite if anything. Think of concurrencylocal as a peak load that you want qmail to impose on your database - or your local file system for that matter. Do you really want to have more than 10 concurrent connections to your database? Better to keep that number safely within the capabilities of your system. I suspect that 10 is a good starting point for your delivery rates and it's much better to have an occassional local delivery delayed than to grind your database into dust. |forward `database-lookup $RECIPIENT` where database-lookup is a simple C program that connects to MySQL, looks up the recipient in the database, and prints it to standard output. This would be easy to write. It might not be as efficient as fastforward due to having to open a new connection to MySQL every time, but if it's efficient enough I think it's better because then (1) the database is always in perfect synch and (2) I don't have to worry about cron jobs to synchronize the fastforward db with the MySQL db. I'll have to try it and see what happens. That sounds like a good plan. Regards.
Re: Fastforward question (was Re: Mail Forwarding Service)
On Sat, Jul 28, 2001 at 02:22:25PM -0400, Philip Mak allegedly wrote: On Sat, 28 Jul 2001, Peter van Dijk wrote: I am not familiar with the internals of qmail, but from what I have seen, this would make sense. Yes. This program could then just talk to /var/qmail/bin/qmail-queue itself, or talk to /var/qmail/bin/forward. Oh, so you're saying if e.g. on mydomain.com I have the file .qmail-pmak that says: [EMAIL PROTECTED] and someone sends e-mail to [EMAIL PROTECTED], the message actually gets injected twice into qmail---first time to send to [EMAIL PROTECTED], then qmail re-injects it again for delivery to [EMAIL PROTECTED]? Yep. The way to do this optimally is to have a program that does the lookup and then execs /var/qmail/bin/forward (or possibly qmail-queue for a minor performance gain). Regards.
Re: Possible degenerate case in trigger handling?
A second and more defensive measure is to issue a non-blocking read on
the pipe to drain all qmail-queue bytes *prior* to the todo
This is the solution I eventually used. Works like a charm. I've
appended the patch so that it gets into the archives. Variations from
the original post include opening the trigger file just the once as
well as setting it non-blocking at the time it's opened. I've called
it the trigger-happy patch :
Regards.
*** Makefile.orig Mon Jun 15 03:53:16 1998
--- MakefileFri Jul 27 11:23:47 2001
***
*** 2114,2120
./compile token822.c
trigger.o: \
! compile trigger.c select.h open.h trigger.h hasnpbg1.h
./compile trigger.c
triggerpull.o: \
--- 2114,2120
./compile token822.c
trigger.o: \
! compile trigger.c select.h open.h trigger.h hasnpbg1.h ndelay.h
./compile trigger.c
triggerpull.o: \
*** trigger.orig.c Mon Jun 15 03:53:16 1998
--- trigger.c Thu Jul 26 18:02:07 2001
***
*** 1,4
--- 1,5
#include select.h
+ #include ndelay.h
#include open.h
#include trigger.h
#include hasnpbg1.h
***
*** 10,24
void trigger_set()
{
! if (fd != -1)
!close(fd);
! #ifdef HASNAMEDPIPEBUG1
! if (fdw != -1)
!close(fdw);
! #endif
! fd = open_read(lock/trigger);
#ifdef HASNAMEDPIPEBUG1
! fdw = open_write(lock/trigger);
#endif
}
--- 11,25
void trigger_set()
{
! if (fd == -1)
! {
!fd = open_read(lock/trigger);
!if (fd != -1)
! ndelay_on(fd);
! }
#ifdef HASNAMEDPIPEBUG1
! if (fdw == -1)
!fdw = open_write(lock/trigger);
#endif
}
***
*** 36,41
int trigger_pulled(rfds)
fd_set *rfds;
{
! if (fd != -1) if (FD_ISSET(fd,rfds)) return 1;
return 0;
}
--- 37,48
int trigger_pulled(rfds)
fd_set *rfds;
{
! char buf[64];
!
! if ((fd != -1) FD_ISSET(fd,rfds))
! {
!while (read(fd,buf,sizeof(buf)) == sizeof(buf)) ;
!return 1;
! }
return 0;
}
Re: Proper way to run multiple qmail-smtpd
On Fri, Jul 27, 2001 at 06:17:09PM -0400, Hubbard, David allegedly wrote: Hi all, can someone tell me what the proper way to run multiple instances of tcpserver to have qmail-smtpd listen to multiple IP's? I realize that a 0 to tcpserver will cause it to listen to all addresses but I need to only listen to a few. I have a working qmail install on the box in question based on lifewithqmail and I'm thinking that just recursively copying the /var/qmail/supervise/qmail-smtpd directory qmail-smtpd1, qmail-smtpd2, etc. and editing the run files to use the correct IP's for tcpserver would be good enough, just wanted to check though. I'd obviously want to adjust my concurrencies too. That's pretty much it - just don't forget that you need unique logging directories too. Regards.
Re: stunnel
On Thu, Jul 26, 2001 at 02:44:17PM +0200, Per-fredrik Pollnow (EPK) allegedly wrote: Hi, I was wondering if there is anyone(probebly someone) who is using stunnel for the qmail-pop3d server. I get this error message on the server all the time when I tray to connect to my pop3d on port 995 with my SSL client. I start the stunnel like this: /usr/local/sbin/stunnel -p /etc/stunnel.pem -l /var/qmail/bin/qmail-pop3d Maildir 21 -f -d 995 And this is the screenshot from the foreground mode: 2001.07.26 15:24:31 LOG5[27215:73728]: Using 'qmail-pop3d Maildir 21' as tcpwrapper service name 2001.07.26 15:24:31 LOG5[27215:73728]: stunnel 3.16 on i386-unknown-openbsd2.9 PTHREAD+LIBWRAP 2001.07.26 15:25:58 LOG5[27215:75776]: qmail-pop3d Maildir 21 connected from 136.225.42.196:4497 2001.07.26 15:25:58 LOG3[27961:75776]: execvp: No such file or directory (2) 2001.07.26 15:29:32 LOG3[27215:77312]: SSL_accept: Peer suddenly disconnected 2001.07.26 15:29:32 LOG3[27215:75776]: select: Interrupted system call (4) 2001.07.26 15:29:32 LOG5[27215:75776]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket I'm using qmail on OpenBSD2.9.. Anyone who knows what's wrong? Yes. You need to read the stunnel documentation more closely. Especially look at the examples in the stunnel man page and note how the command and arguments after -l are constructed. Also note how they have to be the last arguments on the command line. qmail-pop3d works just fine with stunnel - if you get the stunnel invocation right. Regards.
Re: pop3d
On Fri, Jul 27, 2001 at 09:19:43AM +1000, Vivian Doherty allegedly wrote: I was able to get 45/50 connections using telnet, so I don't think this is the problem. Good. It's a process of elimination. So your concurrency does not appear to be limited by system resources. I tried to put the -l option into the pop3d run script, all users starting getting error messages and could not connect to the server. What -l option on what command, where? What exactly does the startup script look like. I am running Redhat7 with qmail and vmailmgr. This only happens every so often, the network slows to a crawl and everybody has problems connecting to At the time that the problem occurs, can you connect to the pop server with telnet? Can you do this from the pop server and from another system on the LAN? the mail server receiving time-out errors. Even the internal network slows down. Any help would be appreciated. Sounds like you have other issues going on here that aren't related to qmail. Regards.
Possible degenerate case in trigger handling?
(I originally found this problem on a very busy FreeBSD 4.3 system
running with the bigtodo patch - it is much less likely to occur with
a standard qmail.)
First some background regarding trigger. When qmail-queue has a mail
for qmail-send it opens the named pipe, trigger, writes a byte to it,
closes trigger and exits.
qmail-send notices this trigger in the following loop:
open trigger
select: is trigger readable?
...
todo_do()
...
close trigger
open trigger
...
select: is trigger readable
etc.
A couple of notes on this loop:
o The todo_do() involves a potentially expensive directory scan - if
lots of injections are occuring or if you use the bigtodo patch.
o The idea behind closing and opening trigger is to flush the byte
written by qmail-queue so that next time around the loop the select
blocks until another qmail-queue comes along.
The problem I've found relates to when the flush occurs on a named
pipe. At least on FreeBSD, a named pipe is only flushed when no other
process has the pipe opened.
On a very busy system the chance of this occuring reduces as there is
almost always one or more qmail-queue processes running. Futhermore
the code order of qmail-send is such that the window in which no
qmail-queue process can exist is very very small. It's the tiny window
between the close that immediately precedes the open in trigger_set().
The degenerate case I see is that qmail-send starts spinning on the
select()--todo_do() loop as select() always indicates that the trigger
is readable. This spin involves a directory scan of todo which slows
the qmail-queue processes as they too are writing to the same
directory/file system. Since the qmail-queue processes are further
slowed, qmail-send continues to spin on a readable trigger.
In other words, in the tiny window that qmail-send leaves for the
kernel to flush the pipe, there is always at least one qmail-queue
process with the trigger open. Ergo a resource burning spin that
degenerates if the injection rate is high and regular (exactly the
situation for the servers I noticed this on).
Returning to the bigtodo patch, that of course exacerbates the
situation as the window between the close and open in trigger_set
forms an even smaller part of the loop.
Fortunately there are a couple of remedies.
At the very least, the flush window can be made substantially larger
by closing trigger as soon as the select returns.
A second and more defensive measure is to issue a non-blocking read on
the pipe to drain all qmail-queue bytes *prior* to the todo
scan. Perhaps both of these could be done in the trigger_pull
routine. I've appended a patch that gives the idea in code (it's
untested).
Question: has anyone else seen this? You most likely will only see it
on a very busy system that has bigtodo.
Regards.
*** trigger.orig.c Mon Jun 15 03:53:16 1998
--- trigger.c Wed Jul 25 16:50:40 2001
***
*** 1,4
--- 1,5
#include select.h
+ #include ndelay.h
#include open.h
#include trigger.h
#include hasnpbg1.h
***
*** 36,41
int trigger_pulled(rfds)
fd_set *rfds;
{
! if (fd != -1) if (FD_ISSET(fd,rfds)) return 1;
return 0;
}
--- 37,55
int trigger_pulled(rfds)
fd_set *rfds;
{
! char buf[64];
!
! if ((fd != -1) FD_ISSET(fd,rfds))
! {
!ndelay_on(fd);
!while (read(fd,buf,sizeof(buf)) 0) ;
!close(fd);
!fd = -1;
! #ifdef HASNAMEDPIPEBUG1
!if (fdw != -1)
! close(fdw);
! #endif
!return 1;
! }
return 0;
}
Re: Possible degenerate case in trigger handling?
(To follow up on my own post) In other words, in the tiny window that qmail-send leaves for the kernel to flush the pipe, there is always at least one qmail-queue process with the trigger open. Ergo a resource burning spin that degenerates if the injection rate is high and regular (exactly the situation for the servers I noticed this on). ... Fortunately there are a couple of remedies. At the very least, the flush window can be made substantially larger by closing trigger as soon as the select returns. This of course is not a good idea as it means that any qmail-queue notify will be lost while trigger is closed. So the closed-window size is a catch-22. Keep it small and a busy system may spin as described. Make it larger and you increase the probably of missing a notify from qmail-queue. A second and more defensive measure is to issue a non-blocking read on the pipe to drain all qmail-queue bytes *prior* to the todo scan. Perhaps both of these could be done in the trigger_pull routine. I've appended a patch that gives the idea in code (it's untested). I still think this might be a viable solution. In fact I wonder whether qmail-send can simply keep the pipe open and do a non-blocking read to drain the notifys rather than rely on the open/close flush semantics. That way there is no close-window at all, so losing a notify becomes impossible rather than unlikely, it's simpler code, it eliminates the false triggers I'm seeing and probably creates less load on the OS by avoiding those repeated opens and closes. Regards.
Re: pop3d
On Thu, Jul 26, 2001 at 02:39:18PM +1000, Vivian Doherty allegedly wrote: We have a problem with the qmail-pop3d, when the status is 7/50 we start having network problems, users cannot connect and receive timeout errors, it only happens about once a month. Any help would be appreciated. Can anyone tell me what is going on and how I fix the problem, why would there be 7 undelivered for pop3d mail accounts? You're getting confused. tcpserver has nothing to do with delivered or undelivered mails. What this log entry is saying is that 7 out of a maximum of 50 concurrent pop sessions are active. You no doubt have a -c 50 in your tcpserver script for pop. You can conduct a simple experiment to help find out what's going on. Establish lots of pop sessions using telnet, eg: telnet popserver.host.name 110 Wait until you get the banner then background the telnet with ^Z. Keep doing this and watch the pop logs. Can you get more than 7/50 or do the telnets start to fail? If they start to fail before you have 50 of them, show us the error you get back from telnet. Oh, and at the end of the test, don't forget to kill all those telnets. My suspicion is that tcpserver is started with a kernel imposed limit on the number of children it can fork concurrently and that that limit is much less than 50 that you want it to use. Regards. Part of the maillog below. Jul 25 13:26:45 mail pop3d: 996031605.921791 tcpserver: status: 7/50 Jul 25 13:26:45 mail pop3d: 996031605.922774 tcpserver: pid 6106 from 202.7.178.138 Jul 25 13:27:09 mail smtpd: 996031629.717653 tcpserver: end 26591 status 0 Jul 25 13:27:09 mail smtpd: 996031629.717786 tcpserver: status: 0/50 Jul 25 13:27:19 mail pop3d: 996031639.938243 tcpserver: ok 1923 :192.168.0.111:110 :192.168.0.19::1035 Jul 25 13:27:19 mail pop3d: 996031639.962696 tcpserver: end 1923 status 256 Jul 25 13:27:19 mail pop3d: 996031639.962939 tcpserver: status: 6/50 Jul 25 13:27:24 mail pop3d: 996031644.263336 tcpserver: status: 7/50 Jul 25 13:27:24 mail pop3d: 996031644.264508 tcpserver: pid 7991 from 192.168.0.33 Jul 25 13:27:33 mail pop3d: 996031653.305314 tcpserver: ok 2611 :192.168.0.111:110 :192.168.0.7::1053 Jul 25 13:27:33 mail pop3d: 996031653.305460 tcpserver: end 2611 status 256 Jul 25 13:27:33 mail pop3d: 996031653.305520 tcpserver: status: 6/50 Jul 25 13:27:38 mail pop3d: 996031658.739339 tcpserver: status: 7/50 Jul 25 13:27:38 mail pop3d: 996031658.740334 tcpserver: pid 8681 from 202.7.178.138 Regards Vivian Doherty IT Consultant James Walker Australia Pty Ltd 32 Clapham Rd Regents Park NSW 2143 Ph: 9644 9755 Mailto:[EMAIL PROTECTED]
Re: Problem with Qmail Queueing
On Tue, Jul 24, 2001 at 08:09:01PM -0400, Dahnke, Eric allegedly wrote: Sorry for my abrupt response previously. I recognize you as a long time member of the list, and appreciated your help when I was first getting into qmail. But on a server level you do need to do this no? That is, qmail can be set to do 300 concurrent deliveries but in the tcp layer either inetd or tcpserver needs to be upped from their default values as well. Yes. But there are two different concurrency levels regarding remote mail. One controls how many *inbound* connections will be accepted concurrently and that is controlled by the tcpserver -c value. The other controls how many *outbound* deliveries will be attempted concurrently and that is controlled by control/concurrencyremote. You are referring to the former while John is referring to the latter. Yes, you do need to tune both of these and yes they are both in the tcp layer as you put it, but they are definitely different beasts that should be treated entirely separately. Regards. -Original Message- From: John White [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 24, 2001 6:59 PM To: [EMAIL PROTECTED] Subject: Re: Problem with Qmail Queueing On Tue, Jul 24, 2001 at 06:39:00PM -0400, Dahnke, Eric wrote: Wrong. Look at the last line of my post. By default, tcpserver allows at most 40 simultaneous qmail-smtpd processes. To raise this limit to 400, use tcpserver -c 400. I read that. That doesn't have anything to do with the number of concurrent remote deliveries that qmail will do. John White
Re: Inode allocation / qmail-queue?
Er whatever other issues may or may not be associated with ReiserFS, re-use of inodes does not present a problem for qmail and is commonly seen on UFS. If you look at the log fragment carefully you'll see that the inode is only reused after the message has been delivered and thus the file deleted. It would be a problem if the same inode was in use at the same time, but the log fragment doesn't show that. By way of an example, on a FreeBSD 4.2 UFS queue I see that the same inode has been re-used over 100 times for some 1200 deliveries. $ grep 'info msg' /var/log/qmail/current | cut -f4 -d' ' | cut -f1 -d: | sort -n | uniq -c | sort -nr 177 8097707 165 8097716 118 8097715 83 8097913 75 8097709 71 8097768 62 8097947 48 8097699 42 8097909 33 8097990 29 8097701 23 8097755 16 8097879 16 8097769 15 8097910 14 8097943 14 8097914 14 8097712 13 8097719 11 8097753 10 8097998 10 8097997 8 8097984 ... Regards. On Tue, Jul 24, 2001 at 01:45:57AM +0200, Lordy allegedly wrote: Hi Mike, this is a known issue with ReiserFS. As you might now, Ext2 and ReiserFS have many differences and you are just experiencing one of them. The whole problem is documented unter www.namesys.com (the homepage of ReiserFS) so you will find the information you need there. In general you have two options: 1) Moving the qMail partition back to ext2 (probably /var) 2) Patching qMail with the ReiserFS patch. (I think that one is available through a link on www.namesys.com too). Just for your information: I have a linux box running qMail and I have moved /home which contains the pop-boxes to ReiserFS but /var remains ext2. This makes sure that mail is securely stored once it is delivered and if your queue (or the partition) crashed you won't have much chances to restore it anyway. Hope this help, Lordy At 14:41 23.07.2001 -0600, you wrote: Hello there. I have been noticing slightly out of the ordinary things happening in my qmail-send logs after changing the queue filesystem over to reiserfs. I am seeing the same inode used for multiple messages. Is this normal? (other users email has been blanked, as has all senders. mine is known to all of you, so why bother typing to cover mine eh? ) excerpts from my qmail-queue log piped thru tai64nlocal 2001-07-23 14:29:38.294512500 new msg 405006 2001-07-23 14:29:38.294529500 info msg 405006: bytes 2531 from [EMAIL PROTECTED] qp 28395 uid 1016 2001-07-23 14:29:38.388694500 starting delivery 689: msg 405006 to local vdomain-vuser@vdomain 2001-07-23 14:29:38.388713500 status: local 1/10 remote 0/20 2001-07-23 14:29:38.442249500 delivery 689: success: POP_user_does_not_exist,_but_will_deliver_to_/users/catchall/dir/did_0+0+1/ 2001-07-23 14:29:38.442273500 status: local 0/10 remote 0/20 2001-07-23 14:29:38.442278500 end msg 405006 2001-07-23 14:32:30.228899500 new msg 405006 2001-07-23 14:32:30.228916500 info msg 405006: bytes 4242 from [EMAIL PROTECTED] qp 28405 uid 1016 2001-07-23 14:32:30.305868500 starting delivery 690: msg 405006 to local [EMAIL PROTECTED] 2001-07-23 14:32:30.305886500 status: local 1/10 remote 0/20 2001-07-23 14:32:30.376295500 delivery 690: success: did_0+0+1/ 2001-07-23 14:32:30.376313500 status: local 0/10 remote 0/20 2001-07-23 14:32:30.376319500 end msg 405006 2001-07-23 14:32:32.722033500 new msg 405006 2001-07-23 14:32:32.722049500 info msg 405006: bytes 1827 from [EMAIL PROTECTED] qp 28409 uid 1016 2001-07-23 14:32:32.814920500 starting delivery 691: msg 405006 to local [EMAIL PROTECTED] 2001-07-23 14:32:32.814937500 status: local 1/10 remote 0/20 2001-07-23 14:32:32.847071500 delivery 691: success: did_0+0+1/ 2001-07-23 14:32:32.847089500 status: local 0/10 remote 0/20 2001-07-23 14:32:32.847094500 end msg 405006 Mike -- Mike Hodson [EMAIL PROTECTED]
Re: Nessus scan results
From Nessus: The remote SMTP server did not complain when issued the command : MAIL FROM: root@this_host RCPT TO: |testing This is a test against a known sendmail vulnerability, not SMTP servers in general. The remote SMTP server did not complain when issued the command : MAIL FROM: root@this_host RCPT TO: /tmp/nessus_test This is a test against a known sendmail vulnerability, not SMTP servers in general. The remote SMTP server did not complain when issued the command : MAIL FROM: |testing This is a test against a known sendmail vulnerability, not SMTP servers in general. There seem to be a buffer overflow in the remote SMTP server when the server is issued a too long argument to the 'MAIL FROM' command, like : MAIL FROM: AAA[...][EMAIL PROTECTED] Where AAA[...]AAA contains more than 8000 'A's. This looks like a test against a known sendmail vulnerability, it's not a generic SMTP problem. It appears that Nessus need to get much more specific in the description of their test results and perhaps much more general in their tests. It looks like they've combined the security problems of sendmail and NTMail and labelled it with the more general SMTP term. Nothing wrong with them having a test, but creating so many false alarms without explanatary comments is not so good. Furthermore, their test *could* notice the qmail banner and add a descriptive entry along the lines of: You appear to be running qmail, if so, this warning does not apply. I guess they'd get tired of adding that to the end of every message though : Regards.
Col Wilson is pretty lame
If nothing else, Mr Wilson will be associated with some interesting search engine results. Regards. - Forwarded message from [EMAIL PROTECTED] - Received: from unknown (HELO dn1.dns4com.net) (216.74.113.140) by arquette.bushwire.net with SMTP; 17 Jul 2001 07:05:06 - Received: from b3390.pppool.de ([213.7.51.144] helo=antrim) by dn1.dns4com.net with asmtp (Exim 3.20 #1) id 15MMoh-0007xg-00 for [EMAIL PROTECTED]; Tue, 17 Jul 2001 00:50:39 -0400 Message-ID: 00c201c10e7c$5aa52330$0201a8c0@antrim From: [EMAIL PROTECTED] To: MarkD [EMAIL PROTECTED] Subject: Re: mail policy Date: Tue, 17 Jul 2001 06:51:32 +0200 MIME-Version: 1.0 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dn1.dns4com.net X-AntiAbuse: Original Domain - bushwire.net X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - colwilson.com From: Col Wilson [EMAIL PROTECTED] Subject: Date: Sun, 15 Jul 2001 09:41:14 +0200 I have repeatedly tried to unsubscribe from this list and now all I can do is bounce messages until I am removerd, SORRY. - End forwarded message -
Re: Dangers of modifying preline.c
On Tue, Jul 10, 2001 at 01:25:11PM -0700, Alex Hathaway allegedly wrote: Hey Ian, I have... Over three times now. No one has had any solid answers. One fellow suggested it was with the SIGPIPE signal, but didn't give me any idea on how to remedy it. So, I had to find another way around it. You need to find out what the problem is. It's real simple, either mailman is exiting with a non-zero exit code or it's exiting prior to reading all of the message from the pipe. Both of these are conditions which preline treats as errors. Consequently preline exits in such a way that the delivery is tried later in the hope that the mail admin notices and fixes the problem. You need to find out which of those two conditions are occuring - and it's fundamentally a mailman issue. If mailman is exiting non-zero, why is it doing so? A non-zero exit is a programs way of telling you something is wrong. Listen to it. If mailman is exiting without reading all of the message, why is it doing so? Surely if it hasn't read all of the message then it cannot have safely stored it, yes? It also executes flawlessly when I take that bit of code out of preline. Not even a ghost proc or crash. Of course - but that proves nothing. You've told preline to ignore all errors from the child. Put another way, you said process the mail but don't tell me whether it worked or not. If mailman ever gets a genuine error, such as quota full or somesuch you'll never know and the mail will simply disappear. The solid answer as you put it, is to find out what mailman is doing and why. Regards. Sincerely, -Confuzzled Lexx. -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 12:43 PM To: [EMAIL PROTECTED] Subject: Re: Dangers of modifying preline.c Alex Hathaway [EMAIL PROTECTED] writes: Is there any dangers in commenting out the lines: /* if (wait_crashed(wstat)) strerr_die2x(111,FATAL,child crashed); */ in preline.c ? Yes. If the program run by preline crashes unexpectedly, your mail will be lost. If you leave the lines in there, your mail will be resent later. I suspect that you have some problem which you are trying to address by commenting out those lines. You are likely to get better advice if you describe the problem. Ian
Re: [Announce] oSpam version 0.02
Looks quite nice. A question: How do you deal with mailing lists? Suggestions: 1: You might want to have wildcard entries used with the isinfile(), that way you can add a whole domain, eg, *@list.cr.yp.to 2: You might want to introduce a command such that a mail can be piped into it and have that sender address included in the accept list. In mutt it would then be as easy as cruising thru your existing mailboxes and running | ospam_accept to preload your accept list. A bit of shell twiddle would get your aliases in their too! Sure the file format is trivial and a program may seem superfluous, but what if you change to a DB file later on? You don't want to be tied down by exposing the file format now. 3: There are a number of hard-coded @8403.ch address in the code, you might want to either externalize these addresses or indeed externalize the complete messages to be in separate text files. 4: A minor note. The perl code uses a lot of system() calls when unlink() and rename() would be safer. On a more general note, I wonder whether embedding locking within each and every program that is run via .qmail makes sense? Perhaps better would be a simple program that single-threads the executation of a .qmail entry. Eg: | singlethread ospam whatever Oh look, BSD has the lockf command. If this is widespread (or if a triv perl implementation were available) you could remove all that locking code and simple have: | lockf -t 20 ospam/ospam.log ospam ospam my@address Please don't take these as a criticism, I'm glad people are making tools like this available. Regards. On Sat, Jul 07, 2001 at 10:13:19AM +0200, Olivier M. allegedly wrote: Bonjour! A new and much better version of oSpam is available : oSpam 0.2. The news are: * automatic creation of ospam directory and files on first call * confirmation mail to sender on success * fixed sender email addresses for confirmation mails * updated the docs * Project homepage: http://omail.omnis.ch/ospam/ * Demo: send a mail to [EMAIL PROTECTED] (test account, emails and registred addresses will be trashed every week) * Description: oSpam - An ultimative Perl qmail based anti-Spam System = It's a package inspired from the mapSoN tool, and other tools used for example by the php-project mail server. 2 main features: 1) use it for your usenet postings: as From: address, you get an [EMAIL PROTECTED] address, which will be valid one week. After this delay, the mails sent to this address will be put in quarantaine, waiting for a confirmation from the author, which will never happen if it is a spam. 2) use it as your main email address: put all your friends addresses in your accepted.txt file. If somebody which isn't in the list send you a mail, he will get a small and unique confirmation request, and then the mail(s) will be delivered transparentely. Every operation is logged: look at the ~/maildir/ospam/ospam.log file and at the source code to understand how the whole is working. * Download: (6.3 KByte big :-) http://prdownloads.sourceforge.net/omail/ospam-0.2.tar.gz * Mailing List: http://lists.sourceforge.net/lists/listinfo/omail-ospam * Other URL's: (cvs, releases, etc) http://freshmeat.net/projects/ospam/ This is just version 0.2, so even if it is already working fine, there is still much to be done (check the todo list). Comments are welcome! Regards, Olivier -- _ Olivier Mueller - [EMAIL PROTECTED] - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
Re: FreeBSD: /etc/mailer.conf
On Fri, Jul 06, 2001 at 06:43:35PM +0200, Karsten W. Rohrbach allegedly wrote: mailq /var/qmail/bin/qmail-queue NO Oops. as you say, qmail-qread. newaliases /bin/true true and false belong into the runtime userland on bsd systems - /usr/bin Double oops. Too many days switching between Solaris and FreeBSD methinx. As an aside, mailer.conf should include a from entry too, methinx. I keep meaning to mention that to the FreeBSD crowd but haven't yet. why that? would you like to set up a system wide default for the user name? this is unix, not windows... this would not make much sense as far i can understand it. I think we're talking about different things. Apropos the thread, I'm talking about the 'from' command which lists the contents of your mailbox. The 'from' that ships with FreeBSD assumes an mbox format mailbox. I would expect that *all* commands related to mail should be mapped to a mail-system specific commands. Perhaps 'biff' is another command that should likewise be mappable. Regards.
Re: qmail-remote
On Thu, Jul 05, 2001 at 11:05:40AM -0400, David Gartner allegedly wrote: Hey all, I have a slight problem. I got some calls that the mail server was taking 5 hours to send email, so I checked out the mail server. I had 3 connections to some mail server (all the same) and all the other qmail-remotes were enclosed in brackets [qmail-remote]. Not knowing what this was, I did a 'killall -HUP qmail-remote'. The 'unclogged' the remote process and it started delivering the messages that were on hold. Can anyone tell me what might have cause this Not now that you've destroyed the evidence. When something unexpected happens to a system and you want to find out what's going on, the best thing to do is as little as possible. Avoid anything that might perturb the observations. Killing a process loses all the state about the process, what files it had open, what system call it might have been sitting on, where in the code it was, what it was connected to, what mail it was handling, that sort of thing. Also, if you're referring to OS related information (ie ps output) it helps to know the OS version, the h/w, that sort of thing. Regards.
Re: sending mail via MS Exchange
On Wed, Jul 04, 2001 at 01:11:30PM -0500, Kenny Austin allegedly wrote: Putting the IP address in smtproutes does work, however if the host at that IP address is ever down the messages will bounce after one try. Not true. Smtproutes is simply a DNS lookup override mechanism. The retry is done regardless of whether smtproutes is part of the delivery process or not. Regards.
Re: qfilter to add disclaimer (examples?)
Note that in this day of MIME and multipart messages, attachments, digitally signed email, encrypted email, and everything else, it is generally a very bad idea to try to append an arbitrary block of text to any message -- even an innocuous footer. For this reason, we ask that you consider _very_carefully_ whether such an action is needed before mangling the mail of your users. Having said all that, it's not that hard to detect a MIME message and append another component. If it's not MIME then a textual appendage usually does the trick. Unmarked HTML email can be a bit tricky, but even this is tractable. So in all there is just three relatively straightforward cases that cover the vast majority of email. Furthermore, most encryption and signage software uses textual markers to tell it where the signed/encrypted section ends so an appendage after that is unlikely to do damage. Even then, if any damage is done it only tends to reduces the security risk by not decrypting, or not recognizing the signature. Finally, all of this is usually done at a single point - the outbound MTA - so it's not too difficult to catch unhandled cases and deal with them on a per-user basis. Note that there can (infrequently) be good technical reasons for doing so. Adding several kilobytes of incomprehensible legalese is _never_ one of these reasons. Well, I think it's always presumptious to define what is appropriate email content when sent from one consenting MTA to another. Regards.
Re: TRANSLATE TO ENGLISH
On Tue, Jul 03, 2001 at 05:28:49PM -0500, Jamyn allegedly wrote: The email is basically a scam I've seen before, translated to French (for 'confidentiality reasons' they say.. *cough*Avoiding US Feds*cough*) There is another similar email written in english, circulating around the web as well. Only the names, places, and dollar amounts are different in Heh. And similar to posted letters originating out of, mostly, Nigeria a few years ago. I'm not trying to pick on Nigeria at all, that just happens to be where the ones I saw (and personally received) came from. They also try to get you to send business letterhead with the account details then use that as a means of trying to convince a bank that they are you. If someone is ever conned by such an absurdity it's hard to feel too sorry for them... Regards.
Re: Qmail/MailMan - Crashing Children with no cause.
Search the archives for preline and SIGPIPE. I think you'll find the answer there. Regards. On Mon, Jul 02, 2001 at 03:33:20PM -0700, Alex Hathaway allegedly wrote: This is an odd ball error: deferral: preline:_fatal:_child_crashed/ I'm using mailman as a list agent (ezmlm is nice, but a bit short of my needs) and for some reason when passing info through preline this error pops up in the syslog. However if I pipe the mail message direct to the command itself without preline or qmail, I get a message just fine. the line in the .qmail- file reads: |/var/qmail/bin/preline /usr/local/mailman/mail/wrapper mailcmd timy As much as I would like to say it's all mailmans fault, I can't figure why it would die via only qmail, and not the command line. I'm on Solaris X86 ver 8 Using roaming users, and vchkpwd. Any ideas of things to try or how to debug would be very helpful and appreachiated -Alex
Re: Qmail/MailMan - Crashing Children with no cause.
On Mon, Jul 02, 2001 at 04:29:50PM -0700, Alex Hathaway allegedly wrote: I don't think that's the problem.. To quote Dan, The next version of preline will work just like a pipe from the shell: it will put the main command in the foreground, and it will die silently if it receives SIGPIPE. Right. But that next version isn't out yet. Your point is? I even to speculation, used the patch in the archives with still the same result. *pullig heair out* why can appy's just get along? You're being silly. You don't know the reason for your problem, yet when someone offers a solution you dismiss it for no good reason and without even trying it! Sounds like you enjoy *pullig heair out* (sic). Regards. -Original Message- From: MarkD [mailto:[EMAIL PROTECTED]] Sent: Monday, July 02, 2001 4:20 PM To: [EMAIL PROTECTED] Subject: Re: Qmail/MailMan - Crashing Children with no cause. Search the archives for preline and SIGPIPE. I think you'll find the answer there. Regards. On Mon, Jul 02, 2001 at 03:33:20PM -0700, Alex Hathaway allegedly wrote: This is an odd ball error: deferral: preline:_fatal:_child_crashed/ I'm using mailman as a list agent (ezmlm is nice, but a bit short of my needs) and for some reason when passing info through preline this error pops up in the syslog. However if I pipe the mail message direct to the command itself without preline or qmail, I get a message just fine. the line in the .qmail- file reads: |/var/qmail/bin/preline /usr/local/mailman/mail/wrapper mailcmd timy As much as I would like to say it's all mailmans fault, I can't figure why it would die via only qmail, and not the command line. I'm on Solaris X86 ver 8 Using roaming users, and vchkpwd. Any ideas of things to try or how to debug would be very helpful and appreachiated -Alex
Re: Qmail/tcpserver woes
morning, and expected all to be well. Soon after the reload, we began to see our SMTP service go painfully slow, only allowing a trickle of emails to get in. So the rcpthosts list going blank and then being rebuilt is not the Well, it may not be a real problem, it may be just slow connections using up your concurrency. In this case it should eventually sort itself out. Having said that, you don't mention whether the box is very busy nor what sort of internet connection you have. That would be useful to know. Futhermore, you don't say whether SMTP deliveries are occuring or not. Is the qmail-send log ticking over with new deliveries? While Matt might have omitted some useful information, he does however make our life a lot easier because he gives plain data and the *real* domain. This allowed me to do a couple of test connections to his server which makes things a lot clearer. Here's what happens for me: $ telnet mail1.godaddy.com 25 Trying 63.241.136.35... telnet: connect to address 63.241.136.35: Network dropped connection on reset telnet: Unable to connect to remote host Thanks Matt. That tells me a lot. Specifically that the port is being listened to - so tcpserver is running correctly, that connections are being accept - so the tcpserver listen socket hasn't reach the backlog limit, but then something fails... I have noticed that if I do a qmail stop and then a qmail start, about 20 successful SMTP connections immediately come in, and then even though This is a worry as your tcpserver line has a concurrency of 120 as shown here. Here is the tcpserver line I am currently using for smtp: 22482 ?S 0:00 /usr/local/bin/tcpserver -v -l mail1.godaddy.com -P -H -R -x /etc/tcp.smtp.cdb -c 120 -u 503 -g 502 0 smtp /var/qmail/bin/qmail-smtpd I'd expect you to see a lot more than 20 qmail-smtpd processes running. In conjunction with the results of the telnet test I suspect a limits problem that is stopping tcpserver from forking as many processes as it wants. Do you log the tcpserver output? If so, what does it show? If not, can you start logging (I don't know whether LWQ includes this). Does your tcpserver start script use softlimit to set the process limits? If so, can you include -p130 or some such? However tcpserver is started you'll need to raise the limit on the number of children it can fork. Regards.
Re: GHOSTS AND ASSHOLES
On Fri, Jun 22, 2001 at 10:21:32AM -0500, Bill Andersen allegedly wrote: And then there are these two conversations that took place in Dallas, Texas. Late 1999. First call: *ring* Hello, Joe's Car Service. How may I be of service? Ah yes, I need someone to pick up my Chevy Suburban at 1234 Anystreet, it won't start this morning. I'm taking a cab to work. Ok, sir. We'll take care of it. Goodbye. Second call: *ring* Hello, Joe's Car Service. How may I be of service? Hi, I called this morning about the Chevy Suburban. Did you have any luck with it?. Uh, sir. We thought you got it started and took it on to work. It wasn't there when we went to pick it up... CAUSE: Someone had tapped into the car shop's phone line and beat them to the address. 3 vehicles THAT DAY! Of course, after getting to the 3rd address and NO vehicle, they started getting suspicious. MORAL OF THE STORY: Don't EVER think it can't happen to you. TRUE MORAL OF THE STORY: If you really really need to get your car started in a hurry, use a car thief. Regards.
Re: GHOSTS AND ASSHOLES
On Fri, Jun 22, 2001 at 12:11:00PM -0400, Russell Nelson allegedly wrote: How to know which is reliable? Watch this mailing list, and see who's been around longest (has the most established reputation to protect), and who's name begins with R. If you say so Russ. Heh heh.
Re: qmail-local's environment settings?
On Thu, Jun 21, 2001 at 03:05:36PM -0700, Williams, Paul (OTS-EDH) allegedly wrote: Does anyone have a list of the environment variables qmail-local sets up and what they map to? You mean above and beyond what the qmail-command manpage talks about? Regards.
Re: Error Messages
On Thu, Jun 21, 2001 at 09:20:51AM +1000, [EMAIL PROTECTED] allegedly wrote: Hi, when running qmail, I have one domain that I am not able to send messages to, it is a connection died, with an error message no. 4.4.2 Does anyone have any ideas if it is my or the other end, and what could be possible causes. Well, if you actually showed us the real error message and the real domain, we'd have an idea. But since you've supplied no information we can supply no ideas. That seems fair doesn't it? Regards. Thanks, -- Peter Milburn Systems Manager Software Communication Group Ltd [EMAIL PROTECTED] Ph: +613 9826 8300 Fax: +613 9826 8336 Level 16, 644 Chapel St South Yarra, Vic 3141 www.sofcom.com.au This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error, please notify Software Communication Group immediately. Any views expressed in this message are those of the individual sender except where the sender specifically states them to be the views of Software Communication Group.
Re: Q: Queue-limit (was Re: Discarding mailer_daemon mail....)
On Tue, Jun 19, 2001 at 07:13:42PM +0200, Bernhard Graf allegedly wrote: Greg Moeller wrote Hmmm, ok, what would a good split be for 7-10 in the queue? BTW... I wonder if there are any limits on how many files can be in the queue besides inodes and disk size? Memory. Read THOUGHTS regarding 'qmail-send uses 8 bytes... Regards.
Re: restart without rebooting
On Mon, Jun 18, 2001 at 09:55:24PM +0200, [EMAIL PROTECTED] allegedly wrote:
kill -HUP `ps auwx | grep qmail-send | grep -v grep | awk -F {'print
$2'}`
Or maybe even (if you have bash)
for PID in \
`ps auwx | grep qmail-send | grep -v grep | awk -F {'print $2'}`; do \
kill -HUP $PID; done
(not on 1 line but don't miss the backslashes)
vs svc -d /service/qmail-send
As Russ says, it's never too late to change over to supervise.
Regards.
Re: qmail-remote (cry wolf?)
On Mon, Jun 18, 2001 at 11:05:34PM +0200, Claudio Nieder allegedly wrote: On Solaris the above code would work without flaws. whereas SunOS 4.1.4 (my usual 'old bsd system' benchmark) says: descriptor sets. 0 indicates that the time limit referred to by timeout expired. On failure, select() returns -1, sets errno to indicate the error, and the descriptor sets are not changed. It doesn't tell explicitly what it does when it returns 0, but as it's mentioned only in the error case, that the bits are not cleared, one supposes that in timeout situations they are cleared, and thus qmail will not have any problems. Same with FreeBSD 4.3 - by implication. ... On return, select() replaces the given descriptor sets with subsets consisting of those descriptors that are ready for the requested operation. ... RETURN VALUES ... If select() returns with an error, including one due to an interrupted call, the descriptor sets will be unmodified. For this who are having significant recurrences of this problem, are you in a position to change timeoutread.c to check for a zero return from select? It sure would help isolate this problem if you can. Regards.
Re: Mime Encoding
You are confused. qmail does not look at the contents of the email at all. qmail has no concept of MIME, attachments, default lengths or anything. If the email is corrupted it's because your programmer submitted it to qmail in a corrupted state. Get your programmer to write the email to a file at the same time that it is submitted to qmail. When the email comes out the other side, compare it against the file and show us the differences. Regards. On Thu, Jun 14, 2001 at 12:47:28PM -0500, Anstett, Brad allegedly wrote: Hi, Does anyone know what the default length that qmail sets for a MIME encoded string for attachments. I had a programmer set it at 4320 and the mail and attachment can across corrupted. Is there anyway to increase the string length that qmail will accept. Thanks Brad Anstett
Re: Suspending an POP3 account.
On Wed, Jun 13, 2001 at 09:42:04AM +0300, Joe allegedly wrote: Changing permissions can be quite messy. Imagine where you have to do it for 1000 or more then when they pay you change them allover again. Best is to change authentication method from passwd file to database. The default tables have a suspend colum... Well, lemme see now... You have to have a process that creates a user, yes? That (at least) entails making some file system entries and setting the permissions appropriately. And you have to have a process that removes a user, after all, users do disappear, yes? That (at least) entails removing some file system entries. And so now we have this disable process, yes? And you're saying it's messy because that involves changes to the file system? That doesn't follow. Changing user states intimately involves the file system. I think that diddling with an authentication mechanism has the downside of giving very poor feedback to the user. Pop clients notoriously mask error messages and an incorrect password message will rarely be interpreted by the user as an I haven't paid my bill message. It certainly won't be interpreted by the POP client that way. I still think a good method is to rename the Maildir and create a temporary Maildir with an single mail that tells them precisely what the problem is. If you have to touch the file system this is no big deal and the resultant message to the user - if worded correctly - will not be vulnerable to misinterpretation. Regards. Joe. - Original Message - From: Reid Sutherland [EMAIL PROTECTED] To: Joshua Nichols [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 3:48 AM Subject: Re: Suspending an POP3 account. (lack of payment) clients when using a passwd/shadow authentication method. Any ideas on a solution? Though different checkpassword and pop programs will handle the problem differently, changing the _permissions_ on the ~Maildir/* so the owner doesn't have read access will work. That is, typical Maildir perms are 700, change it to 300. All mail will be delivered as usual, but the pop account will not work. If the user has telnet access, they will be able to circumvent this, but in a situation where you have expiring pop accounts, I'm assuming they don't. I imagine you could easily set the return error so that the user's mta tells them they're delinquent. It's not everyday the problem is a permission denied read on the Maildir. This sounds really good too. This will give them a more descriptive error instead of password error as suggested before. A password error will often simply mean that and end up confusing the client in most cases. But a permission denied error could result in them thinking, 'Hey, maybe I should pay my bill on time next time'. Thanks for the tip. -reid
Re: Mail with many BCC:s and delivery delays
What I mean is, if qmail processes message in the order received, and it receives a message to 100,000 recipients, does that mean that it won't start sending the next injected message until the first is completely delivered? (or at least attempted and deferred?). Correct. First in, first served. Like with this list... Let's say Charles sends a message 1/10 of a second after I send this one. Does that mean that qmail won't even /try/ to send his until mine has been completely delivered? If so, how does anyone run both standard email accounts and large lists on the same box without experiencing HUGE delays on their regular outbound email? By having more than once instance of qmail installed on your system or having your list run on a seperate system. Sorry, I'm sure this is a FAQ, but I couldn't seem to find a clear answer in the archives. I think a search for multiple instances or somesuch should do the trick. Regards.
Re: Suspending an POP3 account.
I've attempted a permission change on the Maildir, but then it won't run the program in the .qmail file. That's not how it works. There must be something else you've done. Did you change the permissions on the home directory as well? How about the .qmail file? Show us the exact error message in the log that tells you that it won't run the program in the .qmail file. Also, show us the contents and permission of the .qmail file. Regards.
Re: Install and communicate two qmail servers is possible?
On Tue, Nov 28, 2000 at 11:39:33AM -0800, Ould wrote: Hi, I want helps of anyone already running qmail or at least having a simple idea on how configurating both local server (which is in my LAN, behind a firewall, not visible to internet)and a second server(in my DMZ region, visible by internet but well serve only for sinding to and receiving mails of my mail local server, it is also behind a second firewall but having an internet IP). Sure. Plenty of people have done that and there is plenty of discussion archived (www.qmail.org has a pointer). You'll want to search on smtproutes. Your external server will have an smtproutes entry for your domain, pointing to your internal server. Your internal server will be configured in the standard way and will not need to be aware of the external system. Regards.
Re: unable to control /var/qmail/supervise/qmail-send
On Tue, Nov 28, 2000 at 02:34:37PM -0500, Silberman, Malcolm (BHR) wrote: I have installed Qmail a few times on Mandrake OS, and it worked fine. I go exactly according to Qmail how to by Adam McKenna. Now I tried to install on RedHat7 (and posted ome questions last week). I cameup with a dead end, so droped down to 6.2, but still I getthe following; svc: warning: unable to control /var/qmail/supervise/qmail-send: file does not exist svc: warning: unable to control /var/qmail/supervise/qmail-smtpd: file does not exist qmailsvc: warning: unable to control /var/qmail/supervise/qmail-send/log: file does not exist svc: warning: unable to control /var/qmail/supervise/qmail-smtpd/log: file does not exist logging. Post the output of: ls -lR /var/qmail Regards.
Re: Error messages - what do they mean?
On Tue, Nov 28, 2000 at 10:22:02PM +0100, Johan Almqvist wrote: Hi! I'm getting stuff like this in my logs: Nov 28 22:16:09 sol qmail: 975446169.345287 warning: trouble marking remote/9/96701; message will be delivered twice! Nov 28 22:16:09 sol qmail: 975446169.347416 delivery 8796: deferral: qmail-spawn_unable_to_create_pipe._(#4.3.0)/ This seems to mean trouble. What else does it mean? Apart from trouble? Nothing. Seriously, you have some serious resource and permission problems. Tell us more about the installation. Is it new? How did you do it? Which instructions did you follow? Has this mail system ever been running? What has changed recently? Any change of permissions, moving of directories, backup/restores? How do you start qmail? I suspect that the permission settings in /var/qmail differ from the ones set by a standard qmail install. I also suspect that the limits inherited by qmail-start need to be increased. Regards.
Re: unable to control /var/qmail/supervise/qmail-send
It looks like you haven't started the supervise process. The svc command is looking for files in the /var/qmail/supervise/qmail-send/suervise directory and they only get created when the supervise process is running. Check your startup scripts to ensure that supervise is started prior to issuing the svc commands. Regards. On Tue, Nov 28, 2000 at 03:52:12PM -0500, Silberman, Malcolm (BHR) wrote: I have attched the output of ls -lR /var/qmail hope it helps, thanks for your help! Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 3:06 PM To: QMail Mailing List Subject: Re: unable to control /var/qmail/supervise/qmail-send On Tue, Nov 28, 2000 at 02:34:37PM -0500, Silberman, Malcolm (BHR) wrote: I have installed Qmail a few times on Mandrake OS, and it worked fine. I go exactly according to Qmail how to by Adam McKenna. Now I tried to install on RedHat7 (and posted ome questions last week). I cameup with a dead end, so droped down to 6.2, but still I getthe following; svc: warning: unable to control /var/qmail/supervise/qmail-send: file does not exist svc: warning: unable to control /var/qmail/supervise/qmail-smtpd: file does not exist qmailsvc: warning: unable to control /var/qmail/supervise/qmail-send/log: file does not exist svc: warning: unable to control /var/qmail/supervise/qmail-smtpd/log: file does not exist logging. Post the output of: ls -lR /var/qmail Regards. This e-mail and any files transmitted with it are intended for, and should only be read by, the intended addressee. Its contents are confidential and if you are not the intended addressee, please notify the sender immediately and delete all records of the message from your computer. Any reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this message without the prior written consent of the sender are strictly prohibited. The contents of this communication represent the sender's personal views and opinions, which do not necessarily reflect those of Bass Hotels Resorts, Inc. Starting mail-transport-agent:svc: warning: unable to control /var/qmail/supervise/qmail-send: file does not exist svc: warning: unable to control /var/qmail/supervise/qmail-smtpd: file does not exist qmailsvc: warning: unable to control /var/qmail/supervise/qmail-send/log: file does not exist svc: warning: unable to control /var/qmail/supervise/qmail-smtpd/log: file does not exist logging.
Re: ORBS - NOT!
I don't know what sort of qmail install you are running but qmail does run without ORBS. In fact the default qmail does not have any ORBS testing. What must have happened is that someone specifically added the ORBS test on your server. You need to tell us more about your system. Specifically the startup script for qmail-smtpd. If it's done in the usual manner, then it's a one line change. Regards. On Mon, Nov 27, 2000 at 06:28:42PM -0600, Chris Olson wrote: How do I configure qmail to *NOT* use ORBS.org for spam filtering? I tried to remove the line in the startup scripts relating to ORBS, and the SMTP server refuses to run without it. I don't want to start a flame war, but this outfit (ORBS) is blocking IP addresses unnecessarily - please read the following that I received from Road Runner... A rr user tried to send email to a domain that I host and it bounced because of ORBS and the 'HISTORY' outlined here. I called Mark Herrick today and talked to him directly on the phone. This is how I found out that qmail does this (uses ORBS) by default. I *DO NOT* want my mail server using this outfit to filter spam..Mark had to use a hotmail address to contact me because of this 'filter' that ORBS has on their server. Any suggestions would be greatly appreciated. -- Chris Begin pasted message ** Subject: jerland.com blocking rr.com/mediaone.net via ORBS Date: Mon, 27 Nov 2000 10:30:16 -0500 From: "W. Mark Herrick" [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hello, We are currently experiencing problems delivering email to jerland.com. This is due to a manual block from the ORBS system of which jerland.com subscribes. Although we have a thorough anti-SPAM policy and properly address these issues, Road Runner has been manually added to the ORBS list due to a request we made to the ORBS administrators. (see HISTORY) With analysis and discussions with other providers, we believe that the impact of the ORBS block is very minimal and easily corrected on a case-by-case basis. We are currently only hearing 1 or 2 reports per week from our entire customer base. We will take the information provided and work with each provider to correct it with them directly. I can assure you that the IP address that ORBS is currently blocking is in no way an open relay, and that it is being blocked solely due to ORBS' testing servers being refused at our border routers. Road Runner takes the issue of open relay servers very seriously, and, in addition to immediately closing them as they are detected, performs proactive relay detection checks on its own network. Likewise, Road Runner also takes the issue of unauthorized probes very seriously, and as such has taken steps to minimize potential abuse from outside sources. Many other major Internet Service providers, such as Above.net, have taken this stance along with us. You may wish to take a look at http://www.orbs.org/hallofshame.html to see who else is "spite listed" by the ORBS project. ORBS is currently blocking Road Runner IP Addresses with a DNS "A" record of 127.0.0.4 - These are, according to the ORBS web site, considered "untestable netblock entries" (see HISTORY). ORBS has, however, recently made available a number of different "zones" that providers can currently utilize to block unwanted SPAM mail from open relay sources, but that will not block those "untestable netblock entries" sites such as Road Runner, Above.Net, and Carnegie Mellon University. More information regarding these "zones" can be found at http://www.orbs.org/usingindex.html - All that is necessary to make this change is to modify your mail server to query the ORBS database at "outputs.orbs.org" instead of "relays.orbs.org". This will NOT affect the amount of SPAM that your servers block, only the amount of false positives that are affecting our combined users. I would sincerely hope that you reconsider and/or restructure your use of the ORBS project. I can be directly reached at 703-345-2477 if you wish to discuss this further. Sincerely, W. Mark Herrick, Jr. [EMAIL PROTECTED] Operations Security Manager Team Lead - Usenet Operations Road Runner Security - 703.345.2477 [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] HISTORY: Road Runner customers and Affiliates initially contacted us with a security issue. They were concerned with their privacy and security when an unknown entity (to them) began scanning them without permission. We initially tried to address this case by case and later contacted the ORBS administrators and requested this unwelcome scanning terminated. This is analogous to someone requesting they be removed from a list that they did not subscribe to. With this request, all Road Runner IP space was unexpectedly added to the ORBS list
Re: ORBS - NOT!
On Mon, Nov 27, 2000 at 07:01:20PM -0600, Chris Olson wrote: Chris Johnson wrote: There's no such thing as "the" line in the startup script relating to ORBS, and nobody has any idea what your particular startup line looked like before or what it looks like now. OK. I assumed that all installations of qmail used this. I'm running a Corel Server Version (Debian) Linux box and qmail 1.03 came with the distribution. This is a fresh install and the script has not been Great. Yet more Frankinmail... Change this line: rblsmtpd -rrelays.orbs.org /var/qmail/bin/qmail-smtpd 21 | setuser to: /var/qmail/bin/qmail-smtpd 21 | setuser then restart. Regards.
Re: mailq
On Mon, Nov 27, 2000 at 09:07:03PM -0500, Peter Samuel wrote: On Mon, 27 Nov 2000, Paul Fontenot wrote: What is the equivalent of the mailq command? Is it qmail-queue? And if so can I just drop it in place of mailq in my scripts? /var/qmail/bin/qmail-qread You need root privileges (or qmailq really) to run it. Which is why some people run it as a network service. Something like this does the trick: /usr/local/bin/tcpserver -v -H -R -u1008 -g1003 127.0.0.1 81 /var/qmail/bin/qmail-qread Where 1008 is the uid of qmails and 1003 is the group id of qmail. Then create a mailq command thusly: cat EOD /bin/mailq #! /bin/sh /usr/local/bin/tcpclient 127.0.0.1 801 sh -c 'exec /bin/cat -v 6' EOD chmod a=rx /bin/mailq By binding to 127. only local users can access the port. And they all get access without needing any special permissions. Regards.
Re: Host name not found
On Tue, Nov 21, 2000 at 02:29:23PM -0500, Dave Sill wrote: concurrencyincoming:20 Bogus file. concurrencylocal and concurrencyremote are the real files. concurrencyincoming is some invention of [EMAIL PROTECTED] No, it's an LWQism. defaultdelivery :./Mailbox Bogus file. There is no reference to this in qmail. It's yet another invention of [EMAIL PROTECTED] Another LWQism. Both are clearly identified in LWQ as nonstandard. Ug. We'll have to start calling it Frankenmail pretty soon. What with all the installation variants, run-time control variants and user-friendly overlay variants... It's getting hard to recognize the original package (and questions associated with it). Regards.
Re: Hop count problem in qmail-send
On Mon, Nov 20, 2000 at 08:54:24AM +0100, Richard van den Berg wrote: Hi there, I just started using qmail 1.03 a week ago, and made some interesting discovery. I had the following .qmail file: | preline formail -I "Bcc: `some/script`" | qmail-inject Obviously, this causes a loop since qmail-inject will try to deliver to Hmm. When I try the same pipeline I get a bounce alerting me to a loop due to a potentially duplicate Delivered-To: header. Specifically: This message is looping: it already has my Delivered-To line. (#5.4.6) And this is precisely what I'd expect as qmail has very good loop detection. the Bcc: addresses as well as to the original To: line. The interesting bit is that this filled up the /var/mail file system rather quickly. What happend is that: 1) qmail-inject queues a mail for the original To: address 2) qmail-send delivers this mail using qmail-lspawn to this same .qmail file 3) goto 1 There's an important point you've missed. Step 2a where qmail-lspawn uses qmail-local to deliver the mail to .qmail. qmail-local will not deliver a mail that already has the same Delivered-To: header that it wants to generate. In effect. If the same mail ever attempts delivery thru the same .qmail file more than once it will be detected. This goes on indefinately! I soon started getting many bounces from the people on the Bcc: list, saying things like "Too many hops 233 (max 30)". Yes 233 hops! It seems that nor qmail-inject, qmail-queue, qmail-send or qmail-lspawn checks for hop counts. I believe this is a bug. Let me hazard a guess that the mail is actually going out to a remote recipient in the bcc: list and the delivery at that end is somehow removing the Delivered-To: headers. Alternatively the formail invocation is somehow removing the Delivered-To: heades. Have you the full headers of one of those bounces? Regards.
Re: Hop count problem in qmail-send
1) qmail-inject queues a mail for the original To: address 2) qmail-send delivers this mail using qmail-lspawn to this same .qmail file 3) goto 1 There's an important point you've missed. Step 2a where qmail-lspawn uses qmail-local to deliver the mail to .qmail. qmail-local will not deliver a mail that already has the same Delivered-To: header that it wants to generate. This is the catch; without preline, there is no Delivered-To: header. I'd figure qmail-local (or any of the steps before it) would also check the hop count. Hmm. Whilst the qmail-command manpage does say this: WARNING: The mail message does not begin with qmail-local's usual Return-Path and Delivered-To lines. in relation to pipeline deliveries, I'm struggling to understand *why* that choice was made. When does a pipeline delivery make it ok to loop thru the same .qmail file? I guess one reason is that it's a lot easier to use preline (or echo $DTLINE) to add the header than it is for any script that needs to, to reliably remove an embedded header. There must be another but it's not coming to me right now. And yes, as a fallback qmail-local *could* count Received: lines, just as qmail-smtpd does. Actually qmail-queue would be a better spot for this. A slight complication is that qmail-queue does very little header scanning of the input right now. Having said that, performing the test in qmail-queue has the advantage of catching loops on all queue insertion and eliminates the need for this code in qmail-smtpd (I note no checking seems to be done in qmail-qmqpd). I'm afraid they got lost with the rest of the 100Mb I had to chuck. If I remeber correctly, there were a lot of MBOX lines and a lot of Received: lines inserted by my local qmail. This is how the remote smtpds counted the number of hops, I guess. You remembered correctly. It turns out to be trivial to reproduce. You just need this: | qmail-inject in the offending .qmail file. Regards.
Re: qmail 1.04
On Fri, Nov 17, 2000 at 05:06:27PM +0100, Peter van Dijk wrote: On Thu, Nov 16, 2000 at 10:29:28PM -0800, [EMAIL PROTECTED] wrote: I made two mistakes, when I wrote that I want to have a cdb ;-) We're currently experiencing some temporary performance problems with our qmail server. This is due to large smtproutes and rcpthosts files and some I/O bottleneck on the disk they're located. Mistake 1) A cdb wouldn't help with this problem, as its usually even slightly larger Mistake 2) virtualdomains is only read once and kept im memory. Making a cdb out of virtualdomains wouldn't help with the bottleneck ;-) Right. But you're assuming that qmail-send would read the whole of virtualdomains in at startup when it's a cdb file. I would imagine a more sensible strategy would be to read the relevant entry per email - as is done with the other cdb files. Then the discussion is - reading it at HUP *once* and doing in-memory scans versus - a cdb lookup for every delivery. I can tell you now that reading it once will only in very rare conditions give worse performance. True enough, but only virtualdomains has the opportunity to be read just once. smtproutes and rcpthosts (and badmailfrom especially) are read on each invocation of qmail-smtpd. One problem with the current setup is that control.c issues 64 bytes reads. I changed that on one system that had very large smtp control files to do larger reads and it made a significant impact. It also seems that Dan thinks at least some smtp control files are suited to this setup: witness morercpthosts. Regards.
Re: badmailfrom
On Fri, Nov 17, 2000 at 07:07:36PM -, Kevin Smith wrote: Hi All, The file badmailfrom in the /var/qmail/control directory, how do I enter only a domain name to stop receiving mail, instead of enter the full email address? I've tried the following : *@domain.com [EMAIL PROTECTED] Which does work, any ideas? I know it's cheating, but I believe that the manpage for qmail-smtpd tells you exactly what to do. Regards.
Re: Duplicated Messages
On Fri, Nov 17, 2000 at 03:06:52PM -0600, Dave Gresham wrote: I have been receiving multiple copies of messages from the qmail mailing list for a couple weeks. I talked to Dave Sill who suggested I send mail to DJB, which I did, however to date I have not heard anything. Are you continuing to get them? I wonder whether your Exchange server is accepting the message into its queue, but then not sending a "250 ok" or the "250 ok" is not making it back either due to network issues or timeout exceeded. all the messages seem to be coming from: muncher.match.uic.edu with the same message id's. And at quite different times which suggests muncher is retrying the message presumably because it thinks that the previous delivery attempt failed. Certainly the qmail logs at muncher would confirm the delivery outcome that it is seeing. Regards. here are a couple samples: Received: from muncher.math.uic.edu ([131.193.178.181]) by epmail0.ltfinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WQAZ74CF; Fri, 10 Nov 2000 09:33:42 -0600 Received: (qmail 9752 invoked by uid 1002); 9 Nov 2000 14:45:30 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 31147 invoked from network); 9 Nov 2000 14:45:30 - Received: from unknown (HELO zephyr.SoftLock.com) (216.34.101.242) by muncher.math.uic.edu with SMTP; 9 Nov 2000 14:45:30 - Received: (qmail 14895 invoked by uid 71); 9 Nov 2000 14:45:40 - Received: from unknown (HELO arbor.softlock.com) (63.103.65.14) by 216.34.101.242 with SMTP; 9 Nov 2000 14:45:40 - Received: by arbor.softlock.com with Internet Mail Service (5.5.2650.21) id W2W8NZCQ; Thu, 9 Nov 2000 09:47:54 -0500 Message-ID: [EMAIL PROTECTED] From: Greg Owen [EMAIL PROTECTED] To: "Qmail List (E-mail)" [EMAIL PROTECTED] Subject: RE: How maybe times qmail will retry send the bounce email? Date: Thu, 9 Nov 2000 09:47:53 -0500 Received: from muncher.math.uic.edu ([131.193.178.181]) by epmail0.ltfinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WQAZ7TWA; Fri, 10 Nov 2000 06:13:45 -0600 Received: (qmail 9752 invoked by uid 1002); 9 Nov 2000 14:45:30 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 31147 invoked from network); 9 Nov 2000 14:45:30 - Received: from unknown (HELO zephyr.SoftLock.com) (216.34.101.242) by muncher.math.uic.edu with SMTP; 9 Nov 2000 14:45:30 - Received: (qmail 14895 invoked by uid 71); 9 Nov 2000 14:45:40 - Received: from unknown (HELO arbor.softlock.com) (63.103.65.14) by 216.34.101.242 with SMTP; 9 Nov 2000 14:45:40 - Received: by arbor.softlock.com with Internet Mail Service (5.5.2650.21) id W2W8NZCQ; Thu, 9 Nov 2000 09:47:54 -0500 Message-ID: [EMAIL PROTECTED] From: Greg Owen [EMAIL PROTECTED] To: "Qmail List (E-mail)" [EMAIL PROTECTED] Subject: RE: How maybe times qmail will retry send the bounce email? Date: Thu, 9 Nov 2000 09:47:53 -0500 Received: from muncher.math.uic.edu ([131.193.178.181]) by epmail0.ltfinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WQAZ7TTM; Fri, 10 Nov 2000 03:15:05 -0600 Received: (qmail 9752 invoked by uid 1002); 9 Nov 2000 14:45:30 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 31147 invoked from network); 9 Nov 2000 14:45:30 - Received: from unknown (HELO zephyr.SoftLock.com) (216.34.101.242) by muncher.math.uic.edu with SMTP; 9 Nov 2000 14:45:30 - Received: (qmail 14895 invoked by uid 71); 9 Nov 2000 14:45:40 - Received: from unknown (HELO arbor.softlock.com) (63.103.65.14) by 216.34.101.242 with SMTP; 9 Nov 2000 14:45:40 - Received: by arbor.softlock.com with Internet Mail Service (5.5.2650.21) id W2W8NZCQ; Thu, 9 Nov 2000 09:47:54 -0500 Message-ID: [EMAIL PROTECTED] From: Greg Owen [EMAIL PROTECTED] To: "Qmail List (E-mail)" [EMAIL PROTECTED] Subject: RE: How maybe times qmail will retry send the bounce email? Date: Thu, 9 Nov 2000 09:47:53 -0500 next message--- Received: from muncher.math.uic.edu ([131.193.178.181]) by epmail0.ltfinc.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WQAZ7TKH; Thu, 9 Nov 2000 20:37:53 -0600 Received: (qmail 20791 invoked by uid 1002); 8 Nov 2000 17:33:57 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 6383 invoked from network); 8 Nov 2000 17:33:56 - Received: from orion.insign.ch (HELO orion.8304.ch) ([EMAIL PROTECTED]) by muncher.math.uic.edu with SMTP; 8 Nov 2000 17:33:56 - Received: (qmail 23117 invoked by uid
Re: Qmail repeating system name in address
In addition (again thanks to Charles) you could try adding system.system to your locals file. No. Don't do that. It's a completely bogus solution. Better to understand what you want to do and use the configuration appropriately. For example, consider: defaultdomain, plusdomain and the like. A read of the qmail-control man page is a good place to start. Regards. - Original Message - From: "Dave Sill" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 16, 2000 7:42 PM Subject: Re: Qmail repeating system name in address Jamin Collins [EMAIL PROTECTED] wrote: As it stands currently I've been stuck at testing local delivery. Every test message I tried would result in a bounce. In the bounced message I could see that for some reason qmail was adding additional information to the addresses. For example if I addressed a message to "user@system" the bounce message would show "[EMAIL PROTECTED]". I only have three control files at the moment: me, locals, and rcpthosts. All of these files have the same information in them. Originally this entry was "system". However in order to stop qmail from repeating I had to change this to "system.". Can someone explain why this was necessary? I feel that if I understand this, it will help with future delivery problems. "me", "locals", and "rcpthosts" are supposed to be a fully qualified domain names. E.g., hostname.domain.tld. SMTP and qmail both require addresses to be fully qualified. -Dave
Re: control files on an NFS share?
On Thu, Nov 16, 2000 at 05:40:27PM -0600, Ben Beuchler wrote: Our one qmail/vpopmail server is about to become a node in a load balanced pool of mail servers. I plan to mount the queue via NFS (I am now, in fact) but am wondering about the control files. It seems that Ouch. You will, at some stage, lose mail this way. Is it actually working? at least SOME of them should be safe to share over NFS. Any thoughts or recommendations? Anything but queue is probably ok. Regards.
Re: qmail 1.04
On Fri, Nov 17, 2000 at 02:55:51AM +0100, Peter van Dijk wrote: On Thu, Nov 16, 2000 at 10:03:06PM +0100, Balazs Nagy wrote: [snip] It probably would also be cool to have a cdb for vitualdomains, just like morercpthosts. That would mean that virtualdomains updates are instantly instead of only happening at SIGHUP? There is no performance benefit in having virtualdomains as a cdb. Heh. I have 75 domains managed and the virtualhost file contains about the same number of lines. It's not a performance issue but a management one. How would having virtualdomains being a cdb help you manage better? By saving on the HUP to qmail-send? Regards.
Re: qmail 1.04
I made two mistakes, when I wrote that I want to have a cdb ;-) We're currently experiencing some temporary performance problems with our qmail server. This is due to large smtproutes and rcpthosts files and some I/O bottleneck on the disk they're located. Mistake 1) A cdb wouldn't help with this problem, as its usually even slightly larger Mistake 2) virtualdomains is only read once and kept im memory. Making a cdb out of virtualdomains wouldn't help with the bottleneck ;-) Right. But you're assuming that qmail-send would read the whole of virtualdomains in at startup when it's a cdb file. I would imagine a more sensible strategy would be to read the relevant entry per email - as is done with the other cdb files. Regards.
Re: Temporary long delay (Qmail and Real -Time )
On Fri, Nov 17, 2000 at 12:43:55PM +0600, Kornyakov Yevgeniy wrote: I have strange delay -- If clients (or other servers) d't use my SMTP server during 10 (or more) minutes appear timaut about 1 min. After this timeout all working OK - without some timeout till next pause from work SMTP server... I use tcpserver with -R -H options and Slackware linux... I suspect this problem have to do with reduce process prioritet and remove all qmail daemons to swap... How I can avoid this ??? I'd be surprised if it's a swap issue. qmail-smtpd and qmail-queue are very small programs. Have you used things like vmstat to confirm your suspicion about swapping? You also need to give us more details about the delays. Where do they occur exactly? When the remote site tries to connect? When the mail is accepted and placed in the queue? When it's in the queue and waiting to be delivered? What happens when you do a manual smtp session to your server using telnet? Where do you see the delays? Regards.
Re: secrets and lies
On Tue, Nov 14, 2000 at 01:20:32PM -0600, Mate Wierdl wrote: I am reading this book by B. Schneier, in particular, the section `Cracking and hacking contests'. He thinks that contests (like offering $1000 for finding a security hole in a product) are bad for four main reasons, the first reason being that the contests are usually unfair since the author of the software decides what he/she considers a "hole". He also thinks that even having a software out and used for a few years without incidence does not imply that it is secure. He says, the best way to evaluate the security of a product is to have it audited by security experts. Does he mean by a company such as the one he runs (that sells security audit services - surprise surprise) or does he mean a non-commercial audit such as that done by the OpenBSD folk or the informal one of a "thousand eyes" of the open source community? It's all about increasing confidence levels. Whilst an audit is a good idea, I don't see how a competition and time in the field can actual make matters worse. Certainly no worse than relying on an audit and happening to select an incompeted expert (of which there are plenty specializing in security at the moment - one recently expressed surprise to me that qmail was running an x86 Solaris as "that was usually installed on Sparcs"). But to answer your question, I've not seen mention of a formal audit of qmail by certified security experts (or by self-appointed script kiddies for that matter). However, it would be very interesting to see such an audit. Mr Schneier could convince a lot of sceptics if he conducted an eye-opening audit on qmail. Regards.
Re: secrets and lies
Not to mention that the whole point of freeware and open source software in general is to give everyone the ability to audit the software, not just a select few. It sounds like the author of this book is a M$-type weenie. I don't think so. He's the author of perhaps the most popular book on computer security that's available to the public. He's generally well regarded - though having sendmail 8.8.8 on the secondary MX of his domain doesn't make you feel super confident : Regards.
Re: secrets and lies
On Tue, Nov 14, 2000 at 03:35:35PM -0500, Paul Jarc wrote: [EMAIL PROTECTED] writes: Whilst an audit is a good idea, I don't see how a competition and time in the field can actual make matters worse. It can make people think a program is secure when no audit has been done, reducing the likelihood that anyone will call for an audit, leaving holes undiscovered. Conversely, maybe an audit reduces the likelihood that anyone will bother to scuitinize the source, leaving holes undiscovered... All we're doing is speculating about which source of a "false sense of security" is worse. Both have serious weaknesses. Ideally of course we have lots of points of reference to give us confidence - a formal audit, public scrutiny, large field usage, etc. I don't think that any one is enough. On that basis, the more boxes you tick off, the closer you get to feeling comfortable. Regards.
Re: secrets and lies
On Tue, Nov 14, 2000 at 04:13:19PM -0500, Bennett Todd wrote: 2000-11-14-15:07:28 [EMAIL PROTECTED]: [Bruce Schneier is] the author of perhaps the most popular book on computer security that's available to the public. Which book are you referring to? "Secrets and Lies"? While it's a Nup. If you mean Applied Cryptography, it's certainly the most valuable Yup. He's generally well regarded - though having sendmail 8.8.8 on the secondary MX of his domain doesn't make you feel super confident : As a computer security generalist (as opposed to a cryptanalyst), his major thrust seems to be an argument that it's impossible to really secure systems, and after perhaps some superficial efforts to knock out the biggest problems, the place to concentrate your efforts is on monitoring and risk management. With that as a given, I expect he runs sendmail and BIND; things like qmail and djbdns are for those of us who haven't given up on really completely securing our systems:-). Postfix is on the primary MX, go figure. Biodiversity I suppose... Regards.
Re: secrets and lies
On Wed, Nov 15, 2000 at 01:14:15PM +1300, Chris K. Young wrote: Quoted from Lipscomb, Al [15 Nov 2000]: Open Source is often used to describe software that has its source code available regardless of the license involved. Just because it's ``often'' done doesn't mean it's correct. To me, and possibly others, open source is used to describe software that uses a licence conforming to the Open Source Definition. Have a look at clause 4, and let me know if you think that's consistent with the qmail and djbdns licences. Specifically: ``The [licence] must explicitly permit distribution of software built from modified source code.''. I'm confused. How exactly does any of this affect the ability of people to download the source and examine/use it to determine if it's secure or not? After all, wasn't that the point of the discussion? Regards.
Re: Date: field rewritten?
On Mon, Nov 13, 2000 at 01:02:14PM -0500, Enrique Vadillo wrote: Hi, Some of my users are complaining that Qmail is rewriting dates showing in the "Date:" field, for instance, if someone write some message from France right now being 1 pm here and 7 pm in Paris, it shows our 1 pm local time under qmail, a copy of the *SAME* message in a sendmail-based box shows me 7 pm as the "Date:" field which is -i believe- accurate. What do i have to dso so shat Qmail does NOT rewrite Date: fields?? It sounds like you didn't both to check the complaint. Did you actually look at the mails? Did you try and reproduce the problem? Did you check the qmail documentation? Did you search the qmail archives for similar questions? Qmail doesn't modify headers. UAs sometimes convert headers to something they think you want to see. Regards.
Re: Long Local Delivery Delays
On Mon, Nov 13, 2000 at 04:39:11PM -0500, Jamin A. Brown wrote: Hello, We have just completed migrating a sendmail installation for roughly 15000 users to qmail. After doing so, we are experiencing longish delays on the delivery of incoming messages. What sort of passwd technology are you using? /etc/passwd? NIS, NIS+? The delay seems to occur from when mx0 accepts the message to when mx0 writes it to the user's Maildir. My guess would be that the queue is not being processed fast enough. If you showed us some log entries from start of delivery to completion we'd be able to tell you whether they seem slow or not. We are seeing delays of up to a couple hours on messages, so any assistance or pointers in the right direction would be appreciated. Show us the specific log entries for some of these deliveries. We can only speculate in the absence of information. Regards.
Re: Concurrency of qmail-command
On Sat, Nov 11, 2000 at 06:49:11PM -0800, Ellen Spertus wrote: I'm unable to figure out from the FAQ and man pages how much concurrency there is in local delivery when users have commands in their .qmail-* files. To be concrete, assume the following files are in ~ellen: .qmail-foo | foo .qmail-bar | bar My questions are: 1. If a message arrives for ellen-foo, qmail-local will begin running foo. If a second message to ellen-foo arrives while the first instance of foo is running, will two foo processes run at once? If concurrencylocal is greater than one, then sure. There is no per-user concurrency constraint that is additional to the system-wide ones. 2. Same question, but about messages sent to ellen-foo and ellen-bar. Could the foo and bar processes run concurrently? Same answer. 3. Am I right to assume that mail to different users is completely independent; i.e., my having a slow process won't delay other users from having their messages processed? Excepting if a single user consumes all concurrencylocal slots, then other deliveries will have to wait until a slot comes free. Regards.
Re: Balancing multiple queues
On Fri, Nov 10, 2000 at 03:07:56PM -0500, [EMAIL PROTECTED] wrote: Interesting idea. I have concurrency remote right now at 257, have the big-todo patches in etc. But whenever i do a ps ax| grep qmail-remote -c Its usually between 30-90. I have over 60k messages in the queue. Goes out fast, but still i think it could go faster? Any reasons for this? Without seeing the logs we'd be guessing. You can find the exact peak concurrency from the logs (why use an inaccurate ps for this?). You can see if qmail-remotes are exiting abnormally from the logs. starting to hunt for RAMdisk info... Check your logs first. RAMdisk is unlikely to affect your system reaching concurrency-remote if you're not injecting new mails at the time. Regards.
Re: qmail 1.04
On Thu, Nov 09, 2000 at 08:13:01PM +, Greg Cope wrote: out of the patches - but I just trying to be flexible (big-concurrency apears the only essential one in humble view.) Which hopefully will be irrelevant with zeroseek. Regards.
Re: Pointers
On Tue, Nov 07, 2000 at 11:50:51PM -0700, Travis Turner wrote: I am almost there and having almost the same problem as the Maildir guy. for some reason when I send a message to the server for a local user it will not direct it to the correct mailbox. Is there some sort of pointer that I need to set up that says deliver local mail to the /home/user/maildir format? I am almost there darnet and no sleeping until its done. Thanks for the help Your logs are your friend. Experienced qmail users on this list will know what is wrong if you show the logs associated with the delivery. Why not give them a chance to help you? Regards.
Re: No maildir log file??
On Wed, Nov 08, 2000 at 08:37:04PM +1100, Brett Randall wrote: So, when you echo "" Mailbox, you are missing one crucial step. Change the ownerships BACK to the owner. ie the user that will Hmm. Generally speak, if the file already exists, then the ownership and modes are unchanged. Agreed it depends on the shell. Basically, what you are doing is silly. Modifying a file which could be in use by some other process (especially log files) is likely to cause you hell. Agreed. When modifying or replacing a file it behooves you to understand how to interact with the program(s) accessing to that file. It differs depending on the program. You cannot treat a mailbox like a syslog file and you cannot treat a syslog file like a multilog file, etc. Regards.
Re: connections ???
On Wed, Nov 08, 2000 at 02:08:37PM +0200, tag wrote: Michael Maier wrote: tag wrote: Get qmail-analog mentioned on www.qmail.org CU, Michael! I have it - how is it going to help me ??? qmail-analog looks into your Log Files and provides Programs to show Statistics of your Mail Server. Nope. qmail-analog is for qmail-send logs, NOT tcpserver logs. I know that - what I do not know is what the : 973696610.343762 tcpserver: end 16494 status 256 status 256 is from - and as you can see - it is from tcpserver . It's the exit status of process 16494 (presumably qmail-smtpd) as returned by the wait() system call to tcpserver. You'll need to read up on the wait() system call to understand why the value is 256, but here's a snippet: o If the child process terminated due to an _exit() call, the low order 8 bits of status will be 0 and the high order 8 bits will contain the low order 8 bits of the argument that the child process passed to _exit(); see exit(2). In the case of qmail-smtpd it can mean a variety of things, but generally that it failed to get input from the socket when it expected. qmail-smtpd only exits with a status of zero if it gets a QUIT. Regards.
Re: maildir script ?
On Wed, Nov 08, 2000 at 03:18:46PM +1100, Dennis wrote: Hi all... Anyone know where I can find the "maildir" script as discussed in the qmail book, page 196 ? It's not in the "/var/qmail/boot" dir as the book suggests or anywhere else in the qmail src file. Since many of us haven't read that particular book (the real thing is coming "Real Soon Now" (tm)"), perhaps you could elaborate on what it does. I'll hazard a guess that you can trivially construct such a script with the /var/qmail/bin/maildirmake program supplied with qmail. Regards.
Re: maildir script ?
On Wed, Nov 08, 2000 at 03:41:02PM +1100, Brett Randall wrote: Then the question beckons, is this the best way to start qmail up ? By all accounts the book you are reading is not really top-notch. If you're asking this, you should really read Life with Qmail http://web.infoave.net/~dsill/lwq.html. You'll learn something useful from it ;) But this reference is. Mark.
Re: tcpserver dying?
Was it started at reboot or did you start it manually? If the latter, did it exit when the login session that started it, logged out? How about now? How did you restart it? Reboot or manually? If the latter, is that login session still going? Regards. On Mon, Nov 06, 2000 at 08:57:10AM -0500, Hubbard, David wrote: Hi all, does anyone know why tcpserver would die? I have a lightly hit server and discovered that it was not servicing pop3 requests anymore, tcpserver was not running. The only non-standard things I'm doing is authenticating with vchkpw from the vpopmail software. It started right back up but I see no reason why it would have stopped. Here's how I start it: case "$1" in start) # Start daemons. echo -n "Starting the POP3 daemon: " env - PATH="/var/qmail/bin:/usr/local/bin" \ tcpserver -v -g 200 -u 407 -p -R 0 pop3 \ /var/qmail/bin/qmail-popup my.server.com \ /home/vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d Maildir 21 | \ /var/qmail/bin/splogger pop3 20 echo "Done." ;; Thanks, David
Re: Quota on outgoing mail
On Sat, Nov 04, 2000 at 11:56:33AM -0700, Andy Bradford wrote: Thus said Jens Georg on Sat, 04 Nov 2000 19:49:57 +0100: echo 10485760 /var/qmail/control/databytes is this really enough ? i remember to read once that qmail has to be compiled specially to use this feature. Yes, this really is all that needs to be done---no special compiling or patches. Read the man pages and you'll see. ;-) And once you have that limit in place, just make sure your users don't send two mails of half the size to get around this limit... databytes will stop naive dis-interested users, but not determined naive users. Regards.
Re: qmail-rspswn
On Thu, Nov 02, 2000 at 02:10:33PM -0600, Erich Zigler wrote: I had been getting complaints lately that mail was being delivered slower then usual through one of my servers. This server houses several semi-high traffic domains and a fairly large traffic mailing list. I logged into the server and the queue wasn't that bad. 150 messages or so. But when I looked at the qmail processes qmail-rspawn was taking up 30+MB of RAM. I quickly restarted qmail and things returned to normal and the load average dropped. I was wondering what could have caused this errata and how I can prevent it in the future. Which OS Erich? I've seen this once before - but it'll take my braincells a little while to recall which OS. The server I saw it on wasn't doing anything particularly different. Regards.
Re: qmail-rspswn
On Thu, Nov 02, 2000 at 04:37:41PM -0600, Erich Zigler wrote: On Thu, Nov 02, 2000 at 01:47:27PM -0800, [EMAIL PROTECTED] wrote: Which OS Erich? I've seen this once before - but it'll take my braincells a little while to recall which OS. The server I saw it on wasn't doing anything particularly different. FreeBSD 3.3. I'm really confused. Everything "appears" to be fine, but it is taking a long time to process messages. Are you saying that qmail-rspawn regrows to 30M (or thereabouts) fairly immediately? Or are you making a general observation that "things seem slow"? In the latter case you'll want to resort to the usual strategies of looking at the delivery rate, looking at your system resources, etc. Regards.
Re: Don't understand
On Wed, Nov 01, 2000 at 02:24:51PM -0800, Howard Miller wrote: Sorry, sorry, sorry. I am not really a newbie as such, but I am to MTAs. I can usually get In which case you will have understood why an earlier poster asked that you send the logs so we can see what's happening. In spite of that and you "not really (being) a newbie", you still haven't supplied them. Without logs we can offer no opinion at all. things going but I have been at this for nearly two weeks and I simply can't get it to work. It is at best confusing that the INSTALL documentation in the tarball suggests a different installation from the Howto, and is different again from "Living with qmail" (which DOES have some mistakes that even I spotted). In which case, please send your observations to the author of that document, he wants to hear feedback that improves his work. I have by now tried all of them, reloading Linux on my test machine each time. In each case something doesn't work and I am frustrated that documentation seems (to me anyway) to be lacking. I don't think that my requirements are in anyway strange (I need an ISP style setup - all local lan users though - with smtp and pop3). Your requirements are absolutely normal and many thousands of people have installed qmail without a glitch in such environments. The experience of this list is that most people who come to it saying "it doesn't work", usually end up finding they have not follow instructions to the letter. And, be warned - if you claim that you have you'll need to support that claim with proof. I am using SuSE V7 linux, if anybody out there has got a simillar arangement on a similar platform to work correctly I would be most interested to hear from them how they did it. Sorry to everybody again, for getting stroppy - you know what its like when you foolishly promise something in a few days.. oh well. Might I be better just using sendmail, which is built in to SuSE and seems Whatever floats your boat. You're the one who lives with your choice, not us. But if you want to persist with qmail, then you will need to give details. Like logs files, config settings, what is and isn't working, that sort of thing. Regards.
Re: multi-rcpt for qmail
On Wed, Nov 01, 2000 at 02:04:54PM -0600, Charles Cazabon wrote: Bruce Guenter [EMAIL PROTECTED] wrote: This brings me to a question: should the grouping of recipients by domain name be done in qmail-send or qmail-queue? My gut reaction would be in qmail-queue. However, that might make it a little more difficult to do this optimization when mail comes in via qmail-smtpd. Why? qmail-smtpd feeds the mail into qmail-queue, just as all injection programs (ie, qmail-inject, qmail-smtpd, qmail-qmqpd, ezmlm-send). Another question: is it legal in SMTP to temporarily defer one recipient and not another? Doesn't this currently happen with qmail anyways, because each recipient is handled as a separate message and can be deferred, while others go through? I think he means by way of a non-"250 ok" response during the SMTP conversation. The answer is that the protocol allows it, but many programs that talk smtp don't handle it - especially MUAs. But how is that relevant to qmail-queue sorting the recipients? Regards.
Re: Blocked pipe to qmail-queue
On Mon, Oct 30, 2000 at 12:28:06PM -0800, Jeff Mayzurk wrote: I'm trying to write an efficient C interface to feed messages with large recipient lists (500k+ subs) to qmail. I've set up a pipe to qmail-queue in the style of qmail.c and ezmlm, except I'm not using the substdio library. The pipe works fine for small distribution lists, but I'm getting consistent blocking after writing about 10KB of addresses (around 400 recipients) to the pipe. qmail-queue is blocked in read() and my returns EAGAIN indefinitely on write(), or blocks indefinitely without O_NONBLOCK set. Sounds like an OS bug. If you're sure that qmail-queue is sitting on the pipe read and you're sitting on a pipe write to the same pipe. What OS? Can you test your code on another box with a different kernel/OS? Am I missing something? Anyone else successfully written a C interface to qmail-queue they'd be willing to share? Plenty of people have done it via qmail-inject with larger numbers than that, and qmail-inject doesn't do anything special. Certainly there is no need for you to go thru the machinations of non-blocking I/O, etc. Regards.
Re: Blocked pipe to qmail-queue
On Mon, Oct 30, 2000 at 01:29:49PM -0800, Ian Lance Taylor wrote: Date: Mon, 30 Oct 2000 12:28:06 -0800 (PST) From: Jeff Mayzurk [EMAIL PROTECTED] The pipe works fine for small distribution lists, but I'm getting consistent blocking after writing about 10KB of addresses (around 400 recipients) to the pipe. qmail-queue is blocked in read() and my returns EAGAIN indefinitely on write(), or blocks indefinitely without O_NONBLOCK set. You need two pipes to send information to qmail-queue. In which order are you writing and closing them? That sounds right to me, well spotted. So qmail-queue is not reading the same pipe that the program is writing to. Regards.
Re: people are definately starting to harvest emailadresses on this list...
On Sat, Oct 28, 2000 at 04:55:14PM -0700, Russ Allbery wrote: markd [EMAIL PROTECTED] writes: Indeed this is an excellent strategy - if done properly. The problem is, a lot of people don't have the ability to capture all addresses in a domain - and of course user-random@domain is trivially defeated by a competent slicer and dicer if user@domain is valid. There's a simple solution to that. Use user@domain as another spam trap and have your *real* address that you give out to people who you want to have a stable address be user-something@domain and be careful about revealing that something. :) That's a good idea Russ. Regards.
Re: people are definately starting to harvest emailadresses on this list...
On Sat, Oct 28, 2000 at 10:28:51PM +1100, Brett Randall wrote: Martin is there any chance that the list's admin would consider Martin removing the header info that shows the adress of the sender Martin before sending it on to the list? I wouldn't recommend this...how then can we do personal replies when a list reply is not necessary? We will have to do it usenet-style and put "Please reply to [EMAIL PROTECTED] (remove _nospam)" in our signature files. Lucky for us Gnus users we can make those be processed automatically, but it is still messy. Hmm. Lemme get this right. You're telling me that people modify their email addresses so that spammers cannot automatically harvest them yet you then say that Gnus has code that automatically processes them? Are all harvester programmers too dumb to make this connection? I doubt it. In other words I'm sceptical of some of these strategies. If I were a harvest programmer I'd be more than happy to slice and dice such addresses to get all reasonable permutations. If a harvest gets a few bogus addresses out of it, do they care? I doubt it. A better alternative, IMHO, is to use a certain anti-spam e-mail address (someone on this list uses it but I can't remember who) that only lasts like a week, and then its gone. This gives most ppl enuf Indeed this is an excellent strategy - if done properly. The problem is, a lot of people don't have the ability to capture all addresses in a domain - and of course user-random@domain is trivially defeated by a competent slicer and dicer if user@domain is valid. So this strategy only truly works for personal domains. time to reply. This won't cut down your bandwidth, however, but it If you can control your DNS you can apply a similar strategy to your domain by generating a reply address of [EMAIL PROTECTED] where @domain is not a valid mail target. But again, the number of people who have the opportunity, or capability to do this, are low. Regards.
Re: unsubscribe qmail
On Sat, Oct 28, 2000 at 02:29:11AM +0100, Ricardo Cerqueira wrote:
On Fri, Oct 27, 2000 at 03:39:43PM -0700, [EMAIL PROTECTED] wrote:
Hmm. Maybe I'm confused. How do people think the envelope sender
value is determined in the first instant? Eg, how does Eudora go from
a mail in a window to "Mail From: " in SMTP? Or how does qmail-inject
for that matter?
qmail-inject uses environment variables for From (not From:).
What are you talking about? What does "From (not From:)" mean?
If you deduced this from qmail/djb-docs, all of these references
(unless specifically talking about final delivery) mean the "From:"
header. You might care to read cr.yp.to/immhf.htm for a more general
discussion on mail headers.
The only "From" that qmail-inject deals with is "From:". If you think
otherwise show us some output from qmail-inject -n that has this
mysterious "From (not From:)" that you refer to.
If you are referring to the "From " line, this is not a mail header,
that any part of the mail injection deals with. Instead, "From " is a
very poorly defined delimiter in V7 mailboxes that is generated at
final delivery which has nothing to do with injection.
If you still don't believe me and you don't want to bother explain
by demonstration, have a look at this code from qmail-inject.c:
void defaultfrommake()
{
...
df.t[df.len].s = "From";
df.t[df.len].slen = 4;
++df.len;
df.t[df.len].type = TOKEN822_COLON;
It's the only piece of code that has "From" and it looks like "From:" to me.
For those who do not use qmail-inject directly (Like those using remote
SMTP with Eudora, to use your example), the "From" is generated by the MUA.
So yes, those cases are "hopeless". "From:" will almost certainly be the base
for "From"
I think you're confused. There is no "From" that is separate from "From:".
If you think otherwise, inject a mail into qmail via SMTP using a mail client
like Eudora and show us the queue file with this "From" header you refer to.
(Use a target address that cannot be delivered so you can catch the queue
entry).
The answer is that it's mostly derived from a parse of the various
headers in the original mail when it's injected into the MTA. In
many cases the most likely header that will be used to derive the
envelope sender will be the From: header. So to suggest that the
unparsed From: header is a better place to look for the sender
seems a bit silly to me because in many cases the envelope sender is
simply a parsed version of the From: header.
Not really. You can have very odd "From:" lines (with 8bit chars, spaces),
but From is (or should always be) a plain old user@domain string. It's
easier to parse, and probably less prone to error.
Are you sure you're not confusing this discussion with the "From " line
that is generated on delivery into a mailbox? Which by the way *is*
used to stash the envelope sender address, which *is* original derived
from fields like "From: ".
Regards.
Re: people are definately starting to harvest emailadresses on this list...
Here's a crazy idea: And it puts the pressure on crap MUA's, too :) Use the user-random@domain format, but have the e-mail piped through a command that checks the References in the e-mail, and if it contains a valid reference to an e-mail that was posted from your own mail relay, then it passes it, otherwise, it bounces it (or trashes it). How does that sound? Have I missed anything? That's not a bad idea. Allbut the original harvester will not have that information - assuming most lists are sold/shared sans original content. As you say, it relies on MUAs faithfully reproducing References. Fortunately for us .qmail types, mess822 provides reliable access to header fields for those who want to implement that idea. Spammers tend not to use the Subject line either, so a little pattern matching would catch that. Though why spammers tend not to use harvested subject lines is beyond me - i think it'd work a lot better than "MAKE MONEY FAST". markd If you can control your DNS you can apply a similar strategy markd to your domain by generating a reply address of markd [EMAIL PROTECTED] where @domain is not a valid mail markd target. But again, the number of people who have the markd opportunity, or capability to do this, are low. True, but there are domain hosters out there who will host your domain for $99 per year (sorry I don't know their names, I just remember coming across them on occasion) that will let you modify your DNS at will. Not as elegant as your own Yep. That'd be a pain as you have to change on something like a weekly, rotation. BIND server (which is what I have, Well heck pardner, round this neck of the woods some people might see them as fightin' words! If you'd said use djbdns, then, well, yes, we'd understand : Regards.
Re: unsubscribe qmail
On Sat, Oct 28, 2000 at 03:45:40PM +0200, Jarle Hammen Knudsen wrote: Saturday, October 28, 2000, 3:06:42 PM, you wrote: On Sat, Oct 28, 2000 at 02:29:11AM +0100, Ricardo Cerqueira wrote: You might care to read cr.yp.to/immhf.htm for a more general discussion on mail headers. HTTP 404 - File not found Sorry. .html Now wouldn't it be neat if URLs included a checksum and that your MUA only identified them as such if the checksum matched? Blue for a good URL, red for a syntactically correct, my with a checksum error. That would of course then cover mailto: as well! Regards.
Re: people are definately starting to harvest emailadresses on this list...
On Sun, Oct 29, 2000 at 12:32:47AM +1100, Brett Randall wrote: "markd" == markd [EMAIL PROTECTED] writes: markd As you say, it relies on MUAs faithfully reproducing markd References. Fortunately for us .qmail types, mess822 provides markd reliable access to header fields for those who want to markd implement that idea. I might even look into implementing this...but first, what is mess822? cr.yp.to/mess822.htmlll markd Spammers tend not to use the Subject line either, so a little markd pattern matching would catch that. Though why spammers tend Hehe good point, except subject matching is a hard one... You'd have to watch all outgoing mail and capture all subjects that you send. I think References is more failsafe, except crappy clients like Outlook Correct. Thus the allusion to pattern matching and I'd only use it as an additionaltest to Rreference in the event of Reference munging MUAs. BIND server (which is what I have, markd Well heck pardner, round this neck of the woods some people markd might see them as fightin' words! If you'd said use djbdns, markd then, well, yes, we'd understand : Hehe I haven't ever used djbdns so the idea didn't occur to me. Apologies DJB fans! Ok. Your horse lives - this time. Regards.
Re: people are definately starting to harvest emailadresses on this list...
through a command that checks the References in the e-mail, and if markd That's not a bad idea. Allbut the original harvester will not markd have that information - assuming most lists are sold/shared markd sans original content. My Perl is a bit rusty and I'm not game to try this just yet, but how I was more thinking of storing the generate Messsage-IDs in a database so the test is a simple lookup. Regards.
Re: SPAM - Help!
On Fri, Oct 27, 2000 at 12:37:42PM -0300, Ari Arantes Filho wrote: Hello, Someone is using another smtp server to send a very big spam, but they write the header with FROM = an unknown user of one of my virtual domains, so postmasters keep sending bounce messages or autoresponders to this unknown user and my postmaster is receving more than 1 emails. I've temporary created this unknows user, but how can I stop this? I Welcome to the world of unstoppable spam. Sorry to say Ari, you cannot stop it consuming some of your resources. I've had that happen on a site where the spammer sent something like 100K messages to AOL and about half of them were bogus addresses. Having AOL consume all your smtp concurrency for a day is not fun. You'll also probably get some hate mail from people who don't read headers closely enough and think the spam originated from your site. I'd be inclined to make the user valid and have their .qmail just be a comment so that the bounces gets delivered to nowhere. Other than that you have to sit it out. Regards.
