Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New release #14

Open
orlitzky opened this issue Apr 7, 2019 · 14 comments
Open

New release #14

orlitzky opened this issue Apr 7, 2019 · 14 comments

Comments

@orlitzky
Copy link

orlitzky commented Apr 7, 2019

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
Copy link
Author

orlitzky commented Apr 7, 2019

Oops, three years ago!

@sdgathman
Copy link
Owner

sdgathman commented Apr 9, 2019

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
Copy link
Author

orlitzky commented Apr 9, 2019

Great, thanks for the fast response!

@sdgathman
Copy link
Owner

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

$ ./spf.py  1.2.3.4 [email protected] 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
Copy link

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
Copy link
Owner

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
Copy link

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
Copy link

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
Copy link
Owner

sdgathman commented Jun 4, 2019 via email

@gpatel-fr
Copy link

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
Copy link

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
Copy link
Owner

sdgathman commented Jul 5, 2019

@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
Copy link
Collaborator

It's fixed in 4744dee

It'd be nice if we could release agian.

@gpatel-fr
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants