spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Revising FAIL

2008-01-09 14:13:31
Julian,

I appreciate your explanation to Alessandro, as it better clarifies the thinking behind not requiring actions on the receiver side in the specification for me. Even so, I think his is point is well taken (unless I'm missing something else), in that offering recommendations in RFC specs is not unusual. Simply couch them in words like "should" or "may".

If there is an underlying reason why "some things are better left unspecified" that you can either share here or simply assure me is true, but not for public consumption, I'll leave this issue entirely and accept what you say on this point without additional questions.

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy


At 01:33 PM 1/9/2008, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alessandro Vesely wrote:
> Julian Mehnle wrote:
> > I'd really like to avoid telling receivers what to do with "Fail".
>
> I beg your pardon, but I don't understand this point. Besides that,
> as you say, its very name tells what to do, the purpose of a spec
> is to formally tell what to do, isn't it?

SPF, "Sender Policy Framework", is a standardized way to declare your mail
sending policies to receivers, i.e., through which hosts you send and
through which you don't send.  The main aspect of the SPF spec is to
define how to construct these declarations and what they mean.  What it
does NOT define is how receivers should react to those declarations and
to the results of evaluating them (with very few exceptions like "Neutral
must be treated exactly like None").

If you observe what e-mail receivers are doing in the wild, you'll quickly
notice that they frequently violate all kinds of RFCs because it turns
out better for them that way (some violations being reasonable, others
merely due to stupidity of course).  So about two years ago, when we were
finalizing the SPF spec, we deliberately decided against requiring
receivers to react in specific ways.  Choosing the best universal
behavior to put in the spec is very difficult, and many receivers are
going to ignore it anyway.

What would you think of a law that required you, whenever you encountered
a false banknote, to stop whatever you were doing and bring it to the
central bank AT ONCE?  Lawmakers might have thought it would be a good
idea, but those subject to the law might often find themselves in a
completely different position.

> Perhaps, you mean that telling receivers what to do after various
> checks should be the subject of a separate rfc?

Some things are better left unspecified, best practice recommendations
notwithstanding.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhS+KwL7PKlBZWjsRAmIqAKC9c7OXVIqYbwDSSRWI+sATFHD1PACg8qn9
rDsntyf3gacKJ1kja1tM/to=
=Hqfq
-----END PGP SIGNATURE-----

-------------------------------------------
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/?&;
Powered by Listbox: http://www.listbox.com


-------------------------------------------
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=83945305-ae3675
Powered by Listbox: http://www.listbox.com