Mailing List Archive

On Tue, 30 Mar 2004, Roger Moser wrote:

> I have now finished (except the cache) and tested my implementation of SPF
> for Windows. You can download the C source at www.pamho.net/source.

It would help if that page contained a 2-liner introduction to SPF (Meng,
is there an authorised version?) and a link to http://spf.pobox.com/

That way it is possible to refer a windows administrator to just the one
site and they will be able to work out what is going on.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
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 <8009330@pamho.net> "Roger Moser" <Roger.Moser@pamho.net> writes:

> I have now finished (except the cache) and tested my implementation of SPF
> for Windows. You can download the C source at www.pamho.net/source.

Very cool!

I like how you also parse MS Caller-ID records.


One thing I noticed is that if you find that malloc failed, you often
(always?) return SPF_unknown. In libspf-alt, I return SPF_error on
the theory that we will likely have more memory later on.


-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

On Tue, 30 Mar 2004, Roger Moser wrote:

> Wayne wrote:
>
> > One thing I noticed is that if you find that malloc failed, you often
> > (always?) return SPF_unknown. In libspf-alt, I return SPF_error on
> > the theory that we will likely have more memory later on.
>
> If under Windows NT malloc fails, then Windows is in serious troubles and
> most probably crashes. So it does not matter what SPF returns in that case.
> I chose SPF_Unknown, because that value stops the parser. (First I even did
> not check if malloc fails.)

You could make this behaviour even more reliable:

if (malloc_failed()) {
if (get_win16_lock())
crash_windows();
while (1)
kernel_ding_ding_ding_ding_ding_ding_ding();
}

Something in me prefers the "unknown" response. It's a case of:

Our system has failed, or is in an unknown state. Assuming
recovery is probably stretching the point. Let's just not
interfere any more.

This kind of case is fairly personal.

S.

--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/

-------
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 <Pine.LNX.4.53.0403301733370.2504@astray.com> Shevek <spf@anarres.org> writes:

> On Tue, 30 Mar 2004, Roger Moser wrote:
>
>> Wayne wrote:
>>
>> > One thing I noticed is that if you find that malloc failed, you often
>> > (always?) return SPF_unknown. In libspf-alt, I return SPF_error on
>> > the theory that we will likely have more memory later on.
>>
>> If under Windows NT malloc fails, then Windows is in serious troubles and
>> most probably crashes.

In which case, you will likely have more memory after it reboots.



> Something in me prefers the "unknown" response. It's a case of:
>
> Our system has failed, or is in an unknown state. Assuming
> recovery is probably stretching the point. Let's just not
> interfere any more.

Yeah, but "unknown" means that either the domain owner explicitly said
to give that result, or that there is something wrong with the SPF
record that the domain owner published. This is something that will
not change if the email gets recent later, it will only change when
the domain owner changes the SPF record.

This is the not the case with an out-of-memory failure, it is a
problem with the receiving system, and, like many DNS failures, will
likely be fixed without the domain owner doing anything with the SPF
records.


> This kind of case is fairly personal.

Yeah, and somewhat of an academic one in this era of multi-GB of ram.


-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

begin Tuesday 30 March 2004 19:00, wayne quote:
> >> If under Windows NT malloc fails, then Windows is in serious troubles
> >> and most probably crashes.
>
> In which case, you will likely have more memory after it reboots.

... and even more memory still after you've reformatted it and put
Linux on it ;-)

(Sorry, couldn't resist)

Alain

-------
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 wrote:

> One thing I noticed is that if you find that malloc failed, you often
> (always?) return SPF_unknown. In libspf-alt, I return SPF_error on
> the theory that we will likely have more memory later on.

If under Windows NT malloc fails, then Windows is in serious troubles and
most probably crashes. So it does not matter what SPF returns in that case.
I chose SPF_Unknown, because that value stops the parser. (First I even did
not check if malloc fails.)

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