Julian,
At 05:31 PM 1/8/2008, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
WebMaster(_at_)commerco(_dot_)net wrote:
> May I offer this minor wording change...
>
> | A "Fail" result is an explicit statement that the client is not
> | authorized to use the domain in the given identity. Domain owners
> | should be aware that, while most mail receivers typically reject
> | messages on this result as suggested, some receivers may decide to
> | mark the mail based on this.
>
> I'm playing with semantics a little here in saying suggested, in that
> what I mean is what the word Fail suggests rather than the making of
> an actual recommendation. If developers were to take it as a
> recommendation, I would not be heartbroken. After all, when I
> publish an SPF record with "-ALL", such that the outcome is an
> explicit Fail for that domain, I would prefer the result was, in
> fact, a rejected message.
Well, if the word "Fail" suggests rejecting, then why do we need to spell
it out?
I'd really like to avoid telling receivers what to do with "Fail".
It was just a thought. No harm, no foul. I'm not sure that a
recommendation for processing in a spec is really telling them what
to do. I guess it is the difference between telling vs recommending
is using words like must as opposed to should. However, as I
originally said, your version looks good.
> FWIW, in future versions of SPF it might be nice to introduce a
> "FAIL-REJECT" vs a "FAIL-BOUNCE" concept with some trigger in the SPF
> record to further indicate and further qualify the preference of the
> domain holder as to what the receiver should do with a "Fail". I'm
> not sure which would be considered the default, but perhaps the way
> to handle that might be to follow an "-all" with a "-reject" or
> "-bounce" or some such thing to indicate the domain holders
> desire. Personally, I think the default should be "-reject" to avoid
> having to receive the bounces from a "Fail". After all, I know it
> should fail because I created the SPF record, the receiver knows I
> want it to fail because they read and interpreted my intent, so let's
> just drop the problem message and save both our systems further time
> and energy.
Please let's not do the receiver policy thing.
I'm not meaning to do that, I'm simply wanting to express a desired
response to a receiver from a domain holders perspective. I could
envision times when I would like to see bounces and have the ability
to shut them down from at least some of the MTAs who might respect my
wishes if the bounces become overly burdensome on my servers. That's
really all I had in mind.
I know it is difficult for domain owners to decide on how to qualify their
policies, not knowing how receivers will act on them. However it will be
even more difficult for domain owners if they make assumptions about how
receivers will act based on recommendations that we put in the spec but
will actually be ignored by receivers, because receivers will always just
do what's best for _them_. I know that I, as a receiver, would. (For
example, I treat "Neutral" the same as "None" not because the spec tells
me to, but only because I happen to agree with the spec.)
No argument there.
Furthermore, why do you care whether the receiver rejects "Fail" messages
from your domain, or marks them, or drops them on the floor, or feeds
them into their /dev/random? What difference does it make to you?
Given the choices above, it makes no difference. I was thinking of
bounce back messages to my servers, which does make a
difference. Perhaps I've forgotten yet another thing about SPF, but
does the spec already provide for recommending the stopping of bounce
back messages from occurring when a domain name is spoofed and SPF "Fail"s?
Best,
AlanM
The Commerce Company
TZ.Com - Travel Zippy
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=83450303-44915d
Powered by Listbox: http://www.listbox.com