Stuart D. Gathman wrote:
On Thu, 22 Jul 2004, David Sowder wrote:
It seems to me that some are confusing things a little. In my mind,
all SPF asserts is that a set of IP addresses is legitimate for a
domain. Given the IP address of a connected SMTP client, an SPF
record makes an assertion as to the legitimacy of the server at that
IP address to send messages with an envelope from (and potentially
other uses) of that domain.
I think the word 'legitimate' is confusing things. In the context
of SPF it should mean 'the return path domain was not forged'. 'Legitimate'
messages from a SPF compliant spammer will be spam. SPFv1 is concerned with
stopping return path forgery - and that's it. So let's restate the
results using the word 'forged' intead of 'illegitimate'.
+ means messages from this server with this domain are never forged
- means messages from this server with this domain are always forged
? means messages from this server with this domain may or may not be forged
~ means messages from this server with this domain are most likely forged
I prefer using "authorized". "Authentic" or "legitimate" carries too
many connotations about the content of the message. The whole reason
that (as a mail admin) that I'm willing to implement SPF is that I want
to be able to say:
IP addresses X, Y, and Z are authorized to send e-mail on behalf of my
domain. Any e-mail from other IPs purporting to be from my domain are
forged (those IPs have not been authorized to send e-mail using my
name). Or, if I know I have users who sometimes use mail services which
forge domains, I might say "there might be e-mail from other IPs, but we
don't care if you choose to toss it as suspect".
Nothing in there about authenticity, or whether the e-mail is
legitimate. And the farther away that SPF gets from simply specifying
what IPs I've authorized to send mail for my domain, the less enthused I
am about the whole draft/implementation. I simply want a way to put a
dent in domain forgery.