| 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 think we need to remove the version numbers, they can be encoded into the
record selector - _spfv1.example.com TXT ....
| The most glaring problem with SPF is the use of TXT records.
| TXT records are supposed to be free-form text, with no
| semantics attached.
Supposed schmuposed.
The DNS spec is a quarter century old and the extension mechanism is broken.
A new record type would be less compatible with the deployed infrastructure.
There are many assumptions expressed in the DNS specs that are plain wrong.
The statement about TXT records being one of the most glaring mistakes.
The SRV _selector. mechanism provides the right way to extend the semantics
of TXT.
The use of TXT for test purposes is
| understandable (though regrettable -- an experimental record
| type code would be better); the use of TXT records for
| textual error messages is not. The document itself notes
| the problem of ordering of multi-record messages. Beyond
| that, there are problems with internationalization: what
| language should the error message be in, and in what
| character set is it encoded? A simple URI would be a better
| solution; at the least, it should point to an SPFERR record.
| (Record subtyping in the DNS causes problems; see RFC 3445
| for some details on why.)
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.
"000/010 First record"
"001 Second record"
"..."
"010 Last record"
| The use of TXT-like records is problematic because it
| requires parsing an ASCII string in a DNS resolver. (Yes,
| I know that NAPTR records require the same sort of parse.
| I don't much like that, either.) The more complex the
| parse, the harder it is to get right, both for the author
| and the receiver of such records. A TLV-based structure
| permits parsing by the author's DNS server, and is easier
| to interpret on the receiving end.
It requires deployment of a new DNS server though. All handling of
unrecognized record types is optional.
| The Received-SPF header line is badly specified. It doesn't
| follow the the standards for other RFC 822/2822 headers
| (i.e., it requires exactly one space in certain places
| where an arbitrary amount of white space (including none)
| is permitted in other headers); it has some things as
| comments (receiving host) that should be parseable; and it
| doesn't mandate that Received-SPF lines from outside of
| the domain MUST be deleted. (The actual requirements here
| are more complex; I won't go into details in this note.)
| Yes, the line as specified is a bit easier to parse, but
| any spam filter is going to have to deal with many other
| headers, and hence will have to have a full-fledged 822/2822
| parser.
This issue must be addressed. Intermediaries have the right to add/subtract
arbitrary whitespace...
| 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
| Section 5 speaks of using Received: lines. Such lines have
| been forged by spammers for many years. While they can be
| used, great care must be taken. This document needs to
| define the necessary steps appropriately.
Ditto, must fix
| 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
| The macro language scares me -- it's very complex. Note
| that DNS records are limited to 512 bytes unless EDNS0 is
| used; EDNS0 is not widely used today, and may incur other
| costs. But the real problem is that the functionality
| permitted may be far too rich -- arbitrary semantics are
| not a good idea, since they can lead to random breakage
| when some site implements a test that another site isn't
| prepared to meet. In Postel's language, a sender can't be
| conservative in what it emits if it doesn't know what the
| requirements are.
Absolutely, the Macro language really has to go if there is going to be much
support in the general network protocol community.
| 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.
|
| The suggestion that this scheme become default in April,
| 2004 (Section 9.4) is preposterous. Even if the IESG were
| to approve this document today -- and very few documents
| are passed on first try -- it would take far longer than
| four months to build, test, and deploy production-grade
| clients and servers.
There are misunderstandings on both sides here. I agree with Steve that the
timetable is ridiculous and the statement is a liability, it will look like
the scheme has failled when the deadline passes without action.
The other misunderstanding is that the spec is offered for IESG review or
for that matter IETF review. My understanding of the process here is that
there is no roll envisaged for either body wrt SPF.
I do not see how IETF endorsement helps deployment of SPF. I am not aware of
any significant constituency that will be attracted. Steve Bellovin's
personal comments carry considerably more weight than that of the IESG in my
view.
| The security considerations section mentions IP address
| spoofing, though the FAQ claims that they aren't real. I
| agree that classical spoofing, per Morris' 1984 memo, is
| probably not a major threat here. But spammers are using
| BGP to steal entire address blocks -- that's a bigger
| threat. (The FAQ also points to RFC 2761 when it should
| be 2671.)
Yep, this is serious - and the reason why we will eventually need domain
keys.
| Uptake Model:
| As Rick Adams has pointed out, there is no consensus yet
| that this is the right way to go. The major ISPs on the
| net -- AOL, Yahoo, MSN, etc. -- have not bought into this
| scheme. Unless and until they do, it doesn't help much,
| either for their customers (who make up a substantial
| proportion of the user population) or for everyone else
| (since their addresses could be forged).
Agreed, but Steve does not know the status of those discussions.
| 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. (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.)
|
| The net effect will be to bind users more strongly to their
| ISPs and/or their employers. While big ISPs may like that,
| it flies in the face of current (American) public policy
| -- witness local telephone number portability. Ironically,
| it will also discourage a current anti-spam strategy used
| by many: throw-away email addresses for particular purposes.
|
| It will also make life harder for people who regularly use
| multiple sending email addresses. For reasons of privacy,
| my children generally use email address that are not readily
| tied to their real names. But for certain very important
| kinds of communication -- sending email to teachers, for
| example -- they use a family-linked email address.
|
| It isn't always clear to people what SMTP server they're
| actually using. Over the last few years, I've noticed that
| one major hotel chain intercepts outbound SMTP connections.
| I don't know if they're trying to defend against check-in
| spammers or if they're trying to help travelers whose
| laptops are hard-wired to point to their company's or home
| ISP's SMTP servers. Granted, people should use VPNs or
| SMTP/SASL for such things; too may don't and perhaps can't
| -- if your ISP doesn't support it, for example, you can't
| use it, and switching ISPs carries a non-trivial cost,
| especially if you have only one choice of broadband ISP.
|
| I've underscored some of my points here by using a portable
| email address of my own, rather than my usual email address.
|
| Conclusion:
| The basic concept may or may not be a good idea. The
| authors themselves admit that it's only part of a total
| anti-spam solution, and I'm not convinced that it's worth
| the deployment effort. Its strongest in dealing with "joe
| jobs" -- spammers (and worms) impersonating real email
| addresses -- but that's the part that most runs afoul of
| my semantic concerns.
Impersonation spam is a major evil that is responsible for the vast majority
of phishing and other impersonation based scams.
Phill
-------
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;±¤Ö¤Íµø?¡