QMT has been patched with what is pretty much the cream of the crop of
patches for qmail. See "rpm -qi qmail-toaster". The bigdns patch is
included.
There might be one or two patches from jms which I might consider
including in a future release, but I'm not aware of any patches that are
what I'd consider to be urgent. I'll be revisiting patches when I put
the source code on git, which I plan to do after the QMT 1.5 (COS6) release.
Some resolvers have difficulty resolving DNS records which may be set up
in an peculiar way. (I'm not surprised that a government entity would be
using a peculiar configuration. ;) ) Using a different resolver may be
helpful.
Which dns resolver are you using? Please post contents of
/etc/resolv.conf file. I would expect using pdns-recursor might solve
your problem. You can use pdns-recursor by doing the following:
# yum install pdns-recursor
# service named stop
# service pdns-recursor start
# chkconfig named off
# chkconfig pdns-recursor on
You only need the commands regarding named if you're currently running a
bind resolver (caching-nameserver package is installed).
Then change /etc/resolv.conf to be:
nameserver 127.0.0.1
That should do it.
--
-Eric 'shubes'
On 08/30/2013 06:27 AM, Jim Shupert wrote:
Friends ,
I have a user who cannot email the loc [ library of congress , error
happens when attempting to send to a [email protected] ]
here is the err response
//
Hi. This is the qmail-send program at 'my mailserver my domaine'
I'm afraid I wasn't able to deliver your message to the following
addresses. This is a permanent error; I've given up. Sorry it didn't
work out.
<[email protected]>:
CNAME lookup failed temporarily. (#4.4.3)
I'm not going to try again; this message has been in the queue too long.
//
I did some Googling on the error, and it sounds like this patch below
may fix the problem. It is a qmail problem when dns returns are larger
than 512 bytes.
http://www.memoryhole.net/qmail/qmail-1.03-maildir-uniq.patch
<http://www.memoryhole.net/qmail/qmail-1.03-maildir-uniq.patch>
I’d like to see if we can patch this and have John try sending the
client an email. We will know pretty quickly if this fixed it or not.
Here’s a link to what the problem is:
http://www.memoryhole.net/qmail/#oversize-dns
Go to the section - DNS-related Patches
My Qs
1- Could this 'dns returns < 512 ' be the problem?
2. might this patch be a solution?
from http://www.memoryhole.net/qmail/#oversize-dns
DNS-related Patches
* You can save yourself a lot of trouble, and you can optimize
qmail by trimming its DNS requests to only the information it
really needs. Jonathan de Boyne Pollard wrote this one-liner.
(more details at his qmail page
<http://homepages.tesco.net/%7EJ.deBoynePollard/Softwares/qmail/>,
and while you're at it, check out his djbdns page
<http://homepages.tesco.net/%7EJ.deBoynePollard/FGA/djbdns-problems.html>)
(local copy
<http://www.memoryhole.net/qmail/any-to-cname.patch>)
(homepages.tesco.net
<http://homepages.tesco.net/%7EJ.deBoynePollard/Softwares/qmail/any-to-cname.patch>)
* You should also install Christopher K. Davis's patch to get
qmail to handle large DNS packets. Sometimes (rarely) the answer
to a DNS query is larger than 512 bytes (the max that qmail
allows (which was based on the UDP DNS protocol definition (RFC
1025 <http://www.ietf.org/rfc/rfc1035.txt>, section 4.2.1))).
This is not a widespread occurrence, yet, but can and does
happen from time to time. This patch allows DNS packets to be as
big as the maximum DNS response size, but does not waste memory
if you never see one that's that big. (local copy
<http://www.memoryhole.net/qmail/qmail-103.patch>) (ckdhr.com
<http://www.ckdhr.com/ckd/qmail-103.patch>)
3- and which patch would that be?? the local copy
<http://www.memoryhole.net/qmail/qmail-103.patch>
It seems these patchs are for `netqmail' is that the same as qmailtoaster?
according to that site the means of applying the patch is
//
Apply these patches with the following commands:
|cd /path/to/netqmail/
patch -p1 < /path/to/patch
|
well , I do not think I Have a dir named " netqmail"
my toaster is : qmailtoaster-plus-0.3.0.1.4.4
Any assistance is appreciated
Thanks Much
jim S
here is what the patch is --
:: qmail-1.03-maildir-uniq.patch ::
Some operating systems quickly recycle PIDs, which can lead
to collisions between Maildir-style filenames, which must
be unique and non-repeatable within one second.
This patch is just a means of updating qmail-local to use
the format of the revised Maildir protocol, available at:
http://cr.yp.to/proto/maildir.html
It uses four unique identifiers:
* inode number of the file written to Maildir/tmp
* device number of the file written to Maildir/tmp
* time in microseconds
* the PID of the writing process
A Maildir-style filename would look like the following:
In Maildir/tmp:
time.MmicrosecondsPpid.host
In Maildir/new:
time.IinodeVdeviceMmicrosecondsPpid.host
Additionally, this patch further comforms to the revised
Maildir protocol by looking through the hostname for
instances of '/' and ':', replacing them with "057" and
"072", respectively, when writing it to disk.
Special thanks go to Matthias Andree for design and
sanity-checking.
--Toby Betts <[email protected]>
--- ./qmail-local.c.orig Mon Jun 15 06:52:55 1998
+++ ./qmail-local.c Mon Jun 16 16:09:05 2003
@@ -1,4 +1,5 @@
#include <sys/types.h>
+#include <sys/time.h>
#include <sys/stat.h>
#include "readwrite.h"
#include "sig.h"
@@ -41,6 +42,20 @@
void temp_qmail(fn) char *fn;
{ strerr_die5x(111,"Unable to open ",fn,": ",error_str(errno),".
(#4.3.0)"); }
+/* writes ulong u in hex to char *s, does not NULL-terminate */
+unsigned int fmt_xlong(s,u) char *s; unsigned long u;
+{
+ unsigned int len; unsigned long q; unsigned long c;
+ len = 1; q = u;
+ while (q > 15) { ++len; q /= 16; }
+ if (s)
+ {
+ s += len;
+ do { c = u & 15; *--s = (c > 9 ? 'a' - 10 : '0') + c; u /= 16; }
while(u);
+ }
+ return len;
+}
+
int flagdoit;
int flag99;
@@ -63,6 +78,7 @@
stralloc cmds = {0};
stralloc messline = {0};
stralloc foo = {0};
+stralloc hostname = {0};
char buf[1024];
char outbuf[1024];
@@ -78,7 +94,7 @@
char *dir;
{
unsigned long pid;
- unsigned long time;
+ struct timeval time;
char host[64];
char *s;
int loop;
@@ -92,21 +108,37 @@
pid = getpid();
host[0] = 0;
gethostname(host,sizeof(host));
+
+ s = host;
+ for (loop = 0; loop < str_len(host); ++loop)
+ {
+ if (host[loop] == '/')
+ {
+ if (!stralloc_cats(&hostname,"057")) temp_nomem();
+ continue;
+ }
+ if (host[loop] == ':')
+ {
+ if (!stralloc_cats(&hostname,"072")) temp_nomem();
+ continue;
+ }
+ if (!stralloc_append(&hostname,s+loop)) temp_nomem();
+ }
+
for (loop = 0;;++loop)
{
- time = now();
+ gettimeofday(&time, 0);
s = fntmptph;
s += fmt_str(s,"tmp/");
- s += fmt_ulong(s,time); *s++ = '.';
- s += fmt_ulong(s,pid); *s++ = '.';
- s += fmt_strn(s,host,sizeof(host)); *s++ = 0;
+ s += fmt_ulong(s,time.tv_sec); *s++ = '.';
+ *s++ = 'M'; s += fmt_ulong(s,time.tv_usec);
+ *s++ = 'P'; s += fmt_ulong(s,pid); *s++ = '.';
+ s += fmt_strn(s,hostname.s,hostname.len); *s++ = 0;
if (stat(fntmptph,&st) == -1) if (errno == error_noent) break;
/* really should never get to this point */
if (loop == 2) _exit(1);
sleep(2);
}
- str_copy(fnnewtph,fntmptph);
- byte_copy(fnnewtph,3,"new");
alarm(86400);
fd = open_excl(fntmptph);
@@ -124,8 +156,23 @@
}
if (substdio_flush(&ssout) == -1) goto fail;
+ if (fstat(fd, &st) == -1) goto fail;
if (fsync(fd) == -1) goto fail;
if (close(fd) == -1) goto fail; /* NFS dorks */
+
+ s = fnnewtph;
+ s += fmt_str(s,"new/");
+ s += fmt_ulong(s,time.tv_sec); *s++ = '.';
+
+ /* in hexadecimal */
+ *s++ = 'I'; s += fmt_xlong(s,st.st_ino);
+ *s++ = 'V'; s += fmt_xlong(s,st.st_dev);
+
+ /* in decimal */
+ *s++ = 'M'; s += fmt_ulong(s,time.tv_usec);
+ *s++ = 'P'; s += fmt_ulong(s,pid); *s++ = '.';
+
+ s += fmt_strn(s,hostname.s,hostname.len); *s++ = 0;
if (link(fntmptph,fnnewtph) == -1) goto fail;
/* if it was error_exist, almost certainly successful; i hate NFS */
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
