#17 Solaris: problem with only "ptr" records in SPF data

[Fredrik Pettai]

sid-milter v0.2.9 (and earlier?) is currently rejecting
mail coming from a domain with only "ptr" records in
the spf data:

# dig -t TXT mail.dk

;; ANSWER SECTION:
mail.dk. 2072 IN TXT "v=spf1
ptr:mail.dk ptr:tele.dk -all"

From the sendmail log:

Nov 21 10:07:38 mx1 sendmail[29693]: [ID 801593
mail.info] jAL97aGQ029693: from=<reinsmark@mail.dk>,
size=2658, class=0, nrcpts=1,
msgid=<001801c5ee7b$b916e280$193a5953@webspeed.dk>,
proto=ESMTP, daemon=MTA-v4, relay=pfepb.post.tele.dk
[195.41.46.236]
Nov 21 10:07:38 mx1 sendmail[29693]: [ID 801593
mail.info] jAL97aGQ029693: Milter insert (1): header:
Authentication-Results: mx1.vattenfall.se
from=reinsmark@mail.dk; sender-id=fail (NotPermitted);
spf=fail (NotPermitted)

Re,
/P

[Fredrik Pettai]

Logged In: YES
user_id=370342

This seems to be a Solaris related problem.
both sid-milter and sid-check fails for this domain.

(sid-check was built with nh-res-init-0.2.9.patch and
nh-utility-0.2.9.patch)

[Fredrik Pettai]

Logged In: YES
user_id=370342

> I've also tried building sid-check without libar.
> Even thought i didn't have any compiler warnings, it
doesn't function very well:
>
> # sid-check -v 192.36.28.140 user@testmail.se
> sid-check for sid-milter version 0.2.9
> sm_marid_check_host_frame: ip=<192.36.28.140>,
domain=<testmail.se>, sender=<user@testmail.se> depth=[-1]
> Bus Error (core dumped)

Hmmm ... I tried this, and my sid-check built without libar
acts like yours built with libar:

saint# ./sid-check -v 192.36.28.142 test@testmail.se
sid-check for sid-milter version 0.2.9
sm_marid_check_host_frame: ip=<192.36.28.142>,
domain=<testmail.se>, sender=<test@testmail.se> depth=[-1]
Trying: <v=spf1 ptr:testmail.se -all>
spf=Fail (NotPermitted)
sm_marid_check_host_frame: ip=<192.36.28.142>,
domain=<testmail.se>, sender=<test@testmail.se> depth=[-1]
Trying: <v=spf1 ptr:testmail.se -all>
pra=Fail (NotPermitted)

[Anonymous]

Logged In: YES
user_id=1048957

Turned out to be a problem in constructing the PTR query.
For reasons I haven't quite figured out yet, the code I was
using to do so was failing to reverse the octet order, so
the wrong query was being sent.

Fixed for next release.

[Fredrik Pettai]

Logged In: YES
user_id=370342

Hi,

The CVS-patch diff that you sent me works fine.

/P

[Anonymous]

Logged In: YES
user_id=1048957

v0.2.10 released.