In
<2A1D4C86842EE14CA9BC80474919782E011132C6(_at_)mou1wnexm02(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
| Specsmanship:
| The version number definition is problematic -- it only
| has major version numbers. I suspect that we need minor
| version numbers as well, for operational debugging.
I suggested a minor version number also, but I don't see this as a big
deal. If and when a new version of the SPF spec needs to come out, we
can use anything we want for a version number since older version MUST
NOT use newer records.
I think we need to remove the version numbers, they can be encoded into the
record selector - _spfv1.example.com TXT ....
And then there would be people complaining about underscore character,
the new, required host name that may already be in use, etc.
I personally preferred the _spf.<domain> usage instead of having the
TXT record under <domain>, but the amount of problems both ways, I
don't see a compelling reason to make an incompatible change at this
stage.
The SRV _selector. mechanism provides the right way to extend the semantics
of TXT.
The SRV _selector doesn't extend the semantics of TXT, it is a
mechanism for locating services on a host/port pair. If SRV could
have been used for SPF, it would have been.
| Beyond
| that, there are problems with internationalization: what
| language should the error message be in,
I brought up the point of i18n also, and Meng pointed out that there
isn't enough information at the time that the error message is
generated to deal with the issue. You don't know the language of the
sender or the receiver and there is no way to find out.
| and in what character set is it encoded?
Hmm.. I thought that was specified as ascii, but I can't find any
doc that says one way or the other. It should have the same
restrictions that SMTP reject messages have, since that is where the
message will end up at.
| A simple URI would be a better
| solution; at the least, it should point to an SPFERR record.
The exp= TXT record is intended to hold a short message, often one
with a URL.
Multi-record messages is an issue - we solved it in auth-sender, pretty
easily at that. Just stick a prefix on each record and sort into order.
The SPF spec simply defines what to do if you find multiple TXT
records. In no way should they be encouraged.
| 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?
| 5.1 speaks of cidr-lengths, but 5.2 et seq. speak of
| dual-cidr-length. That looks like something where the
| editing hasn't caught up yet. But having a CIDR length on
| an MX record is a bad idea, since there may be multiple MX
| records with different appropriate lengths.
Ditto, must fix
"Doctor! Doctor! It hurts when I do this!"
While there are many cases where using a CIDR length on an MX record
is a bad idea, there are others where it is just fine. If the folks
creating the SPF record can't be trusted to do the right thing, well,
they shouldn't be doing it at all.
| The macro language scares me -- it's very complex.
Absolutely, the Macro language really has to go if there is going to be much
support in the general network protocol community.
I share the concern that that macro language is scary, but I
absolutely think it must stay. It is one of the keys to making SPF so
useful. It is already being widely used.
| 8.4 ruins much of the effectiveness of the scheme -- it
| provides ways to avoid processing. For example, a spam
| engine could send email with a local-seeming HELO, MAIL
| FROM, and From: entries, in which case (per Example 3) SPF
| isn't to be used. Spam from abuse@ or postmaster@ can also
| bypass checks.
To quote from the spec:
SPF is only one component in a policy engine. An SPF-conformant SMTP
receiver is NOT REQUIRED to perform SPF tests on messages whose
dispositions have already been decided on the basis of other policy.
If an MTA (or whatever is checking the SPF record) doesn't want to
apply the policy, there is no reason why it MUST. In the case of all
local-seeming HELO and MAIL FROM: parts, that generally handled by
other parts of the MTA right now.
| Semantic Model:
| In a strong sense, the part that requires the most debate
| is the semantic model. SPF strongly binds a sender to some
| DNS records. But that isn't always a good idea. People
| who use portable email addresses will now be constrained
| to use the domain owner's SMTP sender, which may not even exist.
Steve is misunderstanding stuff here.
| (A more interesting model would permit delegation
| of individual user names to particular sending machines.
| But that would probably require too much public key
| cryptography to be affordable.)
Uh, SPF *can* be used to permit individual local parts (user names)
to particular sending machines. SPF also allows many other
interesting ideas such as rate-limiting the use of unauthorized
machines and "SPF after IMAP". (Both cool ideas thought up by others
after the SPF spec was frozen.)
-wayne
-------
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;±¤Ö¤Íµø?¡