Re: For SPF Council review - PASS Definition - was: People keep misunde

Chris,

As an SPF publisher, FWLIW my feedback...

At 11:11 AM 5/18/2005, you wrote:
.. snip ..

> It's not the vocabulary that's wrong, its the logic.
>
> What I think we are trying to make with PASS is two logically-different
> declarations:
>
> 1) That the IP is authorised by the domain owner to send messages on its 
> behalf,
> 2) That the IP is trusted by the domain owner _not_ to send messages 
> purporting
> to be from the domain that were not, in fact sent by that domain
As a practical matter, I suspect the majority of SPF publishers accepted 
the SPF concept based upon item 1.  Item 2 seems like it is a logical 
extension of item 1, in that if an MTA is trusted to send mail for a 
domain, it would be reasonable to expect that the server would not send 
mail that did not come from the domain owners.  I'm not sure that SPF has 
as much to do with that as the SMTP server does.  In other words, if I am 
understanding your point, it is good not to send mail through open relay 
servers or servers that allow a non-domain owner or anyone who is not an 
authorized designee of the domain owner to specify messages as coming from 
the domain owner's domain, which is of course entirely reasonable.
As an SPF publisher, when we publish DNS TXT records with -ALL specified, 
the expectation is that the PASS records must only match servers we 
published in our TXT records as valid outbound SMTP servers.  Mail 
purporting to be from a domain we control and publish DNS TXT records for 
which do not match our list of authorized servers should never be delivered 
to an end user nor forwarded to an end user and we don't want the bounces.
As some folks may try to creatively engineer anti-spam add-ins to the SPF 
specification, I trust none shall forget that SPF is first and foremost a 
vehicle to prevent domain identity theft in email FROM.  Whatever is done 
to the spec, please just don't ever break that primary foundation.

> Or to put it another way, Pass means that all messages coming from this IP and
> claiming to be from this domain are, indeed, from this domain.
>
> Using similar language, NEUTRAL means : the domain does send authorised 
> messages
> via this IP, but it is possible that the IP can also send messages claiming to
> be from the domain but which were not actually authorised. The recipient 
> cannot
> therefore make any firm decision on the authenticity of any specific 
> message on
> the basis of this test alone.
>
> SOFTFAIL (to me) says: The domain does not intend to send mail via this IP, so
> anything claiming to be from the domain is probably unauthorised, but please
> inform the domain owner about all such attempts, in case the domain has 
> made an
> error in configuring its mail system.
>
> FAIL says: Anything coming from this IP which claims to be from our domain is
> certainly unauthorised.
>
>
> HTH
>
> Chris Haynes
Chris, the above is really very well stated.  I think the original reason 
for NEUTRAL was to also serve as an answer when a domain owner did not 
publish an SPF record.  In other words, don't draw any conclusions on 
NEUTRAL as to publisher's intent, because in NEUTRAL, there may be no SPF 
record.
I especially liked and agree with your description of SOFTFAIL, in that it 
allows for times where network topology might change and during the 
transitional time, one can check to make sure that one has properly 
configured their SPF TXT records though active feedback from bounces where 
errors have occurred.  Once the domain operator is confident thing are 
configured properly, they can resume -ALL.
I think that some on this list have argued that the ~ALL option should 
vanish over time.  I think that in the course of time, it probably will in 
normal operation as most publishers will eventually want to publish records 
with the -ALL syntax. That said, having it remain available for times of 
network change is valuable, so much so, that I think it must always have 
its place in the specification.  Many moons ago, I had asked about having 
an option to trigger an MTA to bounce or not bounce.  ~ALL versus -ALL 
seems the easiest of all way to handle my request without a single extra 
bit of syntax.
i.e.,
-ALL = Only from PASS having problems allow bounce (e.g., legitimate 
55x).  If FAIL, do not deliver and do not bounce - the message was not 
authorized.  PASS messages may well or may not pass spam filters, but at 
least you know the SPF publisher was the source.  If spam is the problem 
(as opposed to forgery), then bounce based on the spam filters and not SPF.
~ALL = Don't make a judgement about authorization, messages may or may not 
pass spam filters, but in any case, return all bounces, so the problems can 
be evaluated locally.
Best,

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