On Thu, Jan 08, 2004 at 08:14:18PM -0600, wayne wrote:
| >> | Too many cases can result in an "unknown" return value.
| >> | That makes debugging hard. There needs to be a "none"
| >> | value, for cases where there is no SPF record; there needs
| >> | to be a type code for "unknown", to distinguish among the
| >> | many error cases. Beyond that, the set of type codes needs
| >> | to be enumerated -- as is, we'll see an operational nightmare.
| >
| > Ditto, must fix
|
| I gotta agree with this objection. I don't quite understand why the
| "none" value was removed. I think it could be added back in without
| breaking things.
|
| Meng?
Here's why I took out the "none". I'm not very confident of this line
of reasoning so do read it with skepticism.
Domain owners new to publishing SPF will be filled with trepidation.
The last thing they want is to cause legitimate mail to bounce. I
thought it best to reassure them by saying that if processing results in
an "unknown" the client MUST proceed as though it did not publish any
record at all.
A domain with users all over the place might start by publishing "v=spf1
a mx exists:%{...} ?all" in an attempt to find out which legitimate users
are mailing from "off-campus". But a zealously antispam MTA might look
at that record and conclude that the "unknown" default result was close
enough for his purposes to "fail". If we distinguished between "none"
and "unknown", SMTP receivers might consider "unknown" the worse result.
Or, suppose things go well and we see a 50% adoption rate among the
domain owner pool. An overzealous fraction of the MTA community might
decide that it's time to drop all domains that don't publish SPF
records, and judge "none" the worse result. Then you'd see a lot of
domains scrambling to publish "v=spf1 ?all". But once they have, in
their minds, dealt with the annoyance of SPF, they might not go back and
set things up properly.
I don't want to create a language in which we create an arms race of
hype, where people bluff and second-guess each other from opposite
poles. If a domain wishes to be treated as though it had no SPF, we
should respect its wishes.
All the above is coloured by my personal belief that mail that has no
SPF record should be given the benefit of the doubt. Certainly, we
should scrutinize it more carefully, and content-filter anything that
has no SPF data, but I do not want the scant distinction between "none"
and "unknown" to be the basis for the decision to reject.
It's late, and I'm not sure I'm making a coherent argument. I'm not
terribly strongly attached to this point of view, so if the consensus is
that I'm wrong about this and that it would be good to return "none" in
certain cases, I'm happy to do that. In any case it would be trivial
for an MTA to go over the head of any SPF library, and independently
discover "none".
Also, if "none" is valuable, tell me whether we should return "none" or
"unknown" if a domain with an SPF record that just uses redirect to
point to another domain without one.
I do agree that we would benefit from a finer classification of errors.
Here and elsewhere, Bellovin is right to criticize the specsmanship.
If you guys can help come up with a good patch, I will apply it.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡