Re: [qmailtoaster] error 571-'sorry, sender address has invalid format (#5.7.1 - chkuser)'
Jim Shupert, Jr. wrote: Friends, I have a blckberry user who has the complaint of 5.1.0 - Unknown address error 571-'sorry, sender address has invalid format (#5.7.1 - chkuser)' I find this in the wiki - ok , that sounds dead on 1.Is it generally agreed that disabling the check for all incoming mail is a good solution? best solution? 2. are there any - risks downsides? 3. ( most importantly )if I wish to disabled the check for all incoming mail :allow,BADMIMETYPE=,SENDER_NOCHECK=1,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan exactly how do I do that? 4. do i have the option of editing my tcp.smtp and would I be correct in thing that it is as easy as N.N.N.N:allow,RELAYCLIENT=,RBLSMTPD=,SENDER_NOCHECK=1 where N.N.N.N is the blackberry mail server? maybe 4 is my best solution... I so far- only have 1 complaint. I wrote that wiki page, and then edited it later as a FYI. I went through all the trouble of turning off the checks for all of Blackberry's MX entries and unfortunately Blackberry has a couple ghost mail servers that are not listed in DNS. I had a screaming client during the process, so I would fix it and the next day he would get the above message. I'd find the ghost MX server and add it telling him it was fixed, and it happened again the next day with a new ghost machine. After a couple of what looked like foot in mouth moments with my client I threw my hands up and turn off sender checking for the whole machine. Those symbols are technically allowed by the RFC, and I could not really see how they could be used to exploit the system since they're not really translating to filenames or anything, so I do not see any reason to deny them. I have been allowing them for a couple months now and have had no adverse effects from it. My 2 cents. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
Roxanne Sandesara wrote: Jake, how do I individually stop qmailtoaster services? Will qmailctl accept a second argument with the name of a service? Or do I need to 'kill' the processes? Is there a way to start up only selected services? You can stop individual processes with the svc -d command: svc -d /var/qmail/supervise/spamd /var/qmail/supervise/spamd/log That stops the spamd and spamd-log daemons as an example. Look in /var/qmail/supervise for the names of the other daemons. Once you stop a service, you can check to make sure it's stopped by 'qmailctl stat' or: svstat /var/qmail/supervise/spamd smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
Thank you. I've run the script to repair the queue, and started up just send. I'm going to leave it to run for an hour or so, to see if it can manage to make the deliveries it needs to make. If not, I'll shut down send, check to see if the queue is corrupted again. If it is, I'll have to drop back and start with bringing the server down completely to scan the disks for corruption. I'm nowhere near to being out of space on the system: [EMAIL PROTECTED] ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 86761840 41277944 41076600 51% / /dev/sda1 101086 60813 35054 64% /boot none 1037384 0 1037384 0% /dev/shm I've got a backup of everything each week for the last two months, and I'll run another before I shut it down for disk scanning, just in case it can prove useful. Sadly, this may be the event that forces me to upgrade to CentOS 5, when rebuilding if that becomes necessary. Thank you for the help, to Jake and to everyone else who tried. I'll keep everyone informed. On Oct 6, 2007, at 9:28 AM, Jake Vickers wrote: Roxanne Sandesara wrote: Jake, how do I individually stop qmailtoaster services? Will qmailctl accept a second argument with the name of a service? Or do I need to 'kill' the processes? Is there a way to start up only selected services? You can stop individual processes with the svc -d command: svc -d /var/qmail/supervise/spamd /var/qmail/supervise/spamd/log That stops the spamd and spamd-log daemons as an example. Look in / var/qmail/supervise for the names of the other daemons. Once you stop a service, you can check to make sure it's stopped by 'qmailctl stat' or: svstat /var/qmail/supervise/spamd - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
OK. Send is still not delivering, clearing up the queue at all. However, the queue is not re-corrupting itself. I'm not really sure / what/ to try next. Any suggestions? Should I just leave send running by itself for a while longer? (I tried forcing the issue with qmHandle -a to no avail). On Oct 6, 2007, at 10:02 AM, Roxanne Sandesara wrote: Thank you. I've run the script to repair the queue, and started up just send. I'm going to leave it to run for an hour or so, to see if it can manage to make the deliveries it needs to make. If not, I'll shut down send, check to see if the queue is corrupted again. If it is, I'll have to drop back and start with bringing the server down completely to scan the disks for corruption. I'm nowhere near to being out of space on the system: [EMAIL PROTECTED] ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 86761840 41277944 41076600 51% / /dev/sda1 101086 60813 35054 64% /boot none 1037384 0 1037384 0% /dev/shm I've got a backup of everything each week for the last two months, and I'll run another before I shut it down for disk scanning, just in case it can prove useful. Sadly, this may be the event that forces me to upgrade to CentOS 5, when rebuilding if that becomes necessary. Thank you for the help, to Jake and to everyone else who tried. I'll keep everyone informed. On Oct 6, 2007, at 9:28 AM, Jake Vickers wrote: Roxanne Sandesara wrote: Jake, how do I individually stop qmailtoaster services? Will qmailctl accept a second argument with the name of a service? Or do I need to 'kill' the processes? Is there a way to start up only selected services? You can stop individual processes with the svc -d command: svc -d /var/qmail/supervise/spamd /var/qmail/supervise/spamd/log That stops the spamd and spamd-log daemons as an example. Look in / var/qmail/supervise for the names of the other daemons. Once you stop a service, you can check to make sure it's stopped by 'qmailctl stat' or: svstat /var/qmail/supervise/spamd - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
Roxanne Sandesara wrote: OK. Send is still not delivering, clearing up the queue at all. However, the queue is not re-corrupting itself. I'm not really sure /what/ to try next. Any suggestions? Should I just leave send running by itself for a while longer? (I tried forcing the issue with qmHandle -a to no avail). Try the queue-repair tool as well - maybe a permission went awry. http://pyropus.ca/software/queue-repair/ smime.p7s Description: S/MIME Cryptographic Signature
RE: [qmailtoaster] Queued into surrender
50% free on the disk is good - But, how about the partition holding the queue? Do any of the partitions themselves show full? Thank You Kevin Katz -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 6:00 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Queued into surrender I've got nearly 50% free space on the disk. On Oct 5, 2007, at 8:11 PM, Todd W wrote: From: Roxanne Sandesara [EMAIL PROTECTED] /var/qmail/control/concurrencyremote = 60 Any idea what 'unable to open todo' means? Or what I should do about it? /var/log/qmail/send current: Script started on Fri 05 Oct 2007 04:52:25 PM EDT ]0;[EMAIL PROTECTED]:~ [EMAIL PROTECTED] ~]# qmlog send 10-05 16:52:15 warning: unable to open todo/3490361 The only thing google found was http://securepoint.com/lists/html/ Qmail/2007-04/msg00091.html A single reply to the op asked if the disk was full. There is no reply. I imagine you saw it, too... but just out of curiosity is your disk full? $ sudo df -h Regards, Todd W. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
OK. I had queue-repair create a whole new queue, in case it was something niggling. However, in test mode it hadn't found anything wrong. Having built a new queue, I have restarted qmail-send, and only send, to see if it will process through the queue. I assume I should let it sit for an hour or so, and then pull the latest messages out of qmlog send if it hasn't cleared the queue? Is there anywhere else I should be looking to find additional messages or information that would help troubleshoot this? On Oct 6, 2007, at 11:10 AM, Jake Vickers wrote: Roxanne Sandesara wrote: OK. Send is still not delivering, clearing up the queue at all. However, the queue is not re-corrupting itself. I'm not really sure /what/ to try next. Any suggestions? Should I just leave send running by itself for a while longer? (I tried forcing the issue with qmHandle -a to no avail). Try the queue-repair tool as well - maybe a permission went awry. http://pyropus.ca/software/queue-repair/ - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
Roxanne Sandesara wrote: OK. I had queue-repair create a whole new queue, in case it was something niggling. However, in test mode it hadn't found anything wrong. Having built a new queue, I have restarted qmail-send, and only send, to see if it will process through the queue. I assume I should let it sit for an hour or so, and then pull the latest messages out of qmlog send if it hasn't cleared the queue? Is there anywhere else I should be looking to find additional messages or information that would help troubleshoot this? You may also try running recordio on it to see if it gives any more information while it's bombing out. The options I'd given you already had fixed my problem in the past, so this is a new one for me as well. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
OK. I tried 'recordio svc -u /var/qmail/supervise/send', but that clearly doesn't work, as that is just a service script. All I get is an EOF and a hanging process. What program(s) should I call with recordio to try to get some meaningful information? Obviously, I'd prefer to fix this, as it would also add to our knowledge base regarding what is happening and perhaps then what caused the situation. But are we reaching the point that I should just consider running that backup, wiping the box and rebuilding? Admittedly, it would take me the rest of today to do that. But I do need to figure this out and fix it. On Oct 6, 2007, at 3:35 PM, Jake Vickers wrote: Roxanne Sandesara wrote: OK. I had queue-repair create a whole new queue, in case it was something niggling. However, in test mode it hadn't found anything wrong. Having built a new queue, I have restarted qmail-send, and only send, to see if it will process through the queue. I assume I should let it sit for an hour or so, and then pull the latest messages out of qmlog send if it hasn't cleared the queue? Is there anywhere else I should be looking to find additional messages or information that would help troubleshoot this? You may also try running recordio on it to see if it gives any more information while it's bombing out. The options I'd given you already had fixed my problem in the past, so this is a new one for me as well. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
Roxanne Sandesara wrote: OK. I tried 'recordio svc -u /var/qmail/supervise/send', but that clearly doesn't work, as that is just a service script. All I get is an EOF and a hanging process. What program(s) should I call with recordio to try to get some meaningful information? Obviously, I'd prefer to fix this, as it would also add to our knowledge base regarding what is happening and perhaps then what caused the situation. But are we reaching the point that I should just consider running that backup, wiping the box and rebuilding? Admittedly, it would take me the rest of today to do that. But I do need to figure this out and fix it. You'll need to put the recordio command in the supervise file (called run) for qmail-send. Then it should just add extra output to the logs (massive amounts, depending on the load). As far as reaching the point of wiping and starting over, that's a call you have to make. I don't know what all is run off your machine so I can't make a guess as to how critical it is. My machines would take me hours each to backup since I usually run something else on the machine as well - I'd move the backup to another server and change the MX record while I got the main one working in my situations. That may not work for you. I'd also like to point out I do have the QMT-ISO (qmtiso.com) that will give you a Cent 4.5 and Toaster install in one fell swoop (okay, 3 reboots total). I'm not a fan of Cent5 myself - it's rather bloated for my tastes. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
Roxanne Sandesara wrote: OK. I put recordio at the start of the command line within the run file within /var/qmail/supervise/send and started up just the send service. What follows is the log /var/log/qmail/send/current: [EMAIL PROTECTED] ~]# cat /var/log/qmail/send/current @40004707b77f074e75e4 status: local 5/10 remote 0/60 @40004707b77f07d19c1c delivery 7976: deferral: maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/home/vpopmail/domains/primary_domain_name/blackhole// Man - that was a big email. It looks like it's making deliveries at first, but gets overloaded after a while. I'd suggest increasing your local concurrency (/var/qmail/control/localconcurrency) to 30 or 50 (default is 10). I'm also worried by this maildrop error - last time I saw that it was because someone's maildrop.log was 2G. Check that as well. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
Yeah. It was huge. Sorry about that. But I really wasn't sure what to keep and what to clip. :( My /var/log/maildrop/maildrop.log was ... gigantinormous. I don't feel like doing byte math, but I'm pretty sure it was at least close to 2gb. So, I moved that to .log.old-date and created a new file of the same original name, same group, user and permissions, in the original location. On the off chance that was at all contributing. Now. It's possible I've done something stupid. That's always possible. But there was no localconcurrency file in /var/qmail/ control in my installation. I created one, just in case, and put 30 in it. I did have a concurrencyremote file. So I also created a concurrencylocal, in case that was a misnomer. I've restarted just the /send service, waiting to see if it will process now. I've also started DLing a copy of the ISO for QMT-ISO. If this doesn't work, I'm going to go ahead and wipe and rebuild. I really do need to get this mailserver back up and running. I'll let you all know what happens. And thanks again, Jake, for all of your help, regardless of how this turns out. I appreciate it. On Oct 6, 2007, at 8:37 PM, Jake Vickers wrote: Roxanne Sandesara wrote: OK. I put recordio at the start of the command line within the run file within /var/qmail/supervise/send and started up just the send service. What follows is the log /var/log/qmail/send/current: [EMAIL PROTECTED] ~]# cat /var/log/qmail/send/current @40004707b77f074e75e4 status: local 5/10 remote 0/60 @40004707b77f07d19c1c delivery 7976: deferral: maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/ home/vpopmail/domains/primary_domain_name/blackhole// Man - that was a big email. It looks like it's making deliveries at first, but gets overloaded after a while. I'd suggest increasing your local concurrency (/var/ qmail/control/localconcurrency) to 30 or 50 (default is 10). I'm also worried by this maildrop error - last time I saw that it was because someone's maildrop.log was 2G. Check that as well. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
Well, I believe we have some good news. Thank you again for your help, Jake. With the latest changes (detailed below), the restart of /send wasn't throwing the errors it was before. So I removed the recordio from the run file for send, ran Jake's qfixq script again (it found several errors in the queue, quite possibly caused while all those other errors were being thrown), and restarted qmailtoaster - the whole suite. The queue is down to half its size and dropping. It appears to have been - I'm guessing, but it seems accurate - the oversized maildrop.log. I'll need to edit the logrotate.conf files so that it rotates. If I might make a suggestion? Since we use maildrop in toaster, perhaps we should make sure one of our appropriate SRPMs sets up rotation for maildrop.log ? Anyway. Thank you very, very much, Jake, for all of your help. And everyone else. This is a huge weight of stress off my shoulders. Roxanne On Oct 6, 2007, at 9:07 PM, Roxanne Sandesara wrote: Yeah. It was huge. Sorry about that. But I really wasn't sure what to keep and what to clip. :( My /var/log/maildrop/maildrop.log was ... gigantinormous. I don't feel like doing byte math, but I'm pretty sure it was at least close to 2gb. So, I moved that to .log.old-date and created a new file of the same original name, same group, user and permissions, in the original location. On the off chance that was at all contributing. Now. It's possible I've done something stupid. That's always possible. But there was no localconcurrency file in /var/qmail/ control in my installation. I created one, just in case, and put 30 in it. I did have a concurrencyremote file. So I also created a concurrencylocal, in case that was a misnomer. I've restarted just the /send service, waiting to see if it will process now. I've also started DLing a copy of the ISO for QMT-ISO. If this doesn't work, I'm going to go ahead and wipe and rebuild. I really do need to get this mailserver back up and running. I'll let you all know what happens. And thanks again, Jake, for all of your help, regardless of how this turns out. I appreciate it. On Oct 6, 2007, at 8:37 PM, Jake Vickers wrote: Roxanne Sandesara wrote: OK. I put recordio at the start of the command line within the run file within /var/qmail/supervise/send and started up just the send service. What follows is the log /var/log/qmail/send/current: [EMAIL PROTECTED] ~]# cat /var/log/qmail/send/current @40004707b77f074e75e4 status: local 5/10 remote 0/60 @40004707b77f07d19c1c delivery 7976: deferral: maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/ home/vpopmail/domains/primary_domain_name/blackhole// Man - that was a big email. It looks like it's making deliveries at first, but gets overloaded after a while. I'd suggest increasing your local concurrency (/var/ qmail/control/localconcurrency) to 30 or 50 (default is 10). I'm also worried by this maildrop error - last time I saw that it was because someone's maildrop.log was 2G. Check that as well. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
