Re: Handling of -all

Dear fellow SPF list members,

Please allow me to echo and expand upon what I gather is Rene Barbier's view.

My company adopted and published SPF records for domains it operates with 
the fundamental understanding that the FIRST goal of SPF was to protect the 
reputation of the company's domain names.  I understood that in publishing 
with the -all record syntax as shown below, I was ensuring that if anyone 
appropriated a domain name that was under the control of my company's DNS 
servers to include without permission in their message as the FROM address, 
the receiving SPF aware MTA / SMTP server would to perform a lookup for the 
DNS txt record of the domain and determine that the message did not come 
from my company.  Period.
In publishing an SPF txt record for a given domain as follows:
v=spf1 redirect=_spf.example.com
and the SPF txt record for the redirect record of _spf.example.com reads:
v=spf1 -all

my company is telling any parties checking (and fully expect them to 
understand in publishing the above) that this domain does not send email 
messages at all - EVER.  Therefore, what I also expect to happen is that a 
receiving MTA / SMTP server will simply junk anything seen with a FROM 
address using that domain or any sub domain in it.
No Delivery to its users, No Relay to anyone else, No Bounce to my 
company.  Just drop the message.
The company is saying that the receiving SPF aware MTA has a 100% certainty 
the message it just received is bogus garbage, so just shred the garbage 
which the misanthrope responsible just sent to the MTA (and optionally 
report the IP address it came from to appropriate sources), because garbage 
is exactly what the MTA just received, if the above referenced DNS SPF txt 
record syntax is published for one of my company's DNS controlled domains.
I think that pretty much is what SPF was originally represented as 
offering.  If you remove that ability as a basic starting point, you have 
emasculated the entire SPF system to the point of being useless for its 
original purpose.  Obviously, any deceitful curs of questionable parentage 
who steal other's domain names for use in emails they issue would be 
delighted to see that happen as well as anything else which retards 
progress or successes in getting SPF popularized and universally adopted.
From my selfish publisher perspective, absolutely any and all other issues 
are moot, if the basic premise of the SPF system is no longer 
applicable.  At that point, we might as well just pack our bags and leave 
the project and I for one have no intention of doing that.  The base stated 
functionality of SPF MUST supercede any other concern without exception.
If a potential implementing adopter has a problem with that, then they 
should establish an acceptable syntax for a next generation / version SPF 
and not implement their own DNS SPF txt records until such a syntax which 
works for their environment is adopted.
If a domain holder publishes a DNS txt record for SPF and uses the -ALL 
syntax, please respect their wishes.
IMO, anything else is a misrepresentation of SPF's purpose and just plain 
wrong to do, so please just believe those of us who adopted and published 
DNS SPF txt records with that basic understanding of SPF's fundamental 
purpose and function.
Please just take SPF publishers at our (DNS SPF txt published record) word.

Best,

Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/

At 03:24 AM 2/10/2005, you wrote:
> Tony Finch wrote:
>
> > I think the best advice at the moment is to do both of these things. SPF
> > is probably a reasonable SpamAssassin test, but it isn't accurate enough
> > to be the sole reason for rejecting a message.
> I do publish -all, because the damage that is done by fake messages 
> pretending to come from our domain is much larger than the potential 
> danger of being rejected because of forwarding. I therefore expect other 
> domains to reject based on that policy. To quote Scott Kitterman:
> > (3) Originating domains MUST publish -all policies only after the understand
> > the potential consequences and believe that the risk of some messages is
> > worth the benifits associated with the policy (that would be me by the way).
> and
>
> > SPF verifiers SHOULD reject messages that fail a -all test
> As we expect others to reject on -all, the same is performed at our mail 
> boundary. The largest problems we see nowadays are not unforeseen 
> rejections, but plain IP blocks (verizon.net for example).
> Best regards,
>
> --
> Rene Barbier
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
> To unsubscribe, change your address, or temporarily deactivate your 
> subscription, please go to 
> http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com