Mailing List Archive

On Thu, 2004-07-08 at 04:28, Pavel Zavyalov wrote:
> Policy:
> "v=spf1 ip4:213.180.192.0/19 -exists:%{l}.%{ir}.yandex.spf-check.yandex.ru
> ?all"
>
> Request to spf-check.yandex.ru :
>
> -exists:tilliesvelyiram.32.108.65.222.yandex.spf-check.yandex.ru IN MX
>
> Software have 2 errors:
> Adds '-exists:' into macro expansion
> Ask MX instead of A
>
> Does anybody knows, what is it?

Well I have a couple ideas. Here is some output from the libSPF Query
Tool (you can obtain it as part of the libSPF library to aide in offline
or otherwise awkward testing).

root@code3 bin $ ./spfquery-shared -i 192.168.0.1 -s johan@yandex.ru -h
hello -v 6
DEBUGGING LEVEL IS: 6
ipv4: 192.168.0.1
sender: johan@yandex.ru
helo: hello

.. snip!

DNS_query :: Received packet size of 194 bytes which contains 1 answers.
DNS_query :: ANSWERS: 1
DNS_query :: QUESTIONS: 1
DNS_txt_answer :: Answer 1 has length 79. (79)
DNS_txt_answer :: Answer Data: (v=spf1 ip4:213.180.192.0/19
-exists:%{l}.%{ir}.yandex.spf-check.yandex.ru ?all ) len: 79

.. snip!

MACRO_expand :: Returning expanded macro:
(johan.1.0.168.192.yandex.spf-check.yandex.ru)
DNS_query :: Called with (johan.1.0.168.192.yandex.spf-check.yandex.ru)
and type: 1
DNS_query :: Received packet size of 100 bytes which contains 1 answers.
DNS_query :: ANSWERS: 1
DNS_query :: QUESTIONS: 1
UTIL_free :: Free address 0x804b6b8 by SPF_parse_policy on line 757
(main.c)
UTIL_free :: Free address 0x804b538 by SPF_parse_policy on line 860
(main.c)
UTIL_assoc_prefix :: (QID: 0) :: Entering function (3)
(-exists:%{l}.%{ir}.yandex.spf-check.yandex.ru)
UTIL_assoc_prefix :: (QID: 0) :: Stored SPF_H_FAIL (3) (3)

.. snip!

SPF_policy_main_rec :: (QID: 0) :: Return policy 3 on mech:
(-exists:%{l}.%{ir}.yandex.spf-check.yandex.ru) with outcome: (fail)
fail
policy result: (fail) from rule
(-exists:%{l}.%{ir}.yandex.spf-check.yandex.ru)

Thats how libSPF parses it with debug mode enabled.

Or I can pass:

james@code3 bin $ ./spfquery-shared -i 213.180.192.1 -s johan@yandex.ru
-h hello -v 1
DEBUGGING LEVEL IS: 1
ipv4: 213.180.192.1
sender: johan@yandex.ru
helo: hello
pass
policy result: (pass) from rule (ip4:213.180.192.0/19)

The long and the short of it, it looks like the parser you are using is
misbehaving? Is it an older version of a parser?

It appears to me that regardless of the possible parser problem, that
the rule makes little sense, give what exists is used for. "exists"
causes an A record to be looked up, and if its found, there is a match,
but if you are using '-' in front of it, if an A record is found
matching it, it will still fail, I don't see how this is desirable.

Cheers,

James

--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> Well I have a couple ideas. Here is some output from the libSPF Query
> Tool (you can obtain it as part of the libSPF library to aide
> in offline
> or otherwise awkward testing).


> DNS_query :: Called with
> (johan.1.0.168.192.yandex.spf-check.yandex.ru)
> and type: 1
> DNS_query :: Received packet size of 100 bytes which contains
> 1 answers.
> DNS_query :: ANSWERS: 1
> DNS_query :: QUESTIONS: 1

Your request was correct:

Jul 08 16:05:20.553 queries: client 24.207.XXX.XXX#53: query:
johan.1.0.168.192.yandex.spf-check.yandex.ru IN A

-- in my logs

But request from ns.mercury.net was incorrect:

Jul 08 15:27:31.787 queries: client 64.7.172.12#53: query:
-exists:iqmpxbw.95.106.127.221.yandex.spf-check.yandex.ru IN MX



>
> The long and the short of it, it looks like the parser you
> are using is
> misbehaving? Is it an older version of a parser?

I'm currently don't use parser. Somebody using and got a wrong result :(

>
> It appears to me that regardless of the possible parser problem, that
> the rule makes little sense, give what exists is used for. "exists"
> causes an A record to be looked up, and if its found, there
> is a match,
> but if you are using '-' in front of it, if an A record is found
> matching it, it will still fail, I don't see how this is desirable

That's OK.
I use spf-check.yandex.ru to reject fakes
In real life, e-mail from username@yandex.ru cannot come out from
213.180.192.0/19 and be rejected by spf-check.yandex.ru

I'm collecting statistic to choose between "+a -(reject check) ?all" and "+a
+(pass check) -all"

And, sorry, are you sure than after +ip4 match, -exits will be checked? I do
not see this activity in spf-check.yandex.ru log files.

Thank you,
Pavel
.
>
> Cheers,
>
> James
>
> --
> James Couzens,
> Programmer

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <1089289062.31231.26.camel@code3> James Couzens <jcouzens@6o4.ca> writes:

> On Thu, 2004-07-08 at 04:28, Pavel Zavyalov wrote:
>>
>> Does anybody knows, what is it?

No, I don't. Sorry. I take it a few are showing up in your logs. If
you are getting the IP address, you can probably track down the mail
admin from that and ask them directly.


> It appears to me that regardless of the possible parser problem, that
> the rule makes little sense, give what exists is used for. "exists"
> causes an A record to be looked up, and if its found, there is a match,
> but if you are using '-' in front of it, if an A record is found
> matching it, it will still fail, I don't see how this is desirable.

Yeah, I mentioned to Meng and Markl recently on the #SPF IRC channel,
there are times when it would be real handy to have a not-exists:
mechanism. This is probably one such case.

On the other hand, Pavel may be using the exists: mechanism just for
tracking purposes, it makes little difference what the SPF result
prefix on the exists: mechanism does.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> In <1089289062.31231.26.camel@code3> James Couzens
> <jcouzens@6o4.ca> writes:
>
> > On Thu, 2004-07-08 at 04:28, Pavel Zavyalov wrote:
> >>
> >> Does anybody knows, what is it?
>
> No, I don't. Sorry. I take it a few are showing up in your logs. If
> you are getting the IP address, you can probably track down the mail
> admin from that and ask them directly.

I did it. No answer. But admin of cashing/forwarding nameserver of large
network may not know what client made this request.

>
>
> > It appears to me that regardless of the possible parser
> problem, that
> > the rule makes little sense, give what exists is used for. "exists"
> > causes an A record to be looked up, and if its found, there
> is a match,
> > but if you are using '-' in front of it, if an A record is found
> > matching it, it will still fail, I don't see how this is desirable.
>
> Yeah, I mentioned to Meng and Markl recently on the #SPF IRC channel,
> there are times when it would be real handy to have a not-exists:
> mechanism. This is probably one such case.

Yes. We check existens of username and check senders ip in our blacklists


> On the other hand, Pavel may be using the exists: mechanism just for
> tracking purposes, it makes little difference what the SPF result
> prefix on the exists: mechanism does.

Tracking is good thing, but 'exists' answer (FAIL) come out in 90% cases ;)

Thank You,
Pavel

>
> -wayne
>
> -------
> To unsubscribe, change your address, or temporarily
> deactivate your subscription,
> please go to
> http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com