[qmailtoaster] Re: Disable CHKUSER
Perhaps. Is that limit for inbound or outbound messages (or both)? There is a 'feature' in the smtp spec that allows multiple messages (distinct, entirely different messages) to be delivered in a single smtp connection. I don't think is used very often though. I expect this is what that setting pertains to, instead of the number of recipients per message. -- -Eric 'shubes' On 11/14/2010 10:06 AM, Michael Colvin wrote: 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 w
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
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
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 qma
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 -
