Mailing List Archive

In <20040726132938.GW16052@dumbo.pobox.com> Meng Weng Wong <mengwong@dumbo.pobox.com> writes:

> On Mon, Jul 26, 2004 at 11:56:02AM +0000, Patrick Mackinlay wrote:

> | I am writing to you regarding your SPF perl module. I am using this module
> | in conjunction with postfix and it works fine. However there is a
> | problem with the trusted forwarders functionality. Some of the trusted rules
> | require a reverse DNS lookup on the clients IP address. As I am sure you know
> | many people do not publish PTR records for their hosts, this results in
> | the SPF lookup failing with a DNS error, resulting in the email being
> | deferred (450 temporary DNS error ....). Since the error is not really
> | temporary (i.e. the PTR record is not likely to appear!) then the email
> | is deferred until the peer decides to give up. Perhaps it would be wiser
> | for PTR DNS errors, whilst evaluating trusted forwarder rules, resulting in a
> | neutral SPF result. As it stands I have to turn of the trusted forwarder
> | functionality, since it ultimately means rejecting all email from hosts
> | without PTR records.


Hi Meng.

I'm not sure what exactly you want to do with this problem.

We first discussed the existance of this problem back around May
15-16. We have discussed it at least once since then. I have
repeatedly sent you patches to the SPF RFC to explicitly say that
implemenations must ignore DNS errors when using the %{p}
macro-variable or the ptr: mechanism, but you have never included
those changes to the RFC.

I guess I can only assume that you think these DNS errors should not
be ignored.



As discussed back in May, libspf2 ignores DNS errors. While
technically out of spec, I think it is the right thing to do.
(Actually, the fact that libspf2 still supports the %{p} macro is
technically out of spec of the latest RFC, but it is my understanding
that you are going to add that back in.)

So, one solution to Patrick's problem is to use libspf2 instead of
M:S:Q.

Another solution is to use a local policy of
"include:spfq.trusted-forwarder.org" and turn off the trusted option.
Note the "q" in "spfq", it stands for quick, and doesn't do the %{p}
macro. This alternate policy has been around for a very long time,
but I've never documented it.

So, another possible solution is that I could change the T-FWL to replace
the spf TXT record with what is now in spfq.


So, what do you want to do?


-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

wayne@midwestcs.com:
>As discussed back in May, libspf2 ignores DNS errors.

Hmm. Are you sure? I had to make a change to my spfmilter to
deal with this problem. Originally, when I got an SPF_RESULT_ERROR
I generated a 451 temporary failure. However, I noticed that
I was generating a lot of these 'temporary' failures for DNS errors
that never went away, so I changed the handling of SPF_RESULT_ERROR
to accept and mark the message, just like for all the other result
codes except SPF_RESULT_FAIL.

I.e., it looks to me like libspf2 does NOT ignore DNS errors, so
I made spfmilter ignore DNS errors instead.
---
Jef

Jef Poskanzer jef@acme.com http://www.acme.com/jef/

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

The specification says:

The "p" macro expands to the validated domain name of the SMTP
client. The validation procedure is described in section 4.6. If
there are no validated domain names, the word "unknown" is
substituted. If multiple validated domain names exist, the first one
returned in the PTR result is chosen.

So if an implementation does not substitue "unknown" when there is no
validated domain main, I consider it a bug.

Roger

-------
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 <002a01c473ac$fa192ea0$01030101@pamho.net> "Roger Moser" <rkd_spf@greenmail.ch> writes:

> The specification says:
>
> The "p" macro expands to the validated domain name of the SMTP
> client. The validation procedure is described in section 4.6. If
> there are no validated domain names, the word "unknown" is
> substituted. If multiple validated domain names exist, the first one
> returned in the PTR result is chosen.
>
> So if an implementation does not substitue "unknown" when there is no
> validated domain main, I consider it a bug.


Well, I happened to agree with your interpretation. The in-addr tree
is so full of errors, especially when dealing with IP addresses from
machines that aren't supposed to be MTAs that I didn't even consider
do anything else.

I think all of the SPF specs have been a little too vague in this
area. The idea that DNS SERVFAIL and timeouts should cause a
TempError (aka "error" in SPF-classic) seems to be based more on
mailing list and IRC discussions than on the spec. There are some
hints here and there, but nothing concrete.

The new MARID-protocol spec is slightly clearer on this subject, for
example section 3.2 "Results" says:

Results from error conditions:
None: no published data
TempError: transient error during DNS lookup or other processing
PermError: unrecoverable error during processing, such as an
error in the record format


I think this needs to be clarified.


-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 <200407270613.i6R6DXP7025730@gate.acme.com> Jef Poskanzer <jef@acme.com> writes:

> wayne@midwestcs.com:
>>As discussed back in May, libspf2 ignores DNS errors.
>
> I.e., it looks to me like libspf2 does NOT ignore DNS errors, so
> I made spfmilter ignore DNS errors instead.

libspf2 should only ignore DNS errors when the occur when processing
ptr: mechanisms and the %{p} macro-variable.


-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

>>>As discussed back in May, libspf2 ignores DNS errors.
>>
>> I.e., it looks to me like libspf2 does NOT ignore DNS errors, so
>> I made spfmilter ignore DNS errors instead.
>
>libspf2 should only ignore DNS errors when the occur when processing
>ptr: mechanisms and the %{p} macro-variable.

All right, but as I said it was returning lots of DNS errors that seemed
permanent, so I had to ignore them one level up.
---
Jef

Jef Poskanzer jef@acme.com http://www.acme.com/jef/

-------
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 <200407271607.i6RG7ar7056837@gate.acme.com> Jef Poskanzer <jef@acme.com> writes:

>>>>As discussed back in May, libspf2 ignores DNS errors.
>>>
>>> I.e., it looks to me like libspf2 does NOT ignore DNS errors, so
>>> I made spfmilter ignore DNS errors instead.
>>
>>libspf2 should only ignore DNS errors when the occur when processing
>>ptr: mechanisms and the %{p} macro-variable.
>
> All right, but as I said it was returning lots of DNS errors that seemed
> permanent, so I had to ignore them one level up.

Can you give some examples of these "permanent" DNS errors? It is my
understanding that most SPF implementations will deal with SERVFAIL
the same way on most mechanisms other than maybe ptr: and %{d}, so
this has a far wider impact than just libspf2.


thanks

-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

>Can you give some examples of these "permanent" DNS errors? It is my

Well, let's see. In Monday's log file I have:

65209 fail
61052 softfail
16353 pass
3326 neutral
447 error
426 unknown

I extracted just the errors and unknowns and put them here:
http://www.acme.com/jef/tmp/spf_error_unknown.txt

Looks like there are some pretty "creative" SPF records out there!
---
Jef

Jef Poskanzer jef@acme.com http://www.acme.com/jef/

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

If we support the submitter mail attribute do we also have to support the
sender header. Is that correct ?


Thanks

Adam Rogas

-----Original Message-----
From: owner-spf-devel@v2.listbox.com [mailto:owner-spf-devel@v2.listbox.com]
On Behalf Of wayne
Sent: Tuesday, July 27, 2004 7:02 AM
To: SPF Development
Subject: Re: [spf-devel] ignore errors during trusted-forwarder lookup?

In <002a01c473ac$fa192ea0$01030101@pamho.net> "Roger Moser"
<rkd_spf@greenmail.ch> writes:

> The specification says:
>
> The "p" macro expands to the validated domain name of the SMTP
> client. The validation procedure is described in section 4.6. If
> there are no validated domain names, the word "unknown" is
> substituted. If multiple validated domain names exist, the first one
> returned in the PTR result is chosen.
>
> So if an implementation does not substitue "unknown" when there is no
> validated domain main, I consider it a bug.


Well, I happened to agree with your interpretation. The in-addr tree is so
full of errors, especially when dealing with IP addresses from machines that
aren't supposed to be MTAs that I didn't even consider do anything else.

I think all of the SPF specs have been a little too vague in this area. The
idea that DNS SERVFAIL and timeouts should cause a TempError (aka "error" in
SPF-classic) seems to be based more on mailing list and IRC discussions than
on the spec. There are some hints here and there, but nothing concrete.

The new MARID-protocol spec is slightly clearer on this subject, for example
section 3.2 "Results" says:

Results from error conditions:
None: no published data
TempError: transient error during DNS lookup or other processing
PermError: unrecoverable error during processing, such as an
error in the record format


I think this needs to be clarified.


-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

On Tue, Jul 27, 2004 at 09:26:51AM -0700, Jef Poskanzer wrote:
| >Can you give some examples of these "permanent" DNS errors? It is my
|
| Well, let's see. In Monday's log file I have:
|
| 65209 fail
| 61052 softfail
| 16353 pass
| 3326 neutral
| 447 error
| 426 unknown
|
| I extracted just the errors and unknowns and put them here:
| http://www.acme.com/jef/tmp/spf_error_unknown.txt
|
| Looks like there are some pretty "creative" SPF records out there!

nah, most of those errors are because the ptr didn't return.

this is a pretty harmless issue all things considered since
most mail sites are requiring PTR records nowadays, but
wayne is right; the spec and Mail::SPF::Query need to change.

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

On Mon, 2004-07-26 at 22:33, wayne wrote:

> As discussed back in May, libspf2 ignores DNS errors. While
> technically out of spec, I think it is the right thing to do.
> (Actually, the fact that libspf2 still supports the %{p} macro is
> technically out of spec of the latest RFC, but it is my understanding
> that you are going to add that back in.)
>
> So, one solution to Patrick's problem is to use libspf2 instead of
> M:S:Q.
>
> Another solution is to use a local policy of
> "include:spfq.trusted-forwarder.org" and turn off the trusted option.
> Note the "q" in "spfq", it stands for quick, and doesn't do the %{p}
> macro. This alternate policy has been around for a very long time,
> but I've never documented it.
>
> So, another possible solution is that I could change the T-FWL to replace
> the spf TXT record with what is now in spfq.
>
>
> So, what do you want to do?

The only solution, is to fix the spec. Advocating the use of some
"feature" to get around a clearly in need of fix in the spec is to
invite trouble. Perhaps if you were to remove the focus from "everyone
use my library" to where it more appropriately belongs and aide in the
above change being put into place. Christ, has Microsoft's influence
been felt that deeply that already we're proposing "SPFUPDATE.COM"?

As for the purported stability of libspf-alt, I'm somewhat sceptical
since it seems every other week there is a "feature" either being pulled
in or out. I recall back, waaaay back when slashdot announced that our
spec was frozen.

Perhaps we could get back to putting it, or SOMETHING for us developers
to go on, BACK into the freezer so we can appropriately attain
stability.

I swear that's friendlier then it sounds, although it is getting rather
irritating given the number of specs whose filenames are symlinked to
newer versions of the spec, almost causing the level of confusion being
advocated by the "libConfusion" group over at midwestcs.

Cheers,

James

--
James Couzens,
Programmer
( ( (
((__)) __lib__ __SPF__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---

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=0x7A7C7DCF

-------
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 <1091102752.18979.7.camel@code3> James Couzens <jcouzens@6o4.ca> writes:

> On Mon, 2004-07-26 at 22:33, wayne wrote:
>
>> So, what do you want to do?
>
> The only solution, is to fix the spec. Advocating the use of some
> "feature" to get around a clearly in need of fix in the spec is to
> invite trouble. Perhaps if you were to remove the focus from "everyone
> use my library" to where it more appropriately belongs and aide in the
> above change being put into place.

Uh, James, two comments:

1) I suggested several different options, one of which kind of works
with the software that Patric already was using.

2) I have been trying to get Meng to fix the spec for many months
now. What have you done to try to improve the spec?



> As for the purported stability of libspf-alt, I'm somewhat sceptical
> since it seems every other week there is a "feature" either being pulled
> in or out. I recall back, waaaay back when slashdot announced that our
> spec was frozen.

Among other things, the IETF standardization process is causing
changes and Meng and Mark are also tweaking things. A changing spec
has nothing to do with libspf2 and libspf2 has not been adding or
deleting features every other week.


> Perhaps we could get back to putting it, or SOMETHING for us developers
> to go on, BACK into the freezer so we can appropriately attain
> stability.

That won't happen until after the IETF give final approval.


> I swear that's friendlier then it sounds, although it is getting rather
> irritating given the number of specs whose filenames are symlinked to
> newer versions of the spec, almost causing the level of confusion being
> advocated by the "libConfusion" group over at midwestcs.

It appears that the confusion is yours.


-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