unsubscribe thomas.flueeli@swissonline.ch
please unsubscribe me!! thanks
unsubscribe ld@krasn.ru
unsubscribe
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 08:11:41PM +, Mark wrote: > On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: > > But FreeBSD does have a (procfs-based) truss. > > Right. But it suffers from the same problem that ktrace does in that > it starts with the next system call, not the current one. Leastwise it > does on a 4.3 I have access to, do you get something different? Nope (I'm still at PRE_SMPNG, waiting for -current to stabilize (hah!)). One idea would be to run the process under truss, and pipe the truss output through multilog, providing one with a syscall activity history without the danger of filling up partitions (as would likely happen when using ktrace). -- Jos Backus _/ _/_/_/"Modularity is not a hack." _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: How can a user put comments into rcpt to address
K. F. Yim writes: > Our user put it in the To: address box of their MS outlook mail client Qmail doesn't parse that address. MS outlook does. If it's handing the wrong thing to qmail, point the finger at MS. > and I did it from command line as well. Running qmail-inject? Qmail-inject doesn't support RFC822 addresses on its command line. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | John Hartford, RIP Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: vpopmail authentication
i also have the same problem. it is working fine on one server but it is not working on the new server i have just configured. where does it look for authentication. i have modified my qmail-pop3d.init "checkpass" /home/vpopmail/bin/vchkpw. any help. Harry - Original Message - From: "Keary Suska" <[EMAIL PROTECTED]> To: "Qmail" <[EMAIL PROTECTED]> Sent: Friday, June 08, 2001 4:25 PM Subject: Re: vpopmail authentication > Make sure you are using the correct POP id: username%virtualdomain.com > > otherwise you are checking against /etc/passwd. > > -K > > "Do not meddle in the affairs of wizards, for they are subtle and quick to > anger." > > > > From: "Franco Vecchiato" <[EMAIL PROTECTED]> > > Date: Wed, 06 Jun 2001 17:24:38 +0200 > > To: [EMAIL PROTECTED] > > Subject: vpopmail authentication > > > > I'm trying to use vpopmail with qmail on a Suse Linux PC, but I'm having a > > problem in retrieving the emails with the POP client. > > > > In vpopmail I created a new domain test.it, with a new user "utente" and > > password "testutente". After setting the right stuff into my DNS server, I > > sent an email to [EMAIL PROTECTED] The email has been delivered correctly to > > vpopmail/domain/test.it/utente/new directory and the logfile reports no > > errors, but when I try to connect to the mailserver with a POP client > > (outlook express) configured for this account, I get an "authentication > > failure" error message from the server. > > > >
Re: How can a user put comments into rcpt to address
Our user put it in the To: address box of their MS outlook mail client and I did it from command line as well. KF - Original Message - From: "Russell Nelson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 09, 2001 8:29 PM Subject: Re: How can a user put comments into rcpt to address > K. F. Yim - Netvigator writes: > > Just right after the to address [EMAIL PROTECTED](comments). > > In what file? On what command line? > > -- > -russ nelson <[EMAIL PROTECTED]> http://russnelson.com > Crynwr sells support for free software | PGPok | > 521 Pleasant Valley Rd. | +1 315 268 1925 voice | John Hartford, RIP > Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: I think I'm being relayed through, but I don't know how.
On Wed, Jun 06, 2001 at 01:44:56PM -0500, Chris Garrigues wrote: > I've got this in my queue: > > 5 Jun 2001 14:44:17 GMT #48256 5651 <[EMAIL PROTECTED]> Are you bouncing spam that has false return addresses? -- Brian 'you Bastard' Reichert<[EMAIL PROTECTED]> 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path
Re: New Broadcast Message!!!
"Kirti S. Bajwa" <[EMAIL PROTECTED]> writes: > You are plain rude. And you are plain stupid. Sometimes it's fun to watch you but mostly it's only painful to read your bullshit. Start to learn the basics, show that you have tried things before asking - then people will start to take you more seriously. At the moment you are a clown at best. And for free a cited comment from Dan: "This is Unix. Stop acting so helpless." Frank
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 01:54:37PM -0600, Charles Cazabon wrote:
> Perhaps something like a "maxlifetime" control file for qmail-remote and
> qmail-smtpd? At process startup, set an alarm for X seconds -- if the ALRM is
> received, abort the connection as gracefully as possible (i.e. try to send
> RSET and QUIT in qmail-remote, issue a 4xx error in qmail-smtpd) but quit
> regardless of whether these attempts to quit gracefully are successful or not.
>
> It doesn't sound too complicated. Anybody see any major issues with this?
No, but this may be more complicated than needed.
I've been using the attached program on one of my machines for years
(the machine was behind a dialup line and it was definitively not
funny to sponsor the Deutsche Telekom just because the other end
of a SMTP connection was slow).
It worked in it's crude form. It leaves a hole open which could
lead to duplicate transfers.
Regards, Uwe
-- setalarm.c ---
#include
#include
#include
#include
#include
static void die_usage(void)
{fputs("usage: setalarm SECONDS program [arguments ...]\n",stderr);
exit(111);}
static void die_parse(void)
{fputs("setalarm: fatal: failed to parse the number of seconds\n",stderr);
exit(111);}
static void die_exec(char *x)
{int e=errno;
fputs("setalarm: fatal: failed to execute ",stderr);
perror(x);
exit(111);}
int
main(int argc, char **argv)
{
unsigned long ul;
int e;
char *ep;
ssize_t l;
if (argc<3) die_parse();
errno=0;
ul=strtoul(argv[1],&ep,10);
if (*ep || !argv[1][0] || errno==ERANGE) die_parse();
signal(SIGALRM,SIG_DFL);
alarm(ul);
execvp(argv[2],argv+2);
die_exec(argv[2]);
}
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 08:12:03PM +, Mark wrote: > On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: > > On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: > > > It's a bummer that ktrace is like that on FreeBSD. It doesn't show the > > > *current* system call that the process is sitting on. Conversely, > > > truss on Solaris does this nicely... > > > > But FreeBSD does have a (procfs-based) truss. > > Right. But it suffers from the same problem that ktrace does in that > it starts with the next system call, not the current one. Leastwise it > does on a 4.3 I have access to, do you get something different? I get what you get :) Greetz, Peter -- Against Free Sex! http://www.dataloss.nl/Megahard_en.html
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: > On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: > > It's a bummer that ktrace is like that on FreeBSD. It doesn't show the > > *current* system call that the process is sitting on. Conversely, > > truss on Solaris does this nicely... > > But FreeBSD does have a (procfs-based) truss. Right. But it suffers from the same problem that ktrace does in that it starts with the next system call, not the current one. Leastwise it does on a 4.3 I have access to, do you get something different? Regards.
Re: qmail-remote (cry wolf?)
> Perhaps something like a "maxlifetime" control file for qmail-remote and (Serendipity strikes again - I just posted sample code for this). > qmail-smtpd? At process startup, set an alarm for X seconds -- if the ALRM is > received, abort the connection as gracefully as possible (i.e. try to send > RSET and QUIT in qmail-remote, issue a 4xx error in qmail-smtpd) but quit > regardless of whether these attempts to quit gracefully are successful or not. Why bother with a graceful exit? You'd have to set yet another alarm for the (likely) case that your graceful exit fails. That's seems like unnecessary complexity for a connection that is almost certainly dead. Regards.
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: > It's a bummer that ktrace is like that on FreeBSD. It doesn't show the > *current* system call that the process is sitting on. Conversely, > truss on Solaris does this nicely... But FreeBSD does have a (procfs-based) truss. -- Jos Backus _/ _/_/_/"Modularity is not a hack." _/ _/ _/-- D. J. Bernstein _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 03:11:59PM -0400, Russell Nelson allegedly wrote:
> Greg White writes:
> > I think we may have red-herringed on the OS thing -- if RH6.2, as
> > deployed, had this sort of problem, I think we would have run across it
> > before this, no?
>
> Hmmm I wonder. I could do a denial of service attack on
> qmail-remote by receiving email very, very slowly,
You'd also have to set the TCP/IP receive window size down, otherwise
you may think you're only receiving at one byte every, say, 20
minutes, but in fact your TCP/IP stack got a window full of data at
one time.
But yes, you could slow it down considerably and if you got to the
extreme limit of 20 minutes per byte, a 1M email will take about 9
months...
It sure is the case that some sort of gross delivery timer makes sense
and it would work around the problem that initiated this thread...
> and by sending
> email to a server which is guaranteed to be received and guaranteed to
> bounce. qmail doesn't keep track of very slow hosts, but only hosts
> that time out.
Of course it has to be your server that accepts the traffic slowly so
it's a DOS on yourself at the same time. Not the typical MO for a
successful DOS.
This is only proof of concepts, but to implement a gross timer, you
might use this program as a wrapper to qmail-remote (which of course
you move to qmail-remote.real):
main(int argc, char **argv)
{
alarm(5*60*60); /* Max of five hours for a remote delivery */
execv("/var/qmail/bin/qmail-remote.real", argv);
_exit(1);
}
This wrapper gives qmail-remote an arbitrary 5 hours to make a
delivery at which point qmail-remote gets a SIGALRM which it happens
not to have registered a handler for and thus the OS takes the default
action which is to terminate the process.
Regards.
Re: qmail-remote (cry wolf?)
Russell Nelson <[EMAIL PROTECTED]> wrote: > > Hmmm I wonder. I could do a denial of service attack on > qmail-remote by receiving email very, very slowly, and by sending > email to a server which is guaranteed to be received and guaranteed to > bounce. qmail doesn't keep track of very slow hosts, but only hosts > that time out. I've been thinking along the same lines. qmail-smtpd would seem to also be vulnerable to this (not that this is djb's fault). Lowering timeoutremote and timeoutsmtpd from their defaults of 1200 would help against this problem cropping up due to genuinely slow servers, but not against a deliberate attack (send one byte every ten minutes, or two minutes, or whatever, tying up a qmail-smtpd process for an indefinite period). Perhaps something like a "maxlifetime" control file for qmail-remote and qmail-smtpd? At process startup, set an alarm for X seconds -- if the ALRM is received, abort the connection as gracefully as possible (i.e. try to send RSET and QUIT in qmail-remote, issue a 4xx error in qmail-smtpd) but quit regardless of whether these attempts to quit gracefully are successful or not. It doesn't sound too complicated. Anybody see any major issues with this? Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
Re: qmail-remote (cry wolf?)
Greg White writes: > I think we may have red-herringed on the OS thing -- if RH6.2, as > deployed, had this sort of problem, I think we would have run across it > before this, no? Hmmm I wonder. I could do a denial of service attack on qmail-remote by receiving email very, very slowly, and by sending email to a server which is guaranteed to be received and guaranteed to bounce. qmail doesn't keep track of very slow hosts, but only hosts that time out. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | John Hartford, RIP Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 09:05:00AM -0700, Greg White allegedly wrote: > I think we may have red-herringed on the OS thing -- if RH6.2, as > deployed, had this sort of problem, I think we would have run across it > before this, no? The inclusion of a FreeBSD-4.2-STABLE in the mix seems > to nix a RH specific bug as well (althought it obviously does not rule > it out entirely*). Perhaps we're overlooking some other, more subtle > commonality between these four setups? Indeed. Using commonality to solve a problem is a fine technique. However the underlying assumption is that it is a single problem that is being solved here. We have no certainty of that, all we do have is a single *symptom* - qmail-remote wedges on some systems, on some occassions. If it is a single problem, here are some commonalities that might be explored: 1. Bug in qmail-remote 2. Common compiler (think optimization error) 3. Common clib error (think semantic error or bug) 4. Common OS (think semantic error or bug) 5. Common TCP/IP stack 6. Common network interface code (perhaps all derived from a vendor reference implementation) All of which *may* only be triggered by a certain set of TCP/IP events initiated from the peer end. Indeed the peer may be an uncommon OS/TCP/IP combo which reduces the occurence of this problem to isolated situations. And you can be very certain that this is a very very rare event. Just consider how many invocations of qmail-remote have successfully completed in the last 3 years on many many thousands of OSes in many thousands of locations around the world. What does that mean? It's probably a tough problem to nail down without access to the interaction history between all of the above components. Regards.
Re: error qmail
A good howto on setting up Qmail on FreeBSD 3* / 4* is available here. I have used it on 5 servers and have yet to have any problems http://howto.globelinks.com/qmail-howto-freebsd.html Thanks Jps - Original Message - From: "budsz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 09, 2001 6:57 AM Subject: error qmail > Hi... > > When i compiled qmail in FreeBSD 4.2 ,i got some message "multilog: > fatal: unable to lock directory /var/log/qmail: temporary failure" > > what is that mean? and how i can resolve that. > > BTW where i can find URL/e-books for install qmail in FreeBSD. > > TIA > > > budsz >
Re: qmail-remote (cry wolf?)
> As far as I can tell, this is a problem between qmail-remote and the kernel. Correct. > This is happening on multiple operating systems, so that leads me to believe > that this is not an OS bug. But many OSes share TCP/IP implementations or mis-interpretations of the protocol. Many coders of TCP/IP stacks look at other implementations to work out what to do. There is a *lot* of commonality between OSes in this regard. Eg, the Linux crowd and the FreeBSD crowd reguarly refer to each others implementations to decide how to do something (or not do something as the case may be). > ** To find out a bit more about what a "stuck" qmail-remote is doing, you > ** may want to ktrace it and show us the output. Find the process id of the > ** stuck qmail-remote and then as root go: ktrace -p thepid > ** > ** Leave that running for at least an hour and show us the output. Yes, I > ** mean at least an hour. > ** > > Ok, I meant to come back in an hour and stop the trace, but after running > ktrace for 9 hours (while I slept), the resulting ktrace.out file is exactly > 0 bytes in length. Would you like me to send a copy? It's a bummer that ktrace is like that on FreeBSD. It doesn't show the *current* system call that the process is sitting on. Conversely, truss on Solaris does this nicely... You can conclude though that qmail-remote wasn't sitting on the select() as that has a timeout and should show the system calls associated with the reading loop. If it's not sitting on the select() what is it sitting on? If it's the read() well, how could that be if select() said the read would not block? Regards.
Re: how to use qmail-queue
On Sat, Jun 09, 2001 at 11:29:41AM -0700, newbieportal wrote: > 1. instead of using mail program /usr/sbin/sendmail > I wanted to use /var/qmail/bin/qmail-qmtpd to send mail and it did not work. Huh? qmail-qmtpd is a daemon that listens for _INCOMING_ qmtp transport. You want qmail-inject. If youy don't want them queued you want qmail-remote. -- * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * * Roedingsmarkt 14, 20459 Hamburg, Germany * Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: qmail-remote (cry wolf?)
On Fri, Jun 08, 2001 at 08:11:21PM -0400, Yevgeniy Miretskiy allegedly wrote: > On Fri, Jun 08, 2001 at 09:47:16PM +, Mark wrote: > > Then it's an OS bug. > > > > qmail-remote only gets to the read() if the OS (via select() ) says > > that the read will not block. Ergo, the OS is lying. > > If it's OS bug, anybody heard/knows of such severe network related > bug in RedHat 6.2? > > What about FreeBSD 4.2 (I believe somebody reported problem with > FreeBSD as well)??? > > What are the chances of _such_ bug in _both_ OSes? > I'd like to mention, that I ran qmail of FreeBSD (starting from 3.x all > the way to latest) for couple years and _never_ observed this behaviour > on FreeBSD. I ran it on Solaris 2.5/2.6 for years and did experience this sort of behaviour. It went away on 2.8. So what? No one has shown that qmail-remote is doing anything wrong. If it's not doing anything wrong, them maybe the problem is somewhere else? Conversely, every reading of the code in question suggests that qmail-remote is doing everything right. The fact that this problem occurs on at least two OSes simply suggests to me that the TCP/IP interaction is a boundary condition perhaps triggered by distance connections and perhaps also by an uncommon remote TCP/IP stack. Regardless of which, if an OS renegs on the "fd-will-not-block" promise, then it can *only* be an OS bug. Regards.
Re: qmail-remote (cry wolf?)
> > Is it possible that some external devices s.a. > > switch/router/firewall/anything could be causing this problem? > > Yes, very possble. Some firewalls do "transparent" SMTP or POP proxying, and > there have been many bugs in such implementations. No. Regardless of what the other end does, a conforming OS should not wedge qmail-remote forever. Why do people keep suggesting this? You have three choices: 1. Show the bug in the code containing the select() and read() 2. Show an interpretation error regarding the semantics of read() and select() If you can do either of those, we can conclude that qmail-remote is coded incorrectly and needs fixing. If you can do neither of these, then this leaves you with the inescapable conclusion that qmail-remote *is* playing by the rules, in which case you are left with the only alternative: 3. the other side of the C code is not playing by the rules: ie a bug in the compiler, libraries or OS. I will note that no one has done 1 or 2 yet, so that leaves 3. Regards.
Re: how to use qmail-queue
newbieportal <[EMAIL PROTECTED]> wrote: > > I'm still trying to utilize qmail with my web based mailing list. > my ideas. > > 1. instead of using mail program /usr/sbin/sendmail > I wanted to use /var/qmail/bin/qmail-qmtpd to send mail and it did not work. Why? qmail-qmtpd is a daemon that accepts mail over the network, much like qmail-smtpd. However, QMTP, as a protocol, is harder to speak than SMTP (as Dan says, it was designed for speed, not simplicity). Using QMTP buys you nothing over speaking SMTP, or, for that matter, using qmail's sendmail wrapper, qmail-inject, or qmail-queue. "What problem are you trying to solve?" In other words, what is it about qmail's sendmail wrapper that prevents you from using it? > 2. Okay how about this, instead of sending these mails directly, I want to > queue them first and send later. say I have 1000 emails in my mysql > database, when I try to loop through the emails and trying to send the mails > at the same time takes too long. I can't have everyone wait long time since > the mailing stops when someone closes out the browser. so is there a way to > just queue them and have it send on the back groud. If it's the same message going to 1000 recipients (as opposed to 1000 different messages going to one recipient each), you're doing it incorrectly and inefficiently. Just feed the message to qmail-inject (or the sendmail wrapper) with all recipients in one message. Open a pipe to qmail-inject and send the message: From: Subject: List message To: recipient list not shown: ; bcc: bcc: ... bcc: Hi! This is a list message. And that will do it quickly and efficiently. > does anyone know how to do this. Is there more documentation on > qmail-queue. You can, of course, use qmail-queue directly (the man page for qmail-queue is sufficient for using it; I've done it) but it doesn't buy you much in this case. > recap: instead directly trying to send mails, I would like to queue them > initially and have qmail send mails in the back ground so no one has to wait > to finish sending mails but just wait to finish queue them. qmail always does this. There is no non-queued delivery mode in qmail. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
how to use qmail-queue
Hi everyone I'm still trying to utilize qmail with my web based mailing list. my ideas. 1. instead of using mail program /usr/sbin/sendmail I wanted to use /var/qmail/bin/qmail-qmtpd to send mail and it did not work. 2. Okay how about this, instead of sending these mails directly, I want to queue them first and send later. say I have 1000 emails in my mysql database, when I try to loop through the emails and trying to send the mails at the same time takes too long. I can't have everyone wait long time since the mailing stops when someone closes out the browser. so is there a way to just queue them and have it send on the back groud. does anyone know how to do this. Is there more documentation on qmail-queue. recap: instead directly trying to send mails, I would like to queue them initially and have qmail send mails in the back ground so no one has to wait to finish sending mails but just wait to finish queue them. thanks in advance --Sudong
Re: url of sqwebmail too long!!!!
At 14:24 08/06/01, Alex Le Fevre wrote: >>I hope I understand what your asking. > >Actually, I think what he's trying to do is the same thing I've been >trying to do -- make mail.domain.com equivalent to >www.domain.com/cgi-bin/sqwebmail. In that case, an alias wouldn't >work, because that would require www.domain.com/alias/, not >mail.domain.com. Of course, it's probably a question more for an >Apache list, but if you or someone else knows how to do that, it would >make both of us quite happy. :-) >Alex Le Fevre I'm not sure if this will help or not, but here's what I do: I've installed both qmailadmin and sqwebmail in /www/webmail/cgi-bin In /etc/tinydns/data/root, for each of my subhosted domains, I add a line like the following: +webmail.justalafusta.com:216.216.32.170 In /usr/local/apache/conf/httpd.conf: DocumentRoot /www/justalaf ScriptAlias /cgi-bin/ /www/justalaf/cgi-bin/ ServerAdmin [EMAIL PROTECTED] ServerName justalafusta.com ServerAlias www.justalafusta.com User justalaf Group justalaf RLimitCPU 30 30 RLimitMEM 2500 2500 RLimitNPROC 10 10 TransferLog /home/justalaf/logs/access.log DocumentRoot /www/webmail ScriptAlias /cgi-bin/ /www/webmail/cgi-bin/ ServerAdmin [EMAIL PROTECTED] ServerName webmail.justalafusta.com SetEnv SQWEBMAIL_TEMPLATEDIR /usr/local/share/sqwebmail/justalaf SetEnv QMAILADMIN_TEMPLATEDIR /usr/local/share/qmailadmin/justalaf RLimitCPU 30 30 RLimitMEM 2500 2500 RLimitNPROC 20 20 TransferLog /home/justalaf/logs/access.log Then I have links to both sqwebmail and qmailadmin on the page at /www/webmail/index.html Qmail Admin Sqwebmail HTH -- All the best (Adéu-siau), Lou Hevly [EMAIL PROTECTED] http://www.visca.com
Re: qmail-remote (cry wolf?)
I think we may have red-herringed on the OS thing -- if RH6.2, as deployed, had this sort of problem, I think we would have run across it before this, no? The inclusion of a FreeBSD-4.2-STABLE in the mix seems to nix a RH specific bug as well (althought it obviously does not rule it out entirely*). Perhaps we're overlooking some other, more subtle commonality between these four setups? Could at least two of the OP's please detail (for me, if not for the list, at least) the devices that sit between the NIC of the host in question and the Big Bad Internet? Routers, hubs, transparent firewalls, everything? *I highly recommend that the FreeBSD-4.2-STABLE user at least upgrade to 4.3R -- I'm not sure at which point in 4.2-STABLE you froze your local tree, but a whole bunch of fixes made it into 4.3, and it's been running great for me. -- Greg White
Re: qmail-remote (cry wolf?)
On Sat, Jun 09, 2001 at 06:32:55AM -0400, Troy Settle wrote: > Yes, I've had qmail-remote processes sit there for weeks. I think that > instead of killing them off wholesale, I'll pick one or two processes and > see just how long they'll hang around. I'll post weekly updates if there's > any interest. Here is what I have on one of mail servers (ps -waux|grep qmail-remote, real email addresses removed, domain names are left. I only left user, pids, state, date, and prog name on the output for readability purposes): qmailr 7365 S May19 qmail-remote iname.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 14602 S May19 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 25415 S May19 qmail-remote careful.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 25875 S May19 qmail-remote programmer.net [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 25902 S May19 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 852S May19 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 20283 S May25 qmail-remote ziplip.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 29814 S May18 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 25877 S May19 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 25145 S May19 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 27208 S Jun08 qmail-remote hp.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 27070 S Jun08 qmail-remote mail.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 11525 S Jun08 qmail-remote best-service.com [EMAIL PROTECTED] [EMAIL PROTECTED] qmailr 13766 S Jun08 qmail-remote mad.scientist.com [EMAIL PROTECTED] [EMAIL PROTECTED] As you can see, processes running since May 19th cannot possibly be explained by slow deliver -- 20 days is just too much. The following domains go through outblaze.com mail servers: iname.com mail.com careful.com programmer.net best-service.com mad.scientist.com The following domains do not go through outblaze: ziplip.com hp.com Unforunatelly, I cannot explain this situation by blaming everything on outblaze. -- Eugene Miretskiy <[EMAIL PROTECTED]> InVision.com, INC. (631) 543-1000 www.invision.net / www.longisland.com
Re: error qmail
budsz <[EMAIL PROTECTED]> wrote: > Hi... > > When i compiled qmail in FreeBSD 4.2 ,i got some message "multilog: > fatal: unable to lock directory /var/log/qmail: temporary failure" > > what is that mean? and how i can resolve that. See the documentation for daemontools (of which multilog is a part). > BTW where i can find URL/e-books for install qmail in FreeBSD. See lifewithqmail.org -- it's an installation good for novices and experienced administrators alike that works under most Unices, including the BSDs. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. ---
RE: New Broadcast Message!!!
Adrian: Thanks. I will pass this info along to the technical personal to try it. Kirti -Original Message- From: Adrian Ho [mailto:[EMAIL PROTECTED]] Sent: Friday, June 08, 2001 6:47 PM To: [EMAIL PROTECTED] Subject: RE: New Broadcast Message!!! On Fri, 8 Jun 2001, Kirti S. Bajwa wrote : > >> Rolf vd Breemer : Wrote.. > > If you're using Maildir's, you could just do "mail * blablabla" in /home. > > > Rolf: > > Call me stupid, but I have no idea what you are recommending. I am a newbie > in qmail. Can you be little more specific? Yes, I I am using Maildir. It's nothing to do with qmail, and everything to do with letting your shell do the "hard" work. Rolf's assuming that all the users in question have their home directories rooted in /home (ie. /home/bob, /home/alice, /home/greg, etc.). If that's the case, then Rolf's saying the following will work: $ cd /home $ mail -s "Shutdown Announcement" * <
Re: How can a user put comments into rcpt to address
K. F. Yim - Netvigator writes: > Just right after the to address [EMAIL PROTECTED](comments). In what file? On what command line? -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | 521 Pleasant Valley Rd. | +1 315 268 1925 voice | John Hartford, RIP Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
error qmail
Hi... When i compiled qmail in FreeBSD 4.2 ,i got some message "multilog: fatal: unable to lock directory /var/log/qmail: temporary failure" what is that mean? and how i can resolve that. BTW where i can find URL/e-books for install qmail in FreeBSD. TIA budsz
RE: Qmailadmin
How about running ~vpopmail/bin/vpasswd? ~vpopmail/bin/vpasswd [EMAIL PROTECTED] newpass You do not want to edit ~vpopmail/domains/default.com/vpasswd file directly. -- Troy Settle Pulaski Networks 540.994.4254 ** -Original Message- ** From: Bill Parker [mailto:[EMAIL PROTECTED]] ** Sent: Friday, June 08, 2001 4:38 PM ** To: [EMAIL PROTECTED] ** Subject: Qmailadmin ** ** ** Hi All, ** ** Through a fault of no one, it appears the password for ** postmaster for my default domain was changed, and no one can ** remember it. How can I change it manually, as I have root ** access to the machine in question, and I am the administrator. ** ** I see a file called vpasswd in the domain in question, can I ** hack the file and remove the encrypted stuff for postmaster? ** ** -Bill ** **
RE: qmail-remote (cry wolf?)
** -Original Message- ** From: Mark [mailto:[EMAIL PROTECTED]] ** Sent: Friday, June 08, 2001 11:14 AM ** To: [EMAIL PROTECTED] ** Subject: Re: qmail-remote (cry wolf?) ** ** ** > processed those 1500 messages in less than 30 minutes. ** However, it left ** > behind another handfull of stuck qmail-remote processes. ** Other messages ** > were undeliverable and left in the queue, and still others ** were sent back to ** > sender with permanent errors. ** ** What do you mean by "stuck"? Do you mean they *never* go away - even ** after a day or two? As others have pointed out, a slow delivery can ** take a long, long time. That's not necessarily a problem, that's just ** the way it is. Yes, I've had qmail-remote processes sit there for weeks. I think that instead of killing them off wholesale, I'll pick one or two processes and see just how long they'll hang around. I'll post weekly updates if there's any interest. I keep hearing that it might be a very slow delivery. How is this possible when there isn't any network connection open to the remote host in question, let alone a connection to it's smtp port. As far as I can tell, this is a problem between qmail-remote and the kernel. This is happening on multiple operating systems, so that leads me to believe that this is not an OS bug. ** ** To find out a bit more about what a "stuck" qmail-remote is doing, you ** may want to ktrace it and show us the output. Find the process id of the ** stuck qmail-remote and then as root go: ktrace -p thepid ** ** Leave that running for at least an hour and show us the output. Yes, I ** mean at least an hour. ** Ok, I meant to come back in an hour and stop the trace, but after running ktrace for 9 hours (while I slept), the resulting ktrace.out file is exactly 0 bytes in length. Would you like me to send a copy? I did verify the behavior of ktrace, and a ktrace on qmail-send generated tons of data within seconds. ktrace is working. Anything else y'all would like me to lok at? -- Troy Settle Pulaski Networks 540.994.4254
Re: ms-outlook bug
Hi, > I have this about 3 times a month on this account which subscribes to a lot of > mailing lists, but only when Norton Antivirus is scanning incoming pop mail. I > guess I could disbale it and then to try to duplicate it. Is the original > poster using Norton to scan his incoming mail? I can confirm problems with OE 5 (latest and pre-latest Version). This appears on two specific Senders, is not related to a specific PC and on these PC's aren't any Virusscanners. First I thought it might be related to a language set (belgium or francophone). But after this discussion I have to start from scratch Tom
Re: Im not sure if this is normal?
On Fri, 8 Jun 2001, Mike Jimenez wrote: > Is my mail que stuck or is this normal.Is there also a way to manage the > que? > /var/qmail/bin/qmail-qstat > messages in queue: 243 > messages in queue but not yet preprocessed: 0 Is qmail running? Have you tried sending SIG_ALRM? Have you tried restarting qmail? -- Todd A. Jacobs CodeGnome Consulting, LTD
