On Monday 03 November 2008 07:38, Felix Knecht wrote:
> Scott Kitterman wrote:
> > d40c236a7b592c5a51a055c3d1456650 python-dns_2.3.3-2~0etchtest_all.deb
>
...
>File "/usr/share/python-support/python-spf/spf.py", line 105, in
> DNSLookup
> raise TempError, 'DNS ' + str(x)
> __main__.TempEr
Scott Kitterman wrote:
d40c236a7b592c5a51a055c3d1456650 python-dns_2.3.3-2~0etchtest_all.deb
This one gives me:
Traceback (most recent call last):
File "/usr/share/python-support/python-spf/spf.py", line 1621, in ?
print q.dns_spf(sys.argv[1])
File "/usr/share/python-support/python-sp
I've prepared two test packages. One is the current Lenny package slightly
modified to work in an Etch environment. The other has a proposed fix for your
problem. I'd like it if you could install first the Lenny package and then the
proposed fix package and rerun each of the same tests and re
Thank you. That should help.
The bad news is that something in your infrastructure is truncating TCP DNS
packets. You ought to find out what that is and fix it (without knowing, I'm
guessing a buggy firewall). But as you say, it still shouldn't crash.
--
To UNSUBSCRIBE, email to [EMAIL
> I think what would be most useful now would be if you could capture port FT
> both UDP and TCP with Wireshark, tcpdump, etc. when doing the above tests.
> I need to see what's in the packet that's causing the crash.
I attached a file containing the raw dump for all 3 tests.
I used tcpdump with o
On Sat, 01 Nov 2008 10:56:18 +0100 Felix Knecht <[EMAIL PROTECTED]>
wrote:
>Thanks for identifying the problem! I agree that it is not exactly a
>bug, but I guess python-spf shouldn't crash on this and get the incoming
>mail rejected.
>
>Anyway, heres the info you requested:
>
>
>Scott Kitterman
That explains it. The python-spf in Etch Backports doesn't support TCP
fallback. It's not actually a bug in python-dns. It's not really a bug in
python-spf either since RFC 4408 recommends against publishing records big
enough to need TCP, but a missing feature.
The Lenny version supports th
Today I tried to add amazon.com to my SPF domain whitelist, which
resulted in the error for each and every mail. This probably happens
because it tries to resolve the whitelist each time. So there definitely
seems to be something wrong with the results of a DNS resolve of the
amazon.com domain.
I also get this bug in the logs. Noticed it when amazon mail stopped
coming in. So here are the log entries:
Oct 31 07:01:47 felixknecht policyd-spf[27208]: None; identity=helo;
client-ip=84.254.213.97; helo=host97.fnet2.ae21vek.ru;
[EMAIL PROTECTED]; receiver=
Oct 31 07:21:40 felixknech
FYI, I the bug appears to have been hit on July 10th, and July 24th, and
then not again until Sept 10th. I generally apply Debian security
patches within a day or so, I think the bug was hit both before and
after the security fix for #490217 was installed.
The three emails in question are:
J
I've taken a look at the python-dns code and there are some changes in the
current version (in Lenny) that may have solved this, but I'm not sure. In
the logs, can you get the domain or email address that was involved in this?
I need that to try an replicate the problem.
signature.asc
Descri
11 matches
Mail list logo