Here's the troublesome feature:
CHKUSER_RCPTMX_TMP_STRING 2.0.7 defined "451 DNS
temporary failure
(#4.5.1 - chkuser)\r\n"
String emitted if there is a soft DNS error on recipient domain.
---------------------------- Original Message
----------------------------
Subject: [qmailtoaster] 451 DNS Temporary Failure: Issue that
should be
addressed in CHKUSER
From: "Tim Pleiman"<tplei...@bravosystemstech.net>
Date: Wed, August 31, 2011 2:00 pm
To: qmailtoaster-list@qmailtoaster.com
--------------------------------------------------------------------------
Eric,
Over the last couple of years working with qmailtoaster, I've come to
both
love and hate this particular CHKUSER check.
I keep copies of all the messages from the qmt list, and searching for
the
string "451 DNS Temporary Problem," it seems to me that people have
many
problems with it that could be addressed with some simple fixes to the
CHKUSR code--e.g. more detailed error responses from CHKUSER that
better
define the nature of the problem.
Unlike the posts I've read over the last year or so, I'm not having
any
trouble with my caching nameserver, DJBDNS. It's working properly, has
always been working properly. I love DJBDNS. However, here's the
problem
that I have with this particular CHKUSER check:
When a sender tries to send a message to a single
"u...@domain.com," if
the domain MX is unresolveable in DNS as follows:
2011-08-31 12:56:25.144555500 servfail nc-mail.nchicago.org.
input/output
error
CHKUSR will return the "451 DNS Temporary Failure" error indicative of
the
issue. In this case today, the above particular domain has no MX
record
for it's e-mail--their problem, not mine.
So, this immediately prevents queuing of messages in QMail that cannot
currently be delivered immediately to that one particular domain. This
is
a good thing as it alerts the sender that the message cannot be
delivered
now--e.g. QMail is not going to queue the message now because it would
just sit there, either waiting for the MX to become available or,
if it
does not, bouncing the message after the queuelifetime expires.
Now, aside from the fact that the average person doesn't know what
this
means, I can deal with it, albeit it is not ideal (the average
user-sender
does not know what the heck "451 DNS Temporary Failure" is).
However, when sending out a multi-recipient message, this is when the
issue gets really dicey. CHKUSR stubbornly refuses to queue the
message
at
all for any of the recipients, even the ones that have valid MXes,
as it
simply also returns the "451 DNS Temporary Failure" error with no
other
information at all.
What this means is that the sender of the multi-recipient message
has to
figure out on his/her own which e-mail domain can currently not
accept a
delivery. The only way to determine this is to send the message to
each
of
the recipients individually until you hit the one with the
invalid/unavailable MX.
Now, I think the ultimate resolution of this issue would be for
CHKUSER
to
be updated to provide better error responses on this particular check.
For
single-recipient messages, it should respond with something like "451
DNS
temporary failure: mail server for domain 'somedomain.com' is
currently
unavailable." In the case of multi-recipient messages, it should go
ahead
and queue the message for the valid domains, while returning a similar
error for the MX domain(s) that is not available.
Meanwhile, from what I can tell from the list archives, there is
currently
no way to disable this CHKUSER check entirely without manually
recompiling
CHKUSER.
If there is already a simple fix/adjustment for this, let me know (and
I'll apologize in advance for missing this). Otherwise, it would be
great
in future QMT releases to have this CHKUSER check disabled entirely,
pending an adjustment to CHKUSER, as it results in lots of puzzled
user
inquiries. With this disabled, such messages would go into the
queue for
QMail to bounce on its own. I understand that the feature also alerts
admins to their own DNS server issues as well. However, those
should be
issues that server admins can resolve on their own anyway. It's the
user-related problems that this check causes that, to me, are most
troublesome.
Thanks!
Tim
