Sorry, but your analisys is partially wrong.
When chkuser has a negative answer from DNS, it sends back:
*CHKUSER_RCPTMX_STRING* 2.0.5 defined "511 sorry, can't find
a valid
MX for rcpt domain (#5.1.1 - chkuser)\r\n"
or
*CHKUSER_SENDERMX_STRING* 2.0.5 defined "511 sorry, can't find a
valid MX for sender domain (#5.1.1 - chkuser)\r\n"
This is a definitive NO to accepting single recipient, as a working DNS
said there is no MX for recipient domain (same mechanism for sender
check).
Only when there is NO answer from DNS, that means NO DNS server is
answering our questions, chkuser sends back messages you are reporting,
which tell remote system to try later.
But main problem is another: how clients manage errors coming from
servers.
SMTP is for servers mainly, not for clients.
Mail clients like Outlook stop at first error, so it is a client problem
to manage.
CHKUSER respects how smtp protocol works: for each recipient say OK or KO.
So:
* ok, recipient exists
* ko, recipients does not exist
* ko, mailbox full
* ok, relayed
* ko, not relayed
* ko, dns error
* ko, mx not existing
* etc
You may have the same problem for a mailbox full (one mailbox full in a
twenty recipients list), or similar problems.
Servers do not stop at any error, but continue sending each remaining
recipient, and then play accordingly to all status received for each
recipient.
Instead, clients stop sometimes at first error and do not know how to
manage errors; a server manages a "451" error, retrying later, while a
client does not manage it at all.
So, my suggested (and personal) solution is:
* public MX, where all errors are handled fully, with remote
servers having full errors back immediately.
* dedicated relay server (on different IP or port), where auth
users can send/relay: here the most of checks are disabled, so the
server will accept anything, and then will send back detailed
e-mails for errors on single deliveries.
You should have two different qmail-smtp process listening: one on port
25 for MX and one on submission port (587) for authenticated customers,
and two servers should act in different ways, as said before.
Actually I use these design:
* public MX, accepting only to my domains, with full CHKUSER.
* auth relay on different IP, working both on port 25 and 587, with
CHKUSER disabled.
About disabling chkuser, with version 2.0.9 I suggest using
*CHKUSER_DISABLE_VARIABLE * 2.0.9 commented "CHKUSER_MUSTAUTH"
and
*CHKUSER_EXTRA_MUSTAUTH_VARIABLE* 2.0.9 undefined
"CHKUSER_MUSTAUTH"
for having a server accepting only authenticated users (any port or
submission port).
For version 2.0.8 you may use (recompiling) both:
*CHKUSER_SENDER_NOCHECK_VARIABLE * 2.0.5 commented "SENDER_NOCHECK"
*CHKUSER_STARTING_VARIABLE* 2.0.5 commented "CHKUSER_START"
Playing with those settings, you may enable or disable chkuser
accordingly to variable settings.
For such scopes, I sugges not to put variables inside tcp.smtp, but
directly within running command, because behaviour is per server and not
per IP.
Regards,
Tonino
Il 31/08/2011 21:00, Tim Pleiman ha scritto:
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
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it to...@interazioni.it
------------------------------------------------------------
