Re: [qmailtoaster] RE: Policy Problem
2009/7/14 Robin W. Sanchez C. robin-sanc...@aimargroup.com: Why show this in mail server policy_check: local karla_solorz...@mail.com - local noel_tin...@mail.com (UNAUTHENTICATED SENDER) @40004a5b8b0714cb99cc policy_parse: syntax error: no domain policy seperator @40004a5b8b0714cbdc34 policy_load(aimargroup.com): policy_parse failed (line 1) @40004a5b8b0714cc1ab4 policy_check: policy_load failed http://www2.inter7.com/?page=empf is configured on the server if your are not using policy remove /var/qmail/control/policy -- Regards Dhaval Thakar http://www.linuxreaders.com/ - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] how to control infected users
Dear All One of my user machine was infected by a virus and it start sending lots of spam mails. As the user was using smtp-auth my server accepted the mail. Because of this my server IP is blacklisted, after diagnosing i have blocked the infected machine IP through iptable and scanned for virus. Now the problem is solved, but i wanted to know how to control this behaviour. With Regards Vinay Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/
Re: [qmailtoaster] how to control infected users
Karpaha Vinayaham wrote: Dear All One of my user machine was infected by a virus and it start sending lots of spam mails. As the user was using smtp-auth my server accepted the mail. Because of this my server IP is blacklisted, after diagnosing i have blocked the infected machine IP through iptable and scanned for virus. Now the problem is solved, but i wanted to know how to control this behaviour. With Regards Vinay Love Cricket? Check out live scores, photos, video highlights and more. Click here http://in.rd.yahoo.com/tagline_cricket_2/*http://cricket.yahoo.com. I don't know any trojan that can use auth sistem to send emails, classical way is to send mails using it's own server, so blocking destination port 25 for the inside clients should solve the problem, but if there is an aplication that sends mails using auth sistem then we are all doomed :D Regards Lucian - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] RE: Policy Problem
Robin, if you are not using empf, you do not necessarily have to remove the policy file from /var/qmail/control. QMT will run just fine with an empty policy file. If you are using empf, and have a policy set up in the policy file, make sure the very last character is a comma (I know, I made this mistake). Also locate the README.empf file on your server. It has all the info needed to correctly setup a policy. I have used it for 1 year and it works beautifully. Dave dhaval thakar wrote: 2009/7/14 Robin W. Sanchez C. robin-sanc...@aimargroup.com: Why show this in mail server policy_check: local karla_solorz...@mail.com - local noel_tin...@mail.com (UNAUTHENTICATED SENDER) @40004a5b8b0714cb99cc policy_parse: syntax error: no domain policy seperator @40004a5b8b0714cbdc34 policy_load(aimargroup.com): policy_parse failed (line 1) @40004a5b8b0714cc1ab4 policy_check: policy_load failed http://www2.inter7.com/?page=empf is configured on the server if your are not using policy remove /var/qmail/control/policy - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Missing HELO identifier
Tim Pleiman wrote: On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! You're all over the solution. The only ones that are messed up are the ones from squirrelmail, so don't you think it's likely that squirrelmail is where the solution lies? ;) I don't have your solution, but I can point you in the right direction. I just ran a test, and on my system it appears that the (HELO mail.shubes.net) is indeed coming from squirrelmail somehow. The only place I have mail.shubes.net specified is in the url I used for accessing squirrelmail. So I tried accessing squirrelmail with test.shubes.net, and indeed I get (HELO test.shubes.net). Now I admit that I've tweaked my config_local.php file from the stock values, mainly because I'm running dovecot in place of courier. I didn't see anything there that I thought would effect this behavior though. So do some digging into SM, and I think you'll find the solution. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today!
[qmailtoaster] sql ERROR
Any one seen this error before One user is geting this message Using Firefox on a MAC OS 10.5 Thanks - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] sql ERROR
Tricube wrote: Any one seen this error before One user is geting this message Using Firefox on a MAC OS 10.5 Thanks When doing what? -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] sql ERROR
Just clicking get mail When the client shuts down thunderbird,then reopens, it gets mail by default, but if the client clicks manually, this is when they get the error. Not ever sure it is a qmail problem, ? Eric Shubert wrote: Tricube wrote: Any one seen this error before One user is geting this message Using Firefox on a MAC OS 10.5 Thanks When doing what? - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] sql ERROR
Sorry , I am loosing my marbles, here is the eror message.. when they click get mail l:sql error 3 Table Pop3 users does not exist - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] sql ERROR
Tricube wrote: Sorry , I am loosing my marbles, here is the eror message.. when they click get mail l:sql error 3 Table Pop3 users does not exist If other users are able to pop, then I'd say their client configuration (tbird or mail) isn't correct. If nobody can pop, then it's possibly a server issue. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] sql ERROR
Checking client settings, I will also test using imap, will let you know. Eric Shubert wrote: Tricube wrote: Sorry , I am loosing my marbles, here is the eror message.. when they click get mail l:sql error 3 Table Pop3 users does not exist If other users are able to pop, then I'd say their client configuration (tbird or mail) isn't correct. If nobody can pop, then it's possibly a server issue. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Missing HELO identifier--Resolved
On Tue, July 14, 2009 11:07 am, Eric Shubert wrote: Tim Pleiman wrote: On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! You're all over the solution. The only ones that are messed up are the ones from squirrelmail, so don't you think it's likely that squirrelmail is where the solution lies? ;) I don't have your solution, but I can point you in the right direction. I just ran a test, and on my system it appears that the (HELO mail.shubes.net) is indeed coming from squirrelmail somehow. The only place I have mail.shubes.net specified is in the url I used for accessing squirrelmail. So I tried accessing squirrelmail with test.shubes.net, and indeed I get (HELO test.shubes.net). Now I admit that I've tweaked my config_local.php file from the stock values, mainly because I'm running dovecot in place of courier. I didn't see anything there that I thought would effect this behavior though. So do some digging into SM, and I think you'll find the solution. -- -Eric 'shubes' Eric, Indeed, that's exactly what's going on here. It seems that particular HELO is being picked up from the actual URL domain that you use for login. So, if you login via IP address, that's what you get in the HELO.
Re: [qmailtoaster] sql ERROR
Keep in mind that while imap and pop3 both have to do with retrieving mail to a client, they are both *entirely* different bits of software. There's very little that they share. One might work flawlessly while the other could be horribly broken. Tricube wrote: Checking client settings, I will also test using imap, will let you know. Eric Shubert wrote: Tricube wrote: Sorry , I am loosing my marbles, here is the eror message.. when they click get mail l:sql error 3 Table Pop3 users does not exist If other users are able to pop, then I'd say their client configuration (tbird or mail) isn't correct. If nobody can pop, then it's possibly a server issue. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Missing HELO identifier--Resolved
Tim Pleiman wrote: On Tue, July 14, 2009 11:07 am, Eric Shubert wrote: Tim Pleiman wrote: On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! You're all over the solution. The only ones that are messed up are the ones from squirrelmail, so don't you think it's likely that squirrelmail is where the solution lies? ;) I don't have your solution, but I can point you in the right direction. I just ran a test, and on my system it appears that the (HELO mail.shubes.net) is indeed coming from squirrelmail somehow. The only place I have mail.shubes.net specified is in the url I used for accessing squirrelmail. So I tried accessing squirrelmail with test.shubes.net, and indeed I get (HELO test.shubes.net). Now I admit that I've tweaked my config_local.php file from the stock values, mainly because I'm running dovecot in place of courier. I didn't see anything there that I thought would effect this behavior though. So do some digging into SM, and I think you'll find the solution. -- -Eric 'shubes' Eric, Indeed, that's exactly what's going on here. It seems that particular HELO is being picked up from the actual URL domain that you use for login. So, if you login via IP address, that's what you get in the HELO. Squirrelmail is passing this on, and has always done so apparently, but I
[qmailtoaster] rhost-check in conjunction with rblsmtpd?
Hi all, Is/has anyone here used rhost_check in conjunction rblsmtpd and QMT to do rDNS lookups on remote hosts for spam filtering? http://www.zentus.com/rhost-check.html I've always compiled this useful tool into my QMR installs in the past to do non-paranoid (-p) tcpserver lookups of the rDNS status of connecting hosts. I always place this lookup immediately prior to all other checks to verify that the connecting server at least HAS some sort of PTR record. It cuts off spam immediately without any other conditions first and avoids hammering the RBLs unnecessarily. It's worked fine with RH9 and EL3. Was wondering if anyone has compiled and installed it on more recent versions of EL--specifically CentOS 5.3-x64. Does the code works with more recent linux releases and x64 versions? Also, in case I'm missing something here and wasting my time, the current CHKUSER isn't doing any rDNS PTR lookups for connection verification/rejection, is it? Thanks! -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] and on Spamdyke (Missing HELO identifier--Resolved)
On Tue, July 14, 2009 5:25 pm, Eric Shubert wrote: Tim Pleiman wrote: On Tue, July 14, 2009 11:07 am, Eric Shubert wrote: Tim Pleiman wrote: On Mon, July 13, 2009 6:12 pm, Eric Shubert wrote: Aleksander Podsiadly wrote: W dniu 13.07.2009 22:16, Tim Pleiman pisze: /var/qmail/control/me contains the primary server mail domain name, e.g: mail.servername.org Tim It should be the same as result of `hostname`, just the servername. Not ,,mail.servername.org'' but FQDN servername with all dots. Not the value of CNAME, but the name from record A, the same as the name from PTR record. IMO it's the best, clear and proper configuration. My toaster has the fqdn value in there, but I can't say for sure where it comes from. I can say that it does not come from `hostname --fqdn` (although I agree with Alex that this is the value it should reflect). Oh, here it is. Looks like it comes from the /var/qmail/control/helohost file. (Duh) http://wiki.qmailtoaster.com/index.php/Helohost -- -Eric 'shubes' Yes it does. However, helohost defaults to me if not specified in the control files. And, it should pick up me as I have it specified, but it does not (I also tried specifying helohost in addition to the correct me--everything with the same name). In the case of localhost sends (as in this case from Squirrelmail), I believe it should ideally pick up the virtual domain that it is sent from in vpopmail, which would be testdomain.com at this stage. Again, it only happens in the second stage of the header during a localhost send process. All the other HELOs are correct. Upon endless adjustments, I think it may be coming from the CHKUSER patch. I did manage to get the unknown portion of the HELO changed to say localhost instead by removing the -H option from tcpserver. So now I get: from localhost (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) from unknown (HELO ?xx.xxx.xxx.xxx?) (127.0.0.1) The unknown goes away, and once this is changed, the smtp daemon logs also reflect the change, referring also to localhost instead of unknown: 2009-07-13 22:17:19.156287500 tcpserver: pid 6969 from 127.0.0.1 2009-07-13 22:17:19.156819500 tcpserver: ok 6969 mail.servername.org:127.0.0.1:25 localhost:127.0.0.1::43932 2009-07-13 22:17:19.162423500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt : sender accepted 2009-07-13 22:17:19.234600500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:localhost:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay INSTEAD OF: 2009-07-10 17:18:30.502954500 tcpserver: pid 32023 from 127.0.0.1 2009-07-10 17:18:30.503012500 tcpserver: ok 32023 mail.servername.org:127.0.0.1:25 :127.0.0.1::41168 2009-07-10 17:18:30.638742500 CHKUSER accepted sender: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt : sender accepted 2009-07-10 17:18:30.679559500 CHKUSER relaying rcpt: from postmas...@testdomain.com:: remote [xx.xxx.xxx.xxx]:unknown:127.0.0.1 rcpt tpleiman@domainname.net : client allowed to relay I believe HELOs typically should be picked up from the static configuration files in /var/qmail/control and I can't figure out for the life of me where (chkuser?) is pulling this HELO name from when it is a simple localhost send from the same box--e.g. remote and localhost are the SAME machine, and why it won't at least just pick up the helohost or me from the control files. At any rate, everything else is working fine. Incomings are are all processing great, and I don't think this is that big of a deal as server to server communications and HELOs are correct, but it would be nice to clean this up so the headers on outbound sends are correct during this internal localhost transaction process for localhost sends from SquirrelMail. Am I just missing something really stupid here? Thanks again! You're all over the solution. The only ones that are messed up are the ones from squirrelmail, so don't you think it's likely that squirrelmail is where the solution lies? ;) I don't have your solution, but I can point you in the right direction. I just ran a test, and on my system it appears that the (HELO mail.shubes.net) is indeed coming from squirrelmail somehow. The only place I have mail.shubes.net specified is in the url I used for accessing squirrelmail. So I tried accessing squirrelmail with test.shubes.net, and indeed I get (HELO test.shubes.net). Now I admit that I've tweaked my config_local.php file from the stock values, mainly because I'm running dovecot in place of courier. I didn't see anything there that I thought would effect this behavior though. So do some digging into SM, and I think you'll find the solution. -- -Eric 'shubes' Eric, Indeed, that's exactly what's going on here. It seems that particular HELO is being picked up from the actual URL domain that you
Re: [qmailtoaster] and on Spamdyke (Missing HELO identifier--Resolved)
Tim Pleiman wrote: You know, I do have qmailtoaster plus installed, and I used it to update the entire base package just a couple weeks ago (had script installed these servers for early testing in May with an earlier QMT release). I did review Spamdyke, but I guess I hadn't paid attention to the rDNS lookup option there as I sort of immediately ruled it out because of the graylisting. I don't care for graylisting myself as I hate having my queues waiting on other people's graylisting, and I know that some of my clients would go berserk if they even have to to wait 5 minutes for mail delivery. (I know that's nuts, considering the fact that default delivery times were like 7 days in Qmail not so many years ago. My first mail server was actually a UUCP mail server back in the mid-nineties, believe it or not). Anyway, I'm assuming it's possible to turn off graylisting in the spamdyke.conf file, yes? All the features listed at spamdyke.org are re-configurable/tweakable in spamdyke.conf after installation? You betcha. The latest version even lets you have different configs for different domains or users even. It's quite flexible. Thanks! Tim -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] how to control infected users
On Tue, July 14, 2009 7:21 am, Lucian Cristian wrote: Karpaha Vinayaham wrote: Dear All One of my user machine was infected by a virus and it start sending lots of spam mails. As the user was using smtp-auth my server accepted the mail. Because of this my server IP is blacklisted, after diagnosing i have blocked the infected machine IP through iptable and scanned for virus. Now the problem is solved, but i wanted to know how to control this behaviour. With Regards Vinay Love Cricket? Check out live scores, photos, video highlights and more. Click here http://in.rd.yahoo.com/tagline_cricket_2/*http://cricket.yahoo.com. I don't know any trojan that can use auth sistem to send emails, classical way is to send mails using it's own server, so blocking destination port 25 for the inside clients should solve the problem, but if there is an aplication that sends mails using auth sistem then we are all doomed :D Regards Lucian Sounds from your description here like you were routing forwarding LAN traffic through the same IP address (same server perhaps) that is hosting your mail. The spam zombie probably wasn't routing via your mail server itself, rather just your IP address interface (on the same machine or otherwise). Spam zombied machines generally send spam directly. In this case, you can either do as Lucian suggests and ban outbound port 25 to forwarding in IPTABLES, or, better yet if possible, route your LAN traffic through a different IP address/interface/server. Also, as I presume the machines on your LAN are Windows machines. Make sure to lock down your client workstations tightly in a controlled manner. If running in a Windows Workgroup, make sure users only have Restricted User (User Group) accounts on a machine by machine basis. If on a Samba domain or Active Directory Domain, also make sure all users are granted only User Group permissions on the Domain. This will help to ensure that users are are not as easily infected in the first place. Unfortunately, in some cases, users must be granted certain slightly elevated permissions on machines for certain software applications to run properly (e.g. Standard User (Power Group). Quickbooks is a notable example of such a badly-designed application. Users in the Power Group can get infected. Also, make sure you are continually educating/informing your users as to network policies/procedures. Users should not open e-mails from untrusted sources, and should never follow links in such emails, and should never follow links in casual e-mails from friends that they receive at the workplace. Use of 3rd party e-mail providers (webmail, et.al), over which you have no control should be discouraged. If a machine shows signs of infection (XP antivirus or other similar bots), users should be educated to unplug the network cable immediately from the wall and contact support. Leave the machine running, and rebooting can cause the infection to become more deeply embedded in the windows registry and/or system32 directory. Anti-virus software on individual machines is proving less and less effective in stopping infection, as the time from virus reporting to AV definition update at the AV vendors can only happen so fast. Zero-hour exploits have exploded, and often the only prevention for these are wise, well-educated users. These are headaches that can't always be prevented by the network admin. I've had two zombie infected machines within the past year, after seeing no infections of any type on my networks for around 8 years. One was a year ago this week and one 2 weeks ago. Both were on machines with elevated permissions. Both were in the same office. The first was a user who was designated as a local office admin. At that point a year ago, I eliminated all users with full admin privileges of any kind. The most recent, however, was on a user's machine with Power Group permissions. Unfortunately, that machine cannot be locked down any further, and that infection slipped by local AV filters. However, in order to get infected, the user had to have followed a malicious link or visit an infected website (probably running IIS). However, you can mitigate these things as above, and I hope this is of some help to you. I know how incredibly painful cleaning up these types of things can be. Good luck! Tim -- Tim Pleiman Bravo Systems Technologies Advanced Open Source Solutions for Business Chicago, IL USA - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates,
[qmailtoaster] Re:
Eva,
I replied this email to the list to share with any one that may have the
same problem with you
1. you missed the hash on
Location of the users file
itu should be
# Location of the users file
2. can you provide the detailed error message the came out?
Kisakye Alex wrote:
This is the exact script that is on Qmailtoaster site… can you share
with me the one you are planning on editing or the one that you have
edited… seems the file with your users is not in the correct path
Alex
*From:* Eva Eme [mailto:evaeme2...@yahoo.com]
*Sent:* Tuesday, July 14, 2009 10:40 AM
*To:* pako...@pala.bo-tak.info; ALex
*Subject:*
Hi,
I am in a difficult situation of getting my Qmail Toaster running. I
need to upload at least 1000 users and I am unable to do so with this
script (from qmailtoaster.com)
I Keep getting the error that the command Users_file is not found
(please not that it does not say that the file is not found, but
rather that the COMMAND IS NOT FOUND)
Please please help.
Thanks
Eva
#!/bin/sh
#
# BULK USER ADDING FOR QMAIL TOASTER
#
# Created after I ran into an issue of creating 20,000 users on my toaster!
# Initial ideas come from a script that PakOgah pako...@pala.bo-tak.info
# helped me with.
# Still very manual, but Work in Progress
#
# Suggestions to akisa...@ucu.ac.ug
#
# Change a few variables and you are good to go
#
#
#
Location of the users file
# Rememeber that the users file is in the format
# Firstname Lastname Username
USERS_FILE=/path/to/file.txt
# The mail domain to which users are created
#
MAILDOMAIN=@domain.com
# the vadduser command
QMAILADD=/home/vpopmail/bin/vadduser
# Select a default password for all users
PASS=mypass
#Specify the Default Quota_in_bytes for your Users
# 10 MB = 10 x 1024 x 1024
QUOTA=10485760
#Fun starts here No more variables to change below this line
cat ${USERS_FILE} | \
while read FIRSTNAME LASTNAME USERNAME
do
echo adding the user: $USERNAME
$QMAILADD -q $QUOTA -c $FIRSTNAME $LASTNAME $USERNAME$MAILDOMAIN $PASS
done
#
Retrieved from
http://wiki.qmailtoaster.com/index.php/Bulk_User_Adding_For_Qmail_Toaster;
This page has been accessed 2,345 times. This page was last modified
08:28, 25 June 2007. Content is available under GNU Free Documentation
License 1.2 http://www.gnu.org/copyleft/fdl.html.
-
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
-
Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] how to control infected users
W dniu 14.07.2009 14:19, Karpaha Vinayaham pisze: Dear All One of my user machine was infected by a virus and it start sending lots of spam mails. As the user was using smtp-auth my server accepted the mail. Because of this my server IP is blacklisted, after diagnosing i have blocked the infected machine IP through iptable and scanned for virus. Now the problem is solved, but i wanted to know how to control this behaviour. With Regards Vinay SMTP proxy can help you: http://smtp-proxy.klolik.org/ It successfuly works on one of my networks. -- Pozdrawiam / Regards, Aleksander Podsiad?y
