> 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
