Re: [qmailtoaster] Re: Disable CHKUSER
Michael, one more element of discussion. If sender has (for error) domain with wrong MX in sender address, of course no following rcpt could be accepted, as initial acceptance phase of sender has not successed. This is unique case in which also server's sending is rejected as a whole. Ciao! Tonino Il 14/11/2010 00:37, Michael Colvin ha scritto: 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 -- in...@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it
RE: [qmailtoaster] Re: Disable CHKUSER
Yes, but this is not the issue in, at least this specific case. It's definitely a recipient MX resolution issue... Mike -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: Sunday, November 14, 2010 7:50 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER Michael, one more element of discussion. If sender has (for error) domain with wrong MX in sender address, of course no following rcpt could be accepted, as initial acceptance phase of sender has not successed. This is unique case in which also server's sending is rejected as a whole. Ciao! Tonino Il 14/11/2010 00:37, Michael Colvin ha scritto: 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
Re: [qmailtoaster] Re: Disable CHKUSER
Check on exchange side. Check also if there is an option to split a multi recipients delivery in several single recipient deliveries. Tonino Il 14/11/2010 17:37, Michael Colvin ha scritto: Yes, but this is not the issue in, at least this specific case. It's definitely a recipient MX resolution issue... Mike -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: Sunday, November 14, 2010 7:50 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER Michael, one more element of discussion. If sender has (for error) domain with wrong MX in sender address, of course no following rcpt could be accepted, as initial acceptance phase of sender has not successed. This is unique case in which also server's sending is rejected as a whole. Ciao! Tonino Il 14/11/2010 00:37, Michael Colvin ha scritto: 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
RE: [qmailtoaster] Re: Disable CHKUSER
There's a Limit number of messages per connection setting in their Exchange server... I'm assuming that if I set that to 1, it will break a multi-recipient e-mail into multiple single messages... Not sure though. I would think that this would result in individual bounces for bad e-mail addresses... Mike -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: Sunday, November 14, 2010 8:51 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER Check on exchange side. Check also if there is an option to split a multi recipients delivery in several single recipient deliveries. Tonino Il 14/11/2010 17:37, Michael Colvin ha scritto: Yes, but this is not the issue in, at least this specific case. It's definitely a recipient MX resolution issue... Mike -Original Message- From: Tonix (Antonio Nati) [mailto:to...@interazioni.it] Sent: Sunday, November 14, 2010 7:50 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Disable CHKUSER Michael, one more element of discussion. If sender has (for error) domain with wrong MX in sender address, of course no following rcpt could be accepted, as initial acceptance phase of sender has not successed. This is unique case in which also server's sending is rejected as a whole. Ciao! Tonino Il 14/11/2010 00:37, Michael Colvin ha scritto: 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
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] 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: qmailtoaster-list-h
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
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
RE: [qmailtoaster] Re: Disable CHKUSER
On 11/12/2010 12:38 PM, Michael Colvin wrote: OK So, Ive 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, cant find a valid MX for rcpt domain bounce that, basically is bouncing the whole message, so even the valid recipients dont get the e-mail. Ive searched the archives, particularly: http://www.mail-archive.com/qmailtoaster- list%40qmailtoaster.com/msg27066.html, and havent really found anything that helps Unless Im doing something wrong Ive 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. Ive read where the default CHKUSER config is to have these commented out, but it appears that this isnt the QMT default, per the linked thread above. How do I go about commenting these out in CHKUSERs config, and then Rebuild QMT? I installed from the CentOS 5 ISO. I simply dont want to check the MX for any e-mail on these particular servers Id 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. :-) Thanks again, I'll give that a try and see if it resolves my issue...Looks like it will. 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
