-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Raymond
Neeves
Sent: Friday, May 20, 2005 10:18 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] BTFOOM
----- Original Message -----
From: "Mark" <admin(_at_)asarian-host(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, May 20, 2005 10:07 PM
Subject: RE: [spf-discuss] BTFOOM
The overall problem on this (and similarly) outstanding item(s),
as far as
I see it, is the difficulty that the decision to make something a
PermError is always closely related to what should happen on PermError.
Which is to say, declaring a PermError cannot be seen apart from what is
to follow that result; and, conversely, what is declared to follow a
PermError, inevitably affects what we wish to call a PermError. For
example, if we were to ignore PermErrors, then declaring something a
PermError has an entirely different consequence than saying, for
instance,
that a PermError should be met with 5.x.x codes.
- Mark
why should this be a problem, you lot sort out what generates what type of
response, the mta owners will sort out what to do in the event of
each type
of response. If they wish to 554 on PermError it's their mta, their
responsibility, they can (and do) generate 554 on Neutral if they want.
if the spec starts saying i MUST generate a 554 for a Fail result and, say
for some legal reason, i can't reject any message then i can't use SPF
because all the coders will have followed the spec. Never forget, it's my
mta, my rules. you can provide mechanisms to help me manage my
message flow
but if it's too restrictive then i'll dump it pretty quickly no matter how
helpful it is in other areas.
this is really a coding issue, not a specification issue. the spec will
show the coders how to generate an SPF response for a given set of input,
the coder will either hardcode what they think should happen/is in
the spec
or they'll be flexible and allow the mta admins to assign an
action for each
possible SPF response. The hardcoded software will not last, no one is
going to put up with not being able to change the settings. The same goes
if you start forceably linking mta actions to SPF responses in the spec,
then SPF itself would not survive.
On the other side of the coin, SPF record publishers (senders) need to have
some expectation of how publishing an SPF record will affect their mail. I
agree the spec shouldn't handcuff the receiver with excessive use of MUST,
but if the sender gets chaotic results from using certain mechanisms, then
they won't use those and may well have to abandon SPF publishing.
There is a balance in here between the sender having certainty with what
will happen with their mail due to SPF and the receiver having complete
freedom to do with SPF as they will.
Scott K