Re: [qmailtoaster] Re: iptables firewall issue
On 11/11/2010 03:46 PM, Eric Shubert wrote: On 11/11/2010 01:10 PM, Jake Vickers wrote: On 11/11/2010 02:27 PM, Scott Hughes wrote: On Thu, Nov 11, 2010 at 1:17 PM, Eric Shubert e...@shubes.net mailto:e...@shubes.net wrote: On 11/11/2010 11:59 AM, Scott Hughes wrote: On Thu, Nov 11, 2010 at 12:35 PM, Eric Shubert e...@shubes.net mailto:e...@shubes.net Something's changing iptables. If it's not changing the /etc/sysconfig/iptables file, then it must be changing iptables on the fly, after init starts iptables (which uses the /etc/sysconfig/iptables file). Anything in rc.local? -- -Eric 'shubes' I think you may have found the issue. Here is what is in rc.local ## Bring up firewall /sbin/iptables-restore /etc/rc.d/firewall.ruleset I think that is what is causing my issue. Would it be okay to change the /etc/rc.d/firewall.ruleset to /etc/sysconfig/iptables ?? Thanks again, Scott rc.local is used for local customization. I've no idea how what you have got there. I do have a firewall.ruleset file on my system, but it doesn't belong to any package, and I don't see anywhere that it's used. I would simply comment out what you have in rc.local, and let the stock settings operate as they do. Just check to be sure that iptables is started (# chkconfig --list iptables), and iptables should start normally with whatever is in your /etc/sysconfig/iptables file. You might do -- -Eric 'shubes' Commenting out that line in rc.local seems to have done the trick. I have this same issue on two of my QMT boxes. They were both loaded from the QMT 5 ISO cd-rom. Might be something that needs to be checked. Thanks again Eric! Scott No checking needed. The ISO contains a firewall setup and is documented on the ISO page on the wiki: http://wiki.qmailtoaster.com/index.php/QMT-ISO_Manual_Guide#Setting_iptables Is there some reason that QMT-ISO doesn't use the conventional mechanism for starting iptables? Yes. - 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: Disable CHKUSER
On 11/12/2010 07:15 PM, Michael Colvin wrote: On 11/12/2010 12:38 PM, Michael Colvin wrote: OK… So, I’ve got some clients that send mails out to affiliates of theirs via rather large distribution lists. When at least one, maybe more, of those addresses are bad, they get the “Sorry, can’t find a valid MX for rcpt domain” bounce that, basically is bouncing the whole message, so even the valid recipients don’t get the e-mail. I’ve searched the archives, particularly: http://www.mail-archive.com/qmailtoaster- list%40qmailtoaster.com/msg27066.html, and haven’t really found anything that helps…Unless I’m doing something wrong… I’ve tried removing the references to CHKUSER_RCPT_MX in tcp.smtp, then issued qmailctl cdb, same issue. I tried setting CHKUSER_RCPT_MX=””, and CHKUSER_RCPT-MX=”0”… Nothing. Tried setting CHKUSER_STARTING_VARIABLE=”NONE”…No change. I’ve read where the default CHKUSER config is to have these commented out, but it appears that this isn’t the QMT default, per the linked thread above. How do I go about commenting these out in CHKUSER’s config, and then “Rebuild” QMT? I installed from the CentOS 5 ISO. I simply don’t want to check the MX for any e-mail on these particular servers…I’d rather the client get bounces for those e-mails, so they can clean up their lists. http://wiki.qmailtoaster.com/index.php/Chkuser ;) -- -Eric 'shubes' Thanks Eric...Not sure how I missed that...I know I dug around on the Wiki during my searches... Tossing my .02 into the earlier thread that I linked too, I would agree with your comment that these settings should be something that are Enabled in tcp.smtp... That would be more User friendly. Another item for Jake's already full to-do list. :-) And also one I disagree with. We've had some discussion (and argument) on this topic several times. If you look at the number of downloads versus questions concerning modifying chkuser, one out of every (roughly) 5000 people wants to modify it (and almost ALWAYS to work around an issue such as this - laziness on someone elses part). Now this number is small, comparatively. If the setting gets added to the tcp.smtp file, now we're exposing those other 4999 people to potentially turning an option they want on off, or stopping mail flow, from a typo in their tcp.smtp file. For the record, I am completely against changing this option. I think a MX check SHOULD be mandatory, for many reasons. Now, to stop the flame war that will ensue, the new version will use the default chkuser settings. All other options will need to be enabled in the tcp.smtp file or recompiled in. - 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] QMT Use Stats
On 11/12/2010 07:00 PM, Eric Shubert wrote: FWIW, here's an interesting link: http://www.securityspace.com/s_survey/data/man.200910/mxsurvey.html That data is a year old. Summarizing the last few years for QMT: Year Servers Percent 11/09 1844 .20 02/09 1642 .20 02/08 1583 .17 02/07 1174 .13 11/06 1028 .11 So from 11/06 - 11/09, QMT has averaged growth of about 25% per year. Not great market penetration (yet), but respectable growth. Interesting. Thanks Eric! - 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] iptables firewall issue
On 11/12/2010 09:44 AM, Scott Hughes wrote: Martin, The problem turned out to be in the rc.local file. It was loading the basic QMT firewall settings instead of firewalll setting in the iptables file. Once I commented out that line in the rc.local file, it worked perfect (survived the reboot process). Unless you specifically changed it, the default firewall was disabled and the one in the rc file loaded. - 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: Disable CHKUSER
Hi all, I wonder about this one... First of all, I agree with Jake that MX verification is rather important. However, the problem at hand is also a nuisance: Why should one bad address out of 15 in the list cause all mails to not be delivered? I guess the solution here would rather be looking at some way to solve that issue and leave the rest as it is, meaning that all good addresses on a list should be properly sent the mail and all addresses that fail MX check should not go out. At any rate, disabling a complete check because the check does not do what it should is a poor solution. Rather fix the real issue... So, can someone isolate where that problem has its root and then we could figure out how to address the underlying issue? My guess would be someone would have to either look at the code for checkuser or take it up with the vpopmail mailing list? I'd be happy to attempt looking into this... Martin -Ursprüngliche Nachricht- From: Jake Vickers Sent: Saturday, November 13, 2010 2:10 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER On 11/12/2010 07:15 PM, Michael Colvin wrote: On 11/12/2010 12:38 PM, Michael Colvin wrote: OK… So, I’ve got some clients that send mails out to affiliates of theirs via rather large distribution lists. When at least one, maybe more, of those addresses are bad, they get the “Sorry, can’t find a valid MX for rcpt domain” bounce that, basically is bouncing the whole message, so even the valid recipients don’t get the e-mail. I’ve searched the archives, particularly: http://www.mail-archive.com/qmailtoaster- list%40qmailtoaster.com/msg27066.html, and haven’t really found anything that helps…Unless I’m doing something wrong… I’ve tried removing the references to CHKUSER_RCPT_MX in tcp.smtp, then issued qmailctl cdb, same issue. I tried setting CHKUSER_RCPT_MX=””, and CHKUSER_RCPT-MX=”0”… Nothing. Tried setting CHKUSER_STARTING_VARIABLE=”NONE”…No change. I’ve read where the default CHKUSER config is to have these commented out, but it appears that this isn’t the QMT default, per the linked thread above. How do I go about commenting these out in CHKUSER’s config, and then “Rebuild” QMT? I installed from the CentOS 5 ISO. I simply don’t want to check the MX for any e-mail on these particular servers…I’d rather the client get bounces for those e-mails, so they can clean up their lists. http://wiki.qmailtoaster.com/index.php/Chkuser ;) -- -Eric 'shubes' Thanks Eric...Not sure how I missed that...I know I dug around on the Wiki during my searches... Tossing my .02 into the earlier thread that I linked too, I would agree with your comment that these settings should be something that are Enabled in tcp.smtp... That would be more User friendly. Another item for Jake's already full to-do list. :-) And also one I disagree with. We've had some discussion (and argument) on this topic several times. If you look at the number of downloads versus questions concerning modifying chkuser, one out of every (roughly) 5000 people wants to modify it (and almost ALWAYS to work around an issue such as this - laziness on someone elses part). Now this number is small, comparatively. If the setting gets added to the tcp.smtp file, now we're exposing those other 4999 people to potentially turning an option they want on off, or stopping mail flow, from a typo in their tcp.smtp file. For the record, I am completely against changing this option. I think a MX check SHOULD be mandatory, for many reasons. Now, to stop the flame war that will ensue, the new version will use the default chkuser settings. All other options will need to be enabled in the tcp.smtp file or recompiled in. - 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 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:
Re: [qmailtoaster] Re: Disable CHKUSER
I meant chkuser mailing list... I am not completely awake it seems... -Ursprüngliche Nachricht- From: Martin Waschbuesch Sent: Saturday, November 13, 2010 3:04 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER Hi all, I wonder about this one... First of all, I agree with Jake that MX verification is rather important. However, the problem at hand is also a nuisance: Why should one bad address out of 15 in the list cause all mails to not be delivered? I guess the solution here would rather be looking at some way to solve that issue and leave the rest as it is, meaning that all good addresses on a list should be properly sent the mail and all addresses that fail MX check should not go out. At any rate, disabling a complete check because the check does not do what it should is a poor solution. Rather fix the real issue... So, can someone isolate where that problem has its root and then we could figure out how to address the underlying issue? My guess would be someone would have to either look at the code for checkuser or take it up with the vpopmail mailing list? I'd be happy to attempt looking into this... Martin -Ursprüngliche Nachricht- From: Jake Vickers Sent: Saturday, November 13, 2010 2:10 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER On 11/12/2010 07:15 PM, Michael Colvin wrote: On 11/12/2010 12:38 PM, Michael Colvin wrote: OK… So, I’ve got some clients that send mails out to affiliates of theirs via rather large distribution lists. When at least one, maybe more, of those addresses are bad, they get the “Sorry, can’t find a valid MX for rcpt domain” bounce that, basically is bouncing the whole message, so even the valid recipients don’t get the e-mail. I’ve searched the archives, particularly: http://www.mail-archive.com/qmailtoaster- list%40qmailtoaster.com/msg27066.html, and haven’t really found anything that helps…Unless I’m doing something wrong… I’ve tried removing the references to CHKUSER_RCPT_MX in tcp.smtp, then issued qmailctl cdb, same issue. I tried setting CHKUSER_RCPT_MX=””, and CHKUSER_RCPT-MX=”0”… Nothing. Tried setting CHKUSER_STARTING_VARIABLE=”NONE”…No change. I’ve read where the default CHKUSER config is to have these commented out, but it appears that this isn’t the QMT default, per the linked thread above. How do I go about commenting these out in CHKUSER’s config, and then “Rebuild” QMT? I installed from the CentOS 5 ISO. I simply don’t want to check the MX for any e-mail on these particular servers…I’d rather the client get bounces for those e-mails, so they can clean up their lists. http://wiki.qmailtoaster.com/index.php/Chkuser ;) -- -Eric 'shubes' Thanks Eric...Not sure how I missed that...I know I dug around on the Wiki during my searches... Tossing my .02 into the earlier thread that I linked too, I would agree with your comment that these settings should be something that are Enabled in tcp.smtp... That would be more User friendly. Another item for Jake's already full to-do list. :-) And also one I disagree with. We've had some discussion (and argument) on this topic several times. If you look at the number of downloads versus questions concerning modifying chkuser, one out of every (roughly) 5000 people wants to modify it (and almost ALWAYS to work around an issue such as this - laziness on someone elses part). Now this number is small, comparatively. If the setting gets added to the tcp.smtp file, now we're exposing those other 4999 people to potentially turning an option they want on off, or stopping mail flow, from a typo in their tcp.smtp file. For the record, I am completely against changing this option. I think a MX check SHOULD be mandatory, for many reasons. Now, to stop the flame war that will ensue, the new version will use the default chkuser settings. All other options will need to be enabled in the tcp.smtp file or recompiled in. - 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 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!
Re: [qmailtoaster] Re: Disable CHKUSER
Il 13/11/2010 15:04, Martin Waschbuesch ha scritto: Hi all, I wonder about this one... First of all, I agree with Jake that MX verification is rather important. However, the problem at hand is also a nuisance: Why should one bad address out of 15 in the list cause all mails to not be delivered? Is this problem related to clients or to emails coming from servers? Double check with clients, because a lot of them stop sending as receive the first error back, while servers continue sending remaining recipients. For my authenticated senders I've complitely disabled chkuser, using a dedicated ip only for this purpose (relaying). If you cannot have a dedicated IP you can always use submission port, and setup a dedicated qmail-smtpd for this usage. On public MX I have chkuser full optional. Regards, Tonino I guess the solution here would rather be looking at some way to solve that issue and leave the rest as it is, meaning that all good addresses on a list should be properly sent the mail and all addresses that fail MX check should not go out. At any rate, disabling a complete check because the check does not do what it should is a poor solution. Rather fix the real issue... So, can someone isolate where that problem has its root and then we could figure out how to address the underlying issue? My guess would be someone would have to either look at the code for checkuser or take it up with the vpopmail mailing list? I'd be happy to attempt looking into this... Martin -Ursprüngliche Nachricht- From: Jake Vickers Sent: Saturday, November 13, 2010 2:10 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER On 11/12/2010 07:15 PM, Michael Colvin wrote: On 11/12/2010 12:38 PM, Michael Colvin wrote: OK… So, I’ve got some clients that send mails out to affiliates of theirs via rather large distribution lists. When at least one, maybe more, of those addresses are bad, they get the “Sorry, can’t find a valid MX for rcpt domain” bounce that, basically is bouncing the whole message, so even the valid recipients don’t get the e-mail. I’ve searched the archives, particularly: http://www.mail-archive.com/qmailtoaster- list%40qmailtoaster.com/msg27066.html, and haven’t really found anything that helps…Unless I’m doing something wrong… I’ve tried removing the references to CHKUSER_RCPT_MX in tcp.smtp, then issued qmailctl cdb, same issue. I tried setting CHKUSER_RCPT_MX=””, and CHKUSER_RCPT-MX=”0”… Nothing. Tried setting CHKUSER_STARTING_VARIABLE=”NONE”…No change. I’ve read where the default CHKUSER config is to have these commented out, but it appears that this isn’t the QMT default, per the linked thread above. How do I go about commenting these out in CHKUSER’s config, and then “Rebuild” QMT? I installed from the CentOS 5 ISO. I simply don’t want to check the MX for any e-mail on these particular servers…I’d rather the client get bounces for those e-mails, so they can clean up their lists. http://wiki.qmailtoaster.com/index.php/Chkuser ;) -- -Eric 'shubes' Thanks Eric...Not sure how I missed that...I know I dug around on the Wiki during my searches... Tossing my .02 into the earlier thread that I linked too, I would agree with your comment that these settings should be something that are Enabled in tcp.smtp... That would be more User friendly. Another item for Jake's already full to-do list. :-) And also one I disagree with. We've had some discussion (and argument) on this topic several times. If you look at the number of downloads versus questions concerning modifying chkuser, one out of every (roughly) 5000 people wants to modify it (and almost ALWAYS to work around an issue such as this - laziness on someone elses part). Now this number is small, comparatively. If the setting gets added to the tcp.smtp file, now we're exposing those other 4999 people to potentially turning an option they want on off, or stopping mail flow, from a typo in their tcp.smtp file. For the record, I am completely against changing this option. I think a MX check SHOULD be mandatory, for many reasons. Now, to stop the flame war that will ensue, the new version will use the default chkuser settings. All other options will need to be enabled in the tcp.smtp file or recompiled in. - 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] Re: QMT Use Stats
On 11/13/2010 06:11 AM, Jake Vickers wrote: On 11/12/2010 07:00 PM, Eric Shubert wrote: FWIW, here's an interesting link: http://www.securityspace.com/s_survey/data/man.200910/mxsurvey.html That data is a year old. Summarizing the last few years for QMT: Year Servers Percent 11/09 1844 .20 02/09 1642 .20 02/08 1583 .17 02/07 1174 .13 11/06 1028 .11 So from 11/06 - 11/09, QMT has averaged growth of about 25% per year. Not great market penetration (yet), but respectable growth. Interesting. Thanks Eric! - I might add that, in the same period, that QMT went from 24th to 14th in the list. That's impressive! -- -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
[qmailtoaster] Re: iptables firewall issue
On 11/13/2010 05:58 AM, Jake Vickers wrote: On 11/11/2010 03:46 PM, Eric Shubert wrote: Is there some reason that QMT-ISO doesn't use the conventional mechanism for starting iptables? Yes. If you recall what that reason is, would you care to share it with us? Perhaps we can come up with a way of using the conventional method with the iso. ;) -- -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
[qmailtoaster] Re: Disable CHKUSER
On 11/13/2010 07:16 AM, Tonix (Antonio Nati) wrote: Il 13/11/2010 15:04, Martin Waschbuesch ha scritto: Hi all, I wonder about this one... First of all, I agree with Jake that MX verification is rather important. However, the problem at hand is also a nuisance: Why should one bad address out of 15 in the list cause all mails to not be delivered? Is this problem related to clients or to emails coming from servers? This is a key question, as they should be treated differently. Incoming messages need MX verification so that bounces have a better probability of being deliverable. Submissions, on the other hand, are rejected directly during the smtp session to the user's client, so there is no bounce (as far as QMT is concerned) and thus no need for MX verification. Double check with clients, because a lot of them stop sending as receive the first error back, while servers continue sending remaining recipients. For my authenticated senders I've completely disabled chkuser, using a dedicated ip only for this purpose (relaying). If you cannot have a dedicated IP you can always use submission port, and setup a dedicated qmail-smtpd for this usage. I like this solution. I've said before that I think that port 25 (incoming smtp) and port 587 (submission) should have separate tcp.smtp files. Such configuration facilitates turning off chkuser on port 587, which I like as a solution for this. Thanks for chiming in on this, Tonino. -- -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
[qmailtoaster] Re: Disable CHKUSER
On 11/13/2010 07:08 AM, Martin Waschbuesch wrote: I meant chkuser mailing list... I am not completely awake it seems... That's funny, Martin. You see, Tonino uses the vpop -- -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
[qmailtoaster] Re: Disable CHKUSER
That's funny, Martin. You see, Tonino uses the vpopmail list for chkuser! I'm glad to see that Tonino hangs out here as well. :) -- -Eric 'shubes' On 11/13/2010 07:08 AM, Martin Waschbuesch wrote: I meant chkuser mailing list... I am not completely awake it seems... -Ursprüngliche Nachricht- From: Martin Waschbuesch Sent: Saturday, November 13, 2010 3:04 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER Hi all, I wonder about this one... First of all, I agree with Jake that MX verification is rather important. However, the problem at hand is also a nuisance: Why should one bad address out of 15 in the list cause all mails to not be delivered? I guess the solution here would rather be looking at some way to solve that issue and leave the rest as it is, meaning that all good addresses on a list should be properly sent the mail and all addresses that fail MX check should not go out. At any rate, disabling a complete check because the check does not do what it should is a poor solution. Rather fix the real issue... So, can someone isolate where that problem has its root and then we could figure out how to address the underlying issue? My guess would be someone would have to either look at the code for checkuser or take it up with the vpopmail mailing list? I'd be happy to attempt looking into this... Martin - 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: Disable CHKUSER
On 11/13/2010 07:16 AM, Tonix (Antonio Nati) wrote: Il 13/11/2010 15:04, Martin Waschbuesch ha scritto: Hi all, I wonder about this one... First of all, I agree with Jake that MX verification is rather important. However, the problem at hand is also a nuisance: Why should one bad address out of 15 in the list cause all mails to not be delivered? Is this problem related to clients or to emails coming from servers? This is a key question, as they should be treated differently. Incoming messages need MX verification so that bounces have a better probability of being deliverable. Submissions, on the other hand, are rejected directly during the smtp session to the user's client, so there is no bounce (as far as QMT is concerned) and thus no need for MX verification. Double check with clients, because a lot of them stop sending as receive the first error back, while servers continue sending remaining recipients. For my authenticated senders I've completely disabled chkuser, using a dedicated ip only for this purpose (relaying). If you cannot have a dedicated IP you can always use submission port, and setup a dedicated qmail-smtpd for this usage. I like this solution. I've said before that I think that port 25 (incoming smtp) and port 587 (submission) should have separate tcp.smtp files. Such configuration facilitates turning off chkuser on port 587, which I like as a solution for this. Thanks for chiming in on this, Tonino. I agree Jake, to some degree. As Martin pointed out, the issue is that this particular customer is sending to a list with 200+ on it. When it bounces back saying ALL of them couldn't resolve an MX for the domain, that's an issue... It's hard for them to keep their list clean, when they can't tell which one is causing the bounce, and I can't really expect them to test each account, or call each person on their distribution list. Nor am I going to do it. :-) As far as whether it's a mail client issue, or server issue, I'm not sure. But, I think in my particular case, it's neither...Well, that is, it's not *MY* server. This particular client has an Exchange server. They send their e-mail from Outlook, to their Exchange server, which then uses my servers for relaying, or a Smarthost... This particular cluster of servers is used solely for filtering client e-mail inbound, and for some clients to use for outbound. I have another cluster that I use for ISP Access customers (DSL, Dialup, Hosting, etc), but they are still using a non-toaster for outbound, so this issue hasn't surfaced, yet, but with most of them using Outlook to connect directly to the server, I'm assuming they'll get individual bounces back? I agree with, I think it was Eric, that fixing the actual issue with how CHKUSER handles these bad MX records would be better... If it would only bounce the bad addresses, that would be preferred. But, from what Tonino said, I'm now wondering if this isn't actually an issue with how Exchange is handling CHKUSER's notification that a given address is Bad... I know during my testing, if I entered a bad e-mail domain via telnet session, it would give me the error message, but I could still enter another address, and those would go through. So, is this Exchange seeing the reject message, and then just assuming the rest are bad? It doesn't appear as though QMT is closing the session...So, this may be... I appreciate that you're switching to the stock CHKUSER setup in QMT2, but I agree with you that this *IS* a valuable feature, and I would prefer to have it enabled... It just needs a little tweaking, or Exchange does... Michael J. Colvin NorCal Internet Services www.norcalisp.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