search

sdgathman / pyspf

Other
49 stars 26 forks source link

New release #14

Open orlitzky opened 5 years ago

orlitzky commented 5 years ago

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 commented 5 years ago

Oops, three years ago!

sdgathman commented 5 years ago

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 commented 5 years ago

Great, thanks for the fast response!

sdgathman commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 4 years ago

It's fixed in https://github.com/sdgathman/pyspf/commit/4744deeec4a2c10987aae72989d7137156ed4151

It'd be nice if we could release agian.

gpatel-fr commented 4 years ago

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.