Hi,

I've read several messages that describe something similar to what I'm
seeing, but no solutions that apply. I agree that the TB extension is
a good idea and could be really usefull.

OK here's the problem:

I have a message that comes from a SPF supporting server (I configured
it myself, and it passes several tests with external tools I made),
the headers are as clear as you can expect:

Return-path: <sender@...>
Envelope-to: rberber@...
Delivery-date: Mon, 07 Aug 2006 10:44:59 -0500
Received: from mail.legosoft.com.mx ([200.52.129.137])
by cactus-soft.dyndns.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.62)
(envelope-from <sender@...>)
id J3MX2X-000258-D0
for rberber@...; Mon, 07 Aug 2006 10:44:58 -0500
Received: from SENDER (sender-pc.legosoft.com.mx [192.168.20.70])
(authenticated bits=0)
by mail.legosoft.com.mx (8.13.7/8.13.7) with ESMTP id k77FiVlW027770
for <rberber@...>; Mon, 7 Aug 2006 10:44:31 -0500
(CDT)
Message-Id: <200608071544.k77FiVlW027770@...>
From: "Sender" <sender@...>
To: "=?iso-8859-1?Q?'Ren=E9_Berber'?=" <rberber@...>
Subject: RE: De vuelta
Date: Mon, 7 Aug 2006 10:44:32 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
[snip]

The extension does its test and says "Domain <legosoft.com.mx> does
not support SPF verification.

Let's see what dig says:

$ dig legosoft.com.mx txt

; <<>> DiG 9.3.2 <<>> legosoft.com.mx txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48890
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;legosoft.com.mx. IN TXT

;; ANSWER SECTION:
legosoft.com.mx. 86400 IN TXT "Legosoft, S.C."
legosoft.com.mx. 86400 IN TXT "v=spf1 mx ~all"
[snip]

So, how can I diagnose what went wrong with the extension?

Thanks.