--- In thunderbird-spf@yahoogroups.com, Joshua Tauberer <jt@...> wrote:
>
> John L. Galt wrote:
> > But, now, I have a new problem. Same router, same computer, but new
> > hardware
>
> Don't bang your head about it --- it's a problem on my end. I'm in the
> process of moving to a new web server, and occams.info points to the
new
> server, but it's not running DNS on port 9053 yet. You could use
> instead:  govtrack.us:9053

Will do.  Thanks for the info!  BTW, nice work on the govtrack site!

>
> > Since it worked before, and since the router itself has not changed at
> > all, could this possibly be a problem related to Windows Live OneCare
> > and it's native firewall? If so, is there a way to configure a FW in
> > general that allows a pass-through on port 9053? Would I configure
> > this to be open for Tb, or is there a separate executable I need
to allow?
>
> I hope the problem *is* on my end because I have no idea about any
of that.
>

I'll post back here and let you know.  Also, is the govtrack.us going
ot be permanent?  If not, other than monitoring this group discussion,
when will we know when ot change it back to occams.info?  When (I
assume) the govtrack stops working?

> --
> - Josh Tauberer
>
> http://razor.occams.info
>
> "Yields falsehood when preceded by its quotation!  Yields
> falsehood when preceded by its quotation!" Achilles to
> Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)
>

John L. Galt wrote:
> But, now, I have a new problem. Same router, same computer, but new
> hardware

Don't bang your head about it --- it's a problem on my end. I'm in the
process of moving to a new web server, and occams.info points to the new
server, but it's not running DNS on port 9053 yet. You could use
instead:  govtrack.us:9053

> Since it worked before, and since the router itself has not changed at
> all, could this possibly be a problem related to Windows Live OneCare
> and it's native firewall? If so, is there a way to configure a FW in
> general that allows a pass-through on port 9053? Would I configure
> this to be open for Tb, or is there a separate executable I need to allow?

I hope the problem *is* on my end because I have no idea about any of that.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

It somehow started working, later on, using occams.info:9053.
However, I think it had to do with a Tb restart, as it did not seem to
try to use any changes without a restart.

But, now, I have a new problem.  Same router, same computer, but new
hardware - I replaced my mobo and it has an onboard Gigabit NIC, so I
had to re-install Vista from scratch - and I have just refinished
migrating Tb over to it so I did not lose my mail and stuff.  All
extensions also work fine, but I am back to the same problem - SPF has
stopped working.

For the record, I am using Tb 2.0.0.6 and tete009's optimized SSE2
build, version 2.0.0.6 as well - to no avail.  Neither seems to allow
SPF verification.  If I leave the field blank, it defaults to my
router's IP address, but if I try to use that, or my ISP's DNS server,
or even the occams.info:9053, with the required restarts again, I
still get nothing but errors.

Since it worked before, and since the router itself has not changed at
all, could this possibly be a problem related to Windows Live OneCare
and it's native firewall?  If so, is there a way to configure a FW in
general that allows a pass-through on port 9053?  Would I configure
this to be open for Tb, or is there a separate executable I need to allow?

Thanks.

--- In thunderbird-spf@yahoogroups.com, "John L. Galt" <johnlgalt@...>
wrote:
>
> Hi, Josh, I have been using your SVE extension for a long time, but
> after I upgraded to a more recent version of TB and upgraded your SVE
> extension as well, it has stopped working for *all* my domains - and
> the router and machine are the exact same and configured (AFAIK) the
same.
>
> I have a DLink DGL4300 (gamerlounge original, that allows gigabit
> ethernet) and a Netgear Gigabit ethernet card, but for some reason all
> attempts at verifying SPF information fails.
>
> I read through the thread regarding the "behind ADSL router" but asI
> mentioned this used to work for me before, and I still use the exact
> same profile as I have for nearly 2 years, so I am not sure where to
> start for troubleshooting this issue.
>
> The error message is as follows:
>
> "Error: Could not get SPF info: Error connecting to DNS server
> 68.1.18.237" - that server is being told by my ISP to my router as I
> have an internal DHCP with DNS server on the router to the external
> world, and I am using Cox.net as my ISP.
>
> I tried leaving the field blank when I first encountered the error,
> and tried substituting the actual DNS Server's IP as well as the IP of
> my router - and none have worked thus far.
>
> Can you (or someone familiar with a similar setup) please help me
> troubleshoot this issue?
>
> TIA
>

Does anyone know about the DNS whitelist Sender Score Certified?

http://www.bondedsender.org/senderscorecertified/

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

I'm new to Linux but am very happy with Xubuntu (it's fast,
configurable and simple).

There's a glitch, though... The mail links in Firefox won't open a
Thunderbird composer window (TB doesn't open at all).

I've tried the Preferred Applications dialog box and have rebooted,
but no luck. Also, I am an administrator on the account I'm using.

I don't want to try another email client yet, I'd prefer not to load
up the opsys any more than necessary. Does anyone here know of a fix
or solution so that I can keep TB as my email client and make it work
with FF?

Thank you,

William Gray
wbgray01@...

Josef Schneider wrote:
> Am 28.04.2007 01:40 schrieb jase_the_kiwi:
>  > I do have a suggestion though for this extension. Why not set up some
>  > kind of deletion or junk folder for those recieved from known
>  > spammers? That way you won't have to see them in your inbox :)
>  >
>
> It would be great, if these would be marked as spam, so that the
> internal spamfilter also learns from them!
> THis way you wouldn't have them in your inbox and your spamfilter would
> also become better!

Lots of things would be great. :)

I'm not necessarily opposed to the idea, but I think it would be best
implemented in Thunderbird's own spam controls, not in my extension.
And, since I don't have much time to spend on the extension (i.e.
basically none), adding spam features, as opposed to better phishing
protection, is an extremely low priority for me.

Thanks for the feedback, though.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

Am 28.04.2007 01:40 schrieb jase_the_kiwi:
>
> I do have a suggestion though for this extension. Why not set up some
> kind of deletion or junk folder for those recieved from known
> spammers? That way you won't have to see them in your inbox :)
>







It would be great, if these would be marked as spam, so that the
internal spamfilter also learns from them!
THis way you wouldn't have them in your inbox and your spamfilter would
also become better!


>
>



___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

I am starting to implement SPF records at my company now and wondered
if there was an extension for thunderbird.  A quick search brought up
this plugin, I installed it and it works well!

I do have a suggestion though for this extension.  Why not set up some
kind of deletion or junk folder for those recieved from known
spammers?  That way you won't have to see them in your inbox :)

The Sender Verification Extension add-on has been updated on the website
to be compatible with Thunderbird 2.0.

http://razor.occams.info/code/spf

The update is also in the hopper at addons.mozilla.org (as of today) so
it'll auto-update eventually once they approve the update.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

enduro672003 wrote:

I've the same problem.
Does now exist a workaround?

The current new version at http://razor.occams.info/code/spf will let
you set the DNS server option to "occams.info:9053". It's my hope that
that will serve as a work-around for the router issues.
Let me know if you try it and it works.

enduro672003 wrote:
> I've the same problem.
> Does now exist a workaround?

The current new version at http://razor.occams.info/code/spf will let
you set the DNS server option to "occams.info:9053".  It's my hope that
that will serve as a work-around for the router issues.

Let me know if you try it and it works.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

Hi Ralf,


I am sorry to say I didn't find one.  I think it is the router blocking
specific queries on those protocol's for TCP in my case.


Scott

enduro672003 wrote:
> Hi,
>
> I've the same problem.
>
> Does now exist a workaround?
>
> bye
>
> Ralf
>

Hi,

I've the same problem.

Does now exist a workaround?

bye

Ralf

--- In thunderbird-spf@yahoogroups.com, Joshua Tauberer <jt@...> wrote:
>
> Scott Price wrote:
> > I believe I'd read somewhere before that it wasn't possible to utilise
> > the UDP com's through javascript, I personally am not familiar with
> > attempting UDP through that scripting, but I believe I read that
was why
> > the SPF Thunderbird Extension had to have TCP access to the DNS it was
> > trying to resolve against.
>
> That's right.  Thunderbird provides extensions with the ability to make
> TCP connections to servers but not UDP connection, at least as far as I
> could figure out at the time I was programming that.
>
> --
> - Josh Tauberer
>
> http://razor.occams.info
>
> "Yields falsehood when preceded by its quotation!  Yields
> falsehood when preceded by its quotation!" Achilles to
> Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)
>

Redd Sam wrote:
> I really like the Sender Verification Extension, and I'd really like
> the following two features:

Hi.  I appreciate the feedback.  I don't have much time to work on the
extension these days so development on new features is pretty much on
hold indefinitely (unless someone else wants to take a stab at it).

But, my comments on your suggestions:

> * Have an option to do SPF and DK checks on new email as it arrives
> (as oppose to when it's read). I suggest this for several reasons:
> [1] Speed. When scanning through my emails it takes a second or so to
> do the check and it'd be nice to be instantaneous.
> [2] It would alleviate the 'Message is too old to verify sender.' issue.
> [3] It'd allow me to read emails offline, knowing I've still had the
> SVE check.
> The details of the SVE check for SPF and DK could be stored in the
> header of the email (similar to how TBird uses the X-Mozilla-Status
> header).

I think this is a good idea, although I don't know at all how to go
about programming it or if it's even possible in an extension.

> * Having done said check on new email, allow some kind of integration
> with the Junk Mail filters. Mail which fails SPF and/or DK could be
> auto-junked. Conversely email which completely passes SPF and/or DK
> *could* (say make an option available) be exempt from other junk mail
> rules and thus protected from accidental automated junking.

This is something that seems like a good idea but in practice I am sure
it would be just a nuisance.  From the email I receive, I would say that
there is a fairly low correlation between SPF status and junk status.
Most legitimate domains don't support SPF, and conversely many spam
senders (I suppose not from botnets) send mail from domains that would
pass an SPF check (using the implicit/fall-back rules).

> * May I also suggest a traffic light system as well to make SVE
> idiot-proof? Put the traffic-light next to the current Sender
> Verification message. Where a clear SPF or DK violation has occurred,
> then a big red blog should be used. Where DK is verified (or if DK is
> turned off, if SPF is verified) a big green blob. Where DK is
> non-existant, or the email too old, then a bright amber blob should be
> shown.

Yeah, I like the idea.  It's a little tricky to reduce the messages to a
single color, but it's something I may do in the future.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

I really like the Sender Verification Extension, and I'd really like
the following two features:

* Have an option to do SPF and DK checks on new email as it arrives
(as oppose to when it's read). I suggest this for several reasons:
[1] Speed. When scanning through my emails it takes a second or so to
do the check and it'd be nice to be instantaneous.
[2] It would alleviate the 'Message is too old to verify sender.' issue.
[3] It'd allow me to read emails offline, knowing I've still had the
SVE check.
The details of the SVE check for SPF and DK could be stored in the
header of the email (similar to how TBird uses the X-Mozilla-Status
header).

* Having done said check on new email, allow some kind of integration
with the Junk Mail filters. Mail which fails SPF and/or DK could be
auto-junked. Conversely email which completely passes SPF and/or DK
*could* (say make an option available) be exempt from other junk mail
rules and thus protected from accidental automated junking.


* May I also suggest a traffic light system as well to make SVE
idiot-proof? Put the traffic-light next to the current Sender
Verification message. Where a clear SPF or DK violation has occurred,
then a big red blog should be used. Where DK is verified (or if DK is
turned off, if SPF is verified) a big green blob. Where DK is
non-existant, or the email too old, then a bright amber blob should be
shown.


Just my thrupence...

Many Thanks,
Sam

On Sun, 04 Feb 2007 14:16:38 -0000 "lp_user_2004" <groups@...>
wrote:
>I was thinking that as every OS this will run on has a very standard
>resolver, why not use that?
>
>Or if that is not possible, why not look in /etc/resolv.conf to see
>what is configured at the moment as DNS server.
>
OS independent name server discovery is actually somewhat complex as
Windows does it completely differently.  Even within the Unix like would
there are some differences.

If you're curious what it takes to do this, you can look at Python DNS on
sourceforge.net.  It has code that does this for both Windows and Unix like
operating systems.

Scott K

lp_user_2004 wrote:
> I was thinking that as every OS this will run on has a very standard
> resolver, why not use that?

Thunderbird doesn't provide a way for extensions to make DNS queries,
afaik.  Notably, the main point isn't to resolve an address but to get
the SPF TXT record on a domain.

> Or if that is not possible, why not look in /etc/resolv.conf to see
> what is configured at the moment as DNS server.

It does, these days.

> Shows corrupted hashtable when I try to insall. Probably something I
> do wrong?

I'm not sure what that means.  It works for me.  Anyone else have problems?

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

Shows corrupted hashtable when I try to insall. Probably something I
do wrong?

--- In thunderbird-spf@yahoogroups.com, Joshua Tauberer <jt@...> wrote:
>
> Hi all,
>
> Version 0.82 of the Sender Verification Extension is now posted at
> http://razor.occams.info/code/spf/.
>
> This version has two changes:
>
>    1) It adds French localization (thanks to Eric Leu!)
>
>    2) It allows the DNS server option to specify a hostname and port.
>       I've set up my server to respond to TCP DNS queries on an
>       alternate port that routers should not interfere with, and so
>       this should provide a work-around for the problem that lots of
>       people have experienced with routers.
>
>       Use Tools | Extensions | Preferences to set the DNS server
>       to  occams.info:9053  if you experience TCP timeout issues.
>
> Comments welcome.  If I don't get any feedback, I'll push the update to
> addons.mozilla.org next week.
>
> --
> - Josh Tauberer
>
> http://razor.occams.info
>
> "Yields falsehood when preceded by its quotation!  Yields
> falsehood when preceded by its quotation!" Achilles to
> Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)
>

I was thinking that as every OS this will run on has a very standard
resolver, why not use that?

Or if that is not possible, why not look in /etc/resolv.conf to see
what is configured at the moment as DNS server.

That might be the easiest and best guess as that will change with
changing netorks.


--- In thunderbird-spf@yahoogroups.com, Joshua Tauberer <jt@...> wrote:
>
> Josef Schneider wrote:
> > It did find my DNS-Server. After I changed the DNS-Server, this
happened:
>
> Okay, there was a bug doing it that way, but in any case, using a root
> server and recursively finding the DNS information won't work because in
> any case kalt-gaming.at's nameservers don't response to TCP DNS
> requests, which is the only way Thunderbird can connect to a server
> (versus UDP).
>
> But, it looks probably like your ISP's DNS server also doesn't respond
> to DNS queries via TCP (which seems to be unusual for an ISP), and that
> really does prevent the extension from working at all.
>
> So, I'm attaching an updated extension.  It fixes a problem so that
> specifying J.ROOT-SERVERS.NET will actually work properly.  In your
> case, you need to specify this (or another public name server) because
> the extension won't work with your ISP's DNS server.  The downside is
> that any DNS server that the extension needs to contact for SPF info
> that doesn't response to DNS on TCP (which is common) won't be able to
> be contacted.
>
> The update also has better error messages for problems, so you can try
> using your ISP's name server again (leave the preference blank to have
> it autodetect again) to make sure that the problem was that it doesn't
> accept TCP connections.
>
> Unfortunately, I guess there's no good solution, in your case (ahm...
> besides submitting a patch to Thunderbird to allow UDP socket
connections.)
>
> --
> - Joshua Tauberer
>
> http://razor.occams.info
>
> "Unfortunately, we're having this discussion. It's too bad,
> because guess who listens to the discussion: the enemy."
>

Hi all,

Version 0.82 of the Sender Verification Extension is now posted at
http://razor.occams.info/code/spf/.

This version has two changes:

    1) It adds French localization (thanks to Eric Leu!)

    2) It allows the DNS server option to specify a hostname and port.
       I've set up my server to respond to TCP DNS queries on an
       alternate port that routers should not interfere with, and so
       this should provide a work-around for the problem that lots of
       people have experienced with routers.

       Use Tools | Extensions | Preferences to set the DNS server
       to  occams.info:9053  if you experience TCP timeout issues.

Comments welcome.  If I don't get any feedback, I'll push the update to
addons.mozilla.org next week.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

--- In thunderbird-spf@yahoogroups.com, Joshua Tauberer <jt@...>
wrote:
>
> j_j_chin wrote:
> > Why is it that this properly formatted header "could not be
> > understood":
>
> Afaik, there's not really such a thing as a properly formatted
Received
> header.  Different mail transfer programs insert Received headers
that
> look different in all sorts of ways, and the extension uses five
> different patterns for extracting the IP address for use with SPF.
> (Actually, I probably do it much too precisely, but that's another
story.)
>
> > Can you next release be made to read non-Unix-like (yes still
RFC-
> > compliant) Received headers properly? Thanks.
>
> Try out the update on the website now
> (http://razor.occams.info/code/spf) -- let me know if it doesn't
solve
> the problem.
>
> --
> - Josh Tauberer
>
> http://razor.occams.info
>
> "Yields falsehood when preceded by its quotation!  Yields
> falsehood when preceded by its quotation!" Achilles to
> Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)
>

Sorry the current version 0.8.1 still has the same exact problem.
I've been searching the web and cannot find any solution.  Thanks.

j_j_chin wrote:
> We have inbound filter servers in front of all of our mailbox
> servers. How come this filter seems to say that all of mail is
> coming from our internal servers?
>
> If we do not list our inbound filter server IPs, then every message
> fails verification. Why?

That sounds like the message that comes up when the extension doesn't
recognize the particular format of the Received: header that your MTA is
inserting into each message.  Could you send me (on or off list) the
Received headers of a message that you have trouble with?  (Feel free to
wipe out people's email addresses --- esp. if you send a reply on-list
--- and IP addresses if you want.)

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

--- In thunderbird-spf@yahoogroups.com, Joshua Tauberer
<tauberer@...> wrote:
>
> Hey all,
>
> I've pushed a new version of the Sender Verification Extension.
Version
> 0.77 now supports CIDR notation in the internal network servers
list,
> there is a new option to display verification status in the status
bar
> rather than up top, and some tiny things were fixed.
>
> It's posted here: http://taubz.for.net/code/spf/
> And it's in the queue on the Mozilla add-ons site to be posted
there.
>
> If there were any open (and fixable) issues I've forgotten, just
remind me.
>
> --
> - Joshua Tauberer
>
> http://taubz.for.net
>
> "Unfortunately, we're having this discussion. It's too bad,
> because guess who listens to the discussion: the enemy."
>

We have inbound filter servers in front of all of our mailbox
servers.  How come this filter seems to say that all of mail is
coming from our internal servers?

If we do not list our inbound filter server IPs, then every message
fails verification.  Why?

Hi, Josh, I have been using your SVE extension for a long time, but
after I upgraded to a more recent version of TB and upgraded your SVE
extension as well, it has stopped working for *all* my domains - and
the router and machine are the exact same and configured (AFAIK) the same.

I have a DLink DGL4300 (gamerlounge original, that allows gigabit
ethernet) and a Netgear Gigabit ethernet card, but for some reason all
attempts at verifying SPF information fails.

I read through the thread regarding the "behind ADSL router" but asI
mentioned this used to work for me before, and I still use the exact
same profile as I have for nearly 2 years, so I am not sure where to
start for troubleshooting this issue.

The error message is as follows:

"Error: Could not get SPF info: Error connecting to DNS server
68.1.18.237" - that server is being told by my ISP to my router as I
have an internal DHCP with DNS server on the router to the external
world, and I am using Cox.net as my ISP.

I tried leaving the field blank when I first encountered the error,
and tried substituting the actual DNS Server's IP as well as the IP of
my router - and none have worked thus far.

Can you (or someone familiar with a similar setup) please help me
troubleshoot this issue?

TIA

On Friday 05 January 2007 08:01, Joshua Tauberer wrote:
> Scott Price wrote:
> > I believe I'd read somewhere before that it wasn't possible to utilise
> > the UDP com's through javascript, I personally am not familiar with
> > attempting UDP through that scripting, but I believe I read that was why
> > the SPF Thunderbird Extension had to have TCP access to the DNS it was
> > trying to resolve against.
>
> That's right.  Thunderbird provides extensions with the ability to make
> TCP connections to servers but not UDP connection, at least as far as I
> could figure out at the time I was programming that.

Ah, then I think that explains it.  You just do TCP and his NAT box doesn't
support it.

If you could figure out the UDP end of it, that would be a good thing.  I
don't think this is a precisely rare condition (DNS over TCP not supported).

Scott K

Scott Price wrote:
> I believe I'd read somewhere before that it wasn't possible to utilise
> the UDP com's through javascript, I personally am not familiar with
> attempting UDP through that scripting, but I believe I read that was why
> the SPF Thunderbird Extension had to have TCP access to the DNS it was
> trying to resolve against.

That's right.  Thunderbird provides extensions with the ability to make
TCP connections to servers but not UDP connection, at least as far as I
could figure out at the time I was programming that.

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

Hi Scott :)


I believe I'd read somewhere before that it wasn't possible to utilise
the UDP com's through javascript, I personally am not familiar with
attempting UDP through that scripting, but I believe I read that was why
the SPF Thunderbird Extension had to have TCP access to the DNS it was
trying to resolve against.

I hope Josh will correct me if I misunderstood what I was reading, or if
that is just plain incorrect.


Kind regards,


Scott :)


Scott Kitterman wrote:
> If you are behind a typical consumer NAT router, DHCP gives the router as the
> DNS address.  The router will then forward DNS requests to the actual DNS
> server.  In any case the request has to be routed through the router even if
> the local client has the true DNS server entered.  This is not at all
> unusual.
>
> What is unusual about this case is an SPF record requiring TCP.  That's why I
> asked the OP for the domain name.
>
> DNS was for a long time considered a UDP protocol and while it could, in
> theory, use TCP, it was not well supported.  I understand that many firewalls
> filter TCP DNS requests by default on the assumption that they are all
> spurious.  TCP is a lot heavier than UDP.
>
> This is why RFC 4408 cautions against SPF records that will cause TCP to be
> used.
>
> Scott K
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

On Thursday 04 January 2007 13:26, Joshua Tauberer wrote:
> Scott Kitterman wrote:
> > Also, for Joshua, I think that you should look there too. It says,
> > "Records that are too long to fit in a single UDP packet MAY be silently
> > ignored by SPF clients." I think if you get a TCP failure on a record
> > lookup, the best thing for your plugin to do is to proceed as if there is
> > no SPF record at all.
>
> That's a good idea, to fall back to "a mx" or whatever it normally does
> when there's no SPF record.  Although, I'm not sure whether the
> extension will be able to resolve the sender's domain name in the first
> place if it can't get the TXT record?
>
> And, why would a router be filtering DNS TCP traffic?
>
> Also, the fact that the error message reports 192.168.0.1 as refusing
> the connection --- which is not the DNS server as configured -- still
> has me confused.  Either the extension is ignoring the DNS server
> configuration or it's resolving the DNS recursively (which is OK) and is
> somehow being directed that the router is the authorative nameserver for
> the domain (which I presume is not the case).

If you are behind a typical consumer NAT router, DHCP gives the router as the
DNS address.  The router will then forward DNS requests to the actual DNS
server.  In any case the request has to be routed through the router even if
the local client has the true DNS server entered.  This is not at all
unusual.

What is unusual about this case is an SPF record requiring TCP.  That's why I
asked the OP for the domain name.

DNS was for a long time considered a UDP protocol and while it could, in
theory, use TCP, it was not well supported.  I understand that many firewalls
filter TCP DNS requests by default on the assumption that they are all
spurious.  TCP is a lot heavier than UDP.

This is why RFC 4408 cautions against SPF records that will cause TCP to be
used.

Scott K

Scott Kitterman wrote:
> Also, for Joshua, I think that you should look there too. It says, "Records
> that are too long to fit in a single UDP packet MAY be silently ignored by
> SPF clients." I think if you get a TCP failure on a record lookup, the best
> thing for your plugin to do is to proceed as if there is no SPF record at
> all.

That's a good idea, to fall back to "a mx" or whatever it normally does
when there's no SPF record.  Although, I'm not sure whether the
extension will be able to resolve the sender's domain name in the first
place if it can't get the TXT record?

And, why would a router be filtering DNS TCP traffic?

Also, the fact that the error message reports 192.168.0.1 as refusing
the connection --- which is not the DNS server as configured -- still
has me confused.  Either the extension is ignoring the DNS server
configuration or it's resolving the DNS recursively (which is OK) and is
somehow being directed that the router is the authorative nameserver for
the domain (which I presume is not the case).

--
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Gödel, Escher, Bach" by Douglas Hofstadter)

You might want to get in touch with the domain owner (or your contact there)
if it's someone you have regular contact with.  Publishing an SPF record that
requires TCP is not a good practice.

While not prohibited by the SPF RFC, the practice is discouraged:

http://www.openspf.org/RFC_4408#rsize

Also, for Joshua, I think that you should look there too.  It says, "Records
that are too long to fit in a single UDP packet MAY be silently ignored by
SPF clients."  I think if you get a TCP failure on a record lookup, the best
thing for your plugin to do is to proceed as if there is no SPF record at
all.

Scott K

On Wednesday 03 January 2007 09:22, Scott Price wrote:
>  Thank you for the response Scott,
>
>
> I think you are spot-on there, it's the router that seems to suggest it
> can support TCP but actually doesn't do other then UDP.
>
> I don't think it's a fault of the SPF at all, just sadly this router
> won't allow it at all, even after investigating further, it just appears
> that the router will not, flatly, allow TCP DNS queries.
>
> Ohh well, was a nice thought.  Nevermind, but thank you for writing the
> mod folks, was nice to see.  :)
>
>
> Scott :)
>
> Scott Kitterman wrote:
> > On Wednesday 03 January 2007 06:24, Scott Price wrote:
> >> Could not get SPF info: DNS server 192.168.0.1 refused a TCP connection.
> >
> > What is the domain in question?
> >
> > It looks to me like they probably have a long SPF record that won't fit
> > in a UDP packet and your routers doesn't support DNS over TCP (this is
> > not rare).
> >
> > I'll take a look at the record and see if it's valid.
> >
> > Scott K