Tonino, Aha! Thanks for clarifying this:
"Mail clients like Outlook stop at first error, so it is a client problem to manage." and "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." Eric, Jake, I just did some testing with SquirrelMail vs. the eGroupware webmail client, and it turns out that the issue with the "dumb" "451 DNS Temporary Failure" error is unique to how SquirrelMail is handling the error response from CHKUSER in an insufficient manner. SquirrelMail returns the message with the base error only without returning any other information--e.g. the message does not process and the error does not include the e-mail address that has failed in the error message. That is a problem with the SquirrelMail webmail client. On the other hand, the eGroupware mail client, sending outbound via the exact same QMT qmail server with CHKUSER_RCPT_MX enabled also fails to send the message, BUT IT DOES return an informative error message that actually indicates WHICH e-mail address has failed, even when sending to more than one recipient. This then allows the sender to correct the outbound recipient list and resend. This is desirable behavior. OK, so since QMT installs with SquirrelMail as the default web client, either the issue may need to be fixed at squirrelmail.org or there might need to be some sort of notation in QMT docs that SquirrelMail does not handle the SMTP server error responses adequately in the above regard (alternatively users should turn off CHKUSER_RCPT_MX in the manner that is scheduled to be released with QMTv2). I would have expected Outlook to be non-compliant in such regaurd, but I hadn't thought this would be an issue with SquirrelMail (which I've used for years). Apparently, it is. For clients that don't process the error properly, users will need to be able to turn off these features. So, the problem here is definitely with SquirrelMail. This has been an informative discussion. As it turns out, I'm migrating all my users to eGroupware over the next 6 months, so this should become a moot issue for me anyway, but perhaps this will be helpful for someone else. Thanks everyone! Tim On Wed, August 31, 2011 5:22 pm, Tonix (Antonio Nati) wrote: > 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 "[email protected]," 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 [email protected] > ------------------------------------------------------------ > > -- Tim Pleiman Bravo Systems Technologies "Advanced Open Source Solutions for Business" Chicago, IL USA --------------------------------------------------------------------------------- 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]
