-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Mark
Sent: December 15, 2003 2:43 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Maybe simple question
The problem with SPF is this: anyone who has SPF records
must provide
an SMTP AUTH (or other mechanism) relay for its users once
they leave
that organization's IP pool. That's what I think Mr. Harvey
was trying
to argue, and a serious problem for some people.
But this is not an SPF issue, per se. All relays are
inherently "closed" (unless they are grossly misconfigured),
with or without SPF. So, basically, everyone "must provide an
SMTP AUTH (or other mechanism) relay for its users once they
leave that organization's IP pool," with or without SPF. The
administrator of such a relay can decide to add "Trusted
Mechanisms" (in sendmail terms), that will allow for a relay
from outside the organization's IP pool; like SMTP AUTH, or
DRAC (Dynamic Relay Authorization Control). But, like I said,
that is not an SPF matter, per se; not being an open relay,
and providing trusted mechanism to deal with relays from
foreign IP space, is just responsible system administration. :)
Responsible system administration or not, I'm sure lots of people aren't
currently providing SMTP AUTH relays...
The way I see it, for the home user, there are four distinct
situations:
1): He sends mail through the SMTP server of his ISP, using
an envelope from address with the domain name of the ISP. In
this case, there is no problem, as SPF queries (at the
machine your ISP's SMTP server relays to) will be targeted at
the DNS server of the ISP (who, itself, has published SPF
records that include its own SMTP servers). And you have
authenticated yourself to your ISP's server, using SMTP AUTH, or DRAC.
Or using nothing :) which, for SPF purposes, is irrelevant... Though I'd
like to see SMTP AUTH there.
2): He sends mail through the SMTP server of his ISP, using
an envelope from address with a domain name of another ISP.
Barring explicit agreements between those ISP's, under SPF,
you can, indeed, no longer do that. That is, you cannot send
out mail using an SMTP server of AOL, using an
@mindspring.com address (unless, like I said, mindspring
published an SPF record which specifically allowed the AOL
SMTP server to relay mail for them; yeah, right).
3): He sends mail through the SMTP server of his ISP, with an
envelope from address using a domain name under his own DNS
control. Possible, but not ideal. Then you get the quandary
Mr. Harvey got himself into: in your own SPF records you need
to designate a third-party as 'trusted' to handle your mail.
SPF queries will be targeted at your own DNS, where you
designated your ISP's mail servers as trusted.
I would like to point out, though, that the Nr. 3 scenario is
unlikely, IMHO. I mean, if you run your own DNS, chances are
you run your own mail server too. Or, rather, if you let your
ISP handle all your Internet Services, why bother running
your own DNS?
I agree.
4): He sends mail through his own SMTP server, with an
envelope from address using a domain name under his own DNS
control. That, I reckon, is the ideal SPF situation. SPF
queries will be targeted against your own DNS, in which you
published SPF records that designate your own mail servers as trusted.
What category is your dad in? :)
Number 2 :P The one that becomes SOL under SPF :) Which, funnily enough,
starting from the days of ending open relays until a year ago or so, was the
generally accepted way of dealing with this situation. That's what bugs me
about SPF: the fact that, after all kinds of people were set up with the
"POP3 from wherever, SMTP through your local ISP" model, suddenly SPF makes
that obsolete and requires "wherever" to provide an SMTP AUTH-type relay. If
they don't feel like bothering with it... then I get to explain to my dad
why he can't use his perfectly functional POP3 client to send mail anymore
and needs to learn some webmail interface. For understandable reasons, this
is a conversation I'd prefer not to have.
I think the SPF + SMTP AUTH model is smarter than the "SMTP through your
local ISP" model, and had people proposed "replace open relays with SMTP
AUTH, then add SPF to the mix" at the time open relays got closed in 97 or
so, my objection to this scheme would go away. But now... after all kinds of
people were set up using #2, I don't like the idea of throwing that way out.
(I might add that my dad is not the only user of such setups: what about a
university student who still keeps his/her POP3 account through his/her
parents' ISP, and wants to send mail FROM: that account from the campus
network? SPF makes them SOL, too, unless the parents' ISP provides a relay
accessible from outside their network... and why would they?)
The worst (or best, depending on your POV) part of SPF is that it's so
ironclad... With the previous no-relay-for-non-local-IPs practice, if your
local ISP wouldn't relay mail with an envelope outside their domain (eg: my
dad's ISP did that for the first month of the post-(_at_)Home transition period,
then they changed their policy when they realized how many people depended
on option #2), you could always set up your own mail server (which, of
course, these days is rarely an option, thanks to widespread blocking of
end-user IP blocks) or use a third-party SMTP AUTH service (no shameless
plug here), possibly on a non-25 port. With SPF, you are literally stuck. If
you want to send mail from @isp.net, and isp.net doesn't want to provide you
with a relay to do it with, then there is absolutely NOTHING you can do
except bend to ISP.NET's way of wanting to do things. Of course, if we
punch holes (if that's even possible... which it isn't) to fix this problem,
SPF goes byebye in usefulness... hence why I said this is the worst and best
part.
I just hope that people realize that in the process of throwing the
spammers' bathwater out, this proposal is also likely to throw all kinds of
babies out for people who want to slightly "bend" the rules on their ISPs'
mail policies (lots of places allow POP3ing from outside... but don't
publicize it). If what people want is an AOL world of people using
ISP/employer-supported mail clients to send mail from ISP/employer-approved
IPs through ISP/employer-approved mail servers, then SPF is a fantastic way
of doing that. Meanwhile, Joe P. Spammer will just buy joepspammer.net (or
joepsmammer1.net, joepspammer2.net, etc), set up SPF records and a mechanism
for whatever trojaned machines he uses to update the SPF records, and people
in my dad's situation will keep getting their spam... but won't be able to
send legitimate email out anymore... And Joe P. Spammer gets a step closer
to turning the Internet into an exclusive delivery mechanism for his spam...
An aside I just thought of: has anyone considered spammers hacking into DNS
servers? If they want to send spam with a @isp.net return address, and
isp.net forgot to install the latest patches from their favourite OS vendor,
why not just hack into the DNS servers, modify the SPF records, and spam
away? Or, even better, find a DNS server that hosts lots of domains, and
break into that... and spam away. Sounds far fetched, but if someone two
years ago had told us spammers would be using zombies to relay their mail,
we would have found that far fetched, too. I hear spammers now try to find
weak passwords in SMTP AUTH systems, so why not do this, too?
Vivien
-------
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_)½§Åv¼ð¦¾Øß´ë ù1Ií-»Fqx(_dot_)com