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]
