New release

[orlitzky]

Last night our SPF daemon crashed a few hundred times because of the invalid ip4 entry (note the \010) in the following record:

$ dig +short kruisecloud.com txt
"v=spf1 +a +mx +ip4:79.124.76.140 +ip4:107.175.172.4 +ip4:107.175.172.41\010 +ip4:107.174.15.33 +ip4:107.174.15.34 +ip4:62.108.40.57 +ip4:62.108.40.58 ~all"

Scott Kitterman fixed this bug two years ago, but there hasn't been a release since =)

It'd make everything a lot easier if there was a new version we could just push out, rather than trying to patch over top of the distro package.

[orlitzky]

Oops, three years ago!

[sdgathman]

I tagged pyspf-2.0.13pre1 (note switch to '.' separators with the move to github. I'll deploy and fix bugs before a full release. Much obliged if you can help with that.

[orlitzky]

Great, thanks for the fast response!

[sdgathman]

Oh, and Scott's fix did seem to have made it to the repo:

$ ./spf.py  1.2.3.4 foo@kruisecloud.com mail.kruisecloud.com
result: ('permerror', 550, "SPF Permanent Error: '107.175.172.41\\n' does not appear to be an IPv4 or IPv6 network") None

[gpatel-fr]

Given the lack of an usable pypi release since, err, 2014, I have switched to github version ("2.1") a few weeks ago with no adverse effect.

[sdgathman]

Given the lack of an usable pypi release since, err, 2014, I have switched to github version ("2.1") a few weeks ago with no adverse effect.

2.1 is unstable - see the README. You want the latest 2.0.x version

[gpatel-fr]

all right, I have selected the 2.0.13.3 tag.about 10 days ago. Since then no problem in SPF handling either.

[gpatel-fr]

Well, I take back the preceding comment.
Receiving a mail from python.org crashed the spf handling with

def DNSLookup_pydns(name, qtype, tcpfallback=True, timeout=30):

try:
    req = DNS.DnsRequest(name, qtype=qtype, timeout=timeout)
    resp = req.req()
    #resp.show()
    # key k: ('wayforward.net', 'A'), value v
    # FIXME: pydns returns AAAA RR as 16 byte binary string, but
    # A RR as dotted quad.  For consistency, this driver should
    # return both as binary string.
    #
    if resp.header['tc'] == True:
        if strict > 1:

--> strict is of course undefined at this point. It's only defined as a global variable if main is run.

This problem don't exist with current github (2.1)

[sdgathman]

On Tue, 4 Jun 2019, gpatel-fr wrote: try: req = DNS.DnsRequest(name, qtype=qtype, timeout=timeout) resp = req.req() #resp.show() # key k: ('wayforward.net', 'A'), value v # FIXME: pydns returns AAAA RR as 16 byte binary string, but # A RR as dotted quad. For consistency, this driver should # return both as binary string. # if resp.header['tc'] == True: if strict > 1: --> strict is of course undefined at this point. It's only defined as a global variable if main is run. This problem don't exist with current github (2.1)

github (2.1) (in master or pyspf-2.1 branch) is not a maintained branch. See the README. It is an artifact of cvs2git that has not been fixed yet. git doesn't seem to want to rename master branch - see issue#11.

…

-- Stuart D. Gathman <stuart@gathman.org> "Confutatis maledictis, flamis acribus addictis" - background song for a Microsoft sponsored "Where do you want to go from here?" commercial.

[gpatel-fr]

The point is that the stable branch has a rather horrid bug that makes it unusable. So people should stay away of it in its current state.
I will comment also on issue#11

[puittenbroek]

There is a (wrongly) tagged/named? version on pypi '2.0.12t'. Running 'pip install pyspf --upgrade' does not install this version. It says 'already up-to-date'.

[sdgathman]

@gpatel-fr

--> strict is of course undefined at this point. It's only defined as a global variable if main is run.

This problem don't exist with current github (2.1)

The normal API entry point is spf.query(), which defines strict. What entry point are you using?

[kitterma]

It's fixed in 4744dee

It'd be nice if we could release agian.

[gpatel-fr]

Thanks, @kitterma. I installed it on my server and I even subscribed to a python mailing list to get a mail from python.org (a domain that has quite a long list of TXT records) and it worked all right.