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:[email protected]] 
Sent: Sunday, November 14, 2010 8:51 AM
To: [email protected]
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:[email protected]]
> Sent: Sunday, November 14, 2010 7:50 AM
> To: [email protected]
> 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:
> [email protected]
>>        For additional commands, e-mail:
> [email protected]
>>
>>
>


-- 
------------------------------------------------------------
         in...@zioni            Interazioni di Antonio Nati
    http://www.interazioni.it      [email protected]
------------------------------------------------------------


----------------------------------------------------------------------------
-----
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: [email protected]
     For additional commands, e-mail:
[email protected]




---------------------------------------------------------------------------------
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: [email protected]
     For additional commands, e-mail: [email protected]


Reply via email to