[this is a bit of a brain dump, sorry].
Hi all,
I prefered the version 1 draft beacause of it's simplicity, and you could
get a result in a fixed number of lookup (vs. the posability of having to
do recusrive lookups[3]).
One other advantage of the _smtp_client.example.com approach is that you
could turn query logging on in your dns servers for the _smtp_client domain.
This is simpler to implement than the report option, tho you would lose
lose sender and recipient logging as part of the package.
(If you got the emails you could grep the received headers for the ip that
was queried in the SPF lookup, but then you might not get the emails).
With the 02-draft + report extention, if the remote mta dosn't suport the
report option you get nothing (beacause you don't know which sending host is
being tested), with this you at least get something.
Localpart option:
-----------------
(This is a fairly weak point, i freely admit to not knowing how possible
this is, but it may be worth watching as an implementation detail, (assuming
localpart makes it to the RFC)).
Imagine you have a localpart in a multibyte charset, when it's sent over the
net it's encoded using one scheme or another so as to be 7bit clean.
Now some MTA's in a country that uses multibyte encodings understand these
encodings and translate them to the multibyte equilivent, if these MTA's do
an SPF lookup using the decoded multibyte localpart and some using the
encoded localpart you'll have to have two localpart settings per user.
I think it's worth stressing that localpart's should be looked up as they
stand when received rather then being decoded.
There are also potential security problems here, there have been some
unicode parseing bugs in the past and given the posibilities of either the
MTA, resolver or dns server trying to be 'helpful' and encoding/decoding
things.
Personally i'm against localpart, it failes KISS for me, and is hard to
implement[1], and SASL+TLS is such a good idea for a whole bunch of other
reasons too.[2]
Waving a flag for the 01 draft.
-------------------------------
After a (rather cursorary) flick through the archives there seem to be three
objections to the 01 draft (appoligies if i've missed something).
a) underscores
- fine, but _smtp_client *isn't* a host, and so it's legal, but if
people really care that much then hyphens are fine by me.
b) wildcards & DNSSEC
- Do we really need wildcards? with a vairation on draft-01:
--spf-.example.com IN TXT "deny"
1.2.0.192.--spf-.example.com IN TXT "allow"
(we don't need "spf=" cos we're in the spf subdomain).
Do two lookups:
the first lookup is against --spf-.example.com:
if NXDOMAIN :: SPF unsported, skip next lookup
if "deny" :: spf supported, with default deny policy
if "softdeny" :: spf supported, softdeny policy
the 2nd lookup is the usual reversed IP:
if "allow" :: Accept mail
if "NXDOMAIN" :: drop mail if policy == "deny", else accept & add X-SPF
header.
draft-01 only needed wild cards to distinguise between "no SPF support" &
"host not found".
This also means less lookups than 01 cos the --spf-.example.com record will
be negativly cached...
c) complexity
- Without wildcards it's a lot simpler
- we already have an easy to use web based RR generator[4],
adding 'include A records' and 'include MX records' checkboxes
won't be hard.
- draft-02 still has the complexity, but instead of having it
resolved once when the sysadmin config's the zone, it's resolved
each and every time a host sending email is tested.
- draft-02 is much more complex to implement in an MTA, 01 or the
simplified scheme above can be done with not much more than
strncmp, but 02 needs fairly complex string parsing, and thats
a source of risk and danger (admittadly secure programming in C
is better understood now, (but if we can't get OpenSSH right do we
really want to risk it?)).
- heck, why use txt records at all?
- in the ip lookup do an A lookup and if the result is the the IP
your looking up, then accept the mail.
- e.g.: 1.2.0.192.--spf-.example.com IN A 192.0.2.1
- in the first lookup:
- 127.0.0.1 :: "allow"
- 127.0.0.2 :: "softdeny"
- 127.0.0.3 :: "deny"
- and now SPF is a (sort of) dnsbl/rbl(tm) list with a twist.
- and another thing, now we don't have to worry about DNS providers
who have a web based interface to clients zone files and who don't
support TXT records.[5]
[1] Admitadly with a MS style Active directory setup it would be easy, you
just tick the 'I want to send email to anyone from here' box in your mail
client and it automaticly updates the zone. (The counter argument is that
viri and worms can do some software equilivent of ticking the box too).
[2] End to end encryption of mail that is sourced and sunk within your
enterprise, email can't leave the enterprise without having enterprise-wide
viri scanning policy applied, no worries about WiFi in airports, coffe shops
and conferences etc.
Oh, and then there is the vairous dialups dnsbl's to worry about...
[3] We have to ask - how can spammers abuse SPF? One way (weak that it is),
is to use SPF with throwaway domains and teergrub the dns lookups,
'punishing' SPF using domains by slowing down there MTA's.
[4] Thanks!
[5] ok, maybe they will dissallow leading and trailing hyphens too
(which are also illegal), how about s-p-f.example.com?
--
[http://pointless.net/] [0x2ECA0975]
-------
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.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡