You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ilan Aisic <il...@pointer.co.il> on 2004/03/08 17:42:31 UTC
Opinions About SPF
A friend pointed me to:
http://spf.pobox.com/
http://spf.pobox.com/wizard.html
Before I go and implement it in my DNS, I'd like to solicit opinions about
it from the list.
--ilan
RE: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 02:06 PM 3/8/2004, Nick Fisher wrote:
>As I understand it.... No. It's a social misunderstanding, thinking that
>the return address of any one piece of mail is authoritative. It was never
>meant to be
OK, from that standpoint... what about DSNs?
MegaSpamCorp sends out millions of messages spoofing
randomaddress@victim.com as the envelope sender. Many of those go to
addresses which are no longer valid, or which reject the obvious
spam. Many of *those* are either sent through relays or sent to servers
that accept the message, then generate a bounce instead of simply issuing
an SMTP redirect.
End result: thousands of invalid bounces deluge the mail server for
victim.com. (No, this is not hypothetical. I'm sure I'm not the only one
who can run "tail -f maillog | grep 'User unknown'" and watch the messages
scroll by.)
Note that no human is involved in this chain of events, except at the very
beginning (spammer hits "send.")
That *is* a technical problem, and it is something SPF, Caller-ID, Domain
Keys, DMP, RMX, etc. are trying to solve. The issue at hand, of course, is
which solution will be the best.
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by Dan Wilder <da...@ssc.com>.
On Mon, Mar 08, 2004 at 04:31:54PM -0800, Kelson Vibber wrote:
> At 03:04 PM 3/8/2004, Mark C. Langston wrote:
> >...which is not the recommendation of SPF. The default assumption is,
> >"no SPF record == bad, evil spammer."
>
> Not true. This is from the latest draft of the SPF RFC:
>
> 8.7 Rejection of non-SPF conformant email
>
> Mail from a domain SHOULD NOT be automatically treated as suspect
> just because the domain doesn't publish SPF records.
>
> Source: http://spf.pobox.com/spf-draft-20040209.txt
This policy likes me MUCH better!
So, if you want to masquerade your email from any wardriving
laptop or Internet Cafe in the world, don't publish SPF records,
and you're fine. At least if your recipients are RFC-compliant.
In this one respect SPF does not immediately introduce the
breakage some may feel it does. That's good.
--
Dan Wilder
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 04:31:54PM -0800, Kelson Vibber wrote:
> At 03:04 PM 3/8/2004, Mark C. Langston wrote:
> >...which is not the recommendation of SPF. The default assumption is,
> >"no SPF record == bad, evil spammer."
>
> Not true. This is from the latest draft of the SPF RFC:
>
> 8.7 Rejection of non-SPF conformant email
>
> Mail from a domain SHOULD NOT be automatically treated as suspect
> just because the domain doesn't publish SPF records.
>
> Source: http://spf.pobox.com/spf-draft-20040209.txt
>
Hm. In that case, Meng (or someone else) should bring the website up to
date with the draft.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 03:04 PM 3/8/2004, Mark C. Langston wrote:
>...which is not the recommendation of SPF. The default assumption is,
>"no SPF record == bad, evil spammer."
Not true. This is from the latest draft of the SPF RFC:
8.7 Rejection of non-SPF conformant email
Mail from a domain SHOULD NOT be automatically treated as suspect
just because the domain doesn't publish SPF records.
Source: http://spf.pobox.com/spf-draft-20040209.txt
--
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 02:49:22PM -0800, Dan Wilder wrote:
> If on the other hand you do:
>
> SPF Sent
> record from listed Suspect
> exists host spam
> ------- ----------- ---------
> no -- no
...which is not the recommendation of SPF. The default assumption is,
"no SPF record == bad, evil spammer."
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
RE: Opinions About SPF
Posted by Nick Fisher <ni...@itsinteractive.com>.
> SPF Sent
> record from listed Suspect
> exists host spam
> ------- ----------- ---------
> no -- no
> yes no yes
> yes yes no
>
> you won't get any FPs just 'cause there's no record.
> On the other hand you may eliminate some spam coming
> from folks who forge the addresses of domains where
> there _are_ SPF records.
>
This overlooks the root of the problem....
Domain A: SPF + SRS
Domain B: No SPF or SRS
Domain C: SPF + SRS
Now if I'm in domain A and I send mail to someone in domain B and that
forwards to someone in domain C.... The mail will appear to be spam. It will
come from a domain with SPF but SRS will not have been followed all the way
through the message's path. So when it hits domain C and the SPF is
checked.....
Untill all the worlds SMTP servers know and use SRS, SPF will generate false
positives. There is no way (that I can see) around that. I put this to the
guy who proposed SPF and he agreed with me.
Nick
Re: Opinions About SPF
Posted by Dan Wilder <da...@ssc.com>.
On Mon, Mar 08, 2004 at 05:06:39PM -0500, Nick Fisher wrote:
> Frankly I doubt that SPF will really be of much use as SRS had to be
> implemented on all of the net before SPF will stop generating false
> positives. A major downside.
Depends how you define a "positive". What you seem to be
thinking of is:
SPF Sent
record from listed Suspect
exists host spam
------- ----------- ---------
no -- yes
yes no yes
yes yes no
which is obviously not a great idea.
If on the other hand you do:
SPF Sent
record from listed Suspect
exists host spam
------- ----------- ---------
no -- no
yes no yes
yes yes no
you won't get any FPs just 'cause there's no record.
On the other hand you may eliminate some spam coming
from folks who forge the addresses of domains where
there _are_ SPF records.
--
Dan Wilder
Re: Opinions About SPF
Posted by Bob Apthorpe <ap...@cynistar.net>.
Hi,
On Mon, 8 Mar 2004 13:55:25 -0800 "Mark C. Langston" <ma...@bitshift.org> wrote:
[snip]
> Further, one does not invite attack on an equally (some would argue
> more) insecure protocol if one can avoid it.
>
> Lastly, one does not address all these issues by waving one's hands and
> saying, "simply rearchitect your SMTP and DNS deployments."
>
> I'm glad DNS attacks have fallen by the wayside. I've no great desire
> to see them become popular again.
Such is the nature of a dynamic system; if we find effective defenses
for the current spectrum of attacks, the attackers will respond by
changing tactics. It's unavoidable, expected, and perfectly natural.
However, it's not SPF's fault that DNS is still vulnerable after how
many years of the DNSSEC spec being on the books. If SPF is the
straw(man) that breaks the camel's back to get DNSSEC implemented, is
that such a bad thing, long term?
I've been silently predicting we'll see two tiers of mail service
develop - the unencumbered, easy, simple, and utterly choked with trash
level of service, and the fully-authenticated, accountable, proper f-
and rDNS, RFC-2142 compliant,
takes-more-than-two-firing-neurons-to-deploy level of service. Both can
coexist, but the latter will be a bit more like FedEx compared to the
Postal Service. You will pay more for the latter, moreso in required
skill and labor than (hash)cash, but will you get much faster, more
reliable delivery. The transition will be slow and graceful and will
require evolutionary changes to assumptions, protocols, architecture,
and behavior, but it will happen. I see designated sender protocols such
as SPF as being part of this evolutionary transition.
SPF addresses a specific problem and by doing so inevitably comes with
the cost of invalidating previous assumptions and forcing changes in
architecture and behavior. If SPF breaks mail sent from mobile phones
_under the current model_, the mobile phone providers or users will find
a workaround or SPF won't find wide adoption. Either the model will
change or SPF will. As in evolution, the behavior that results in the
highest ratio of legitimate mail being successfully delivered the
fastest will survive, the other behaviors may survive but they won't
prosper except in isolated cases.
> There's no need to push this out the door and implement today. When an
> appropriate (read: does not break major aspects of existing email use)
> solution is ready, the spammers will still be waiting.
Better to push out SPF now, find out where it fails, fix it, and try
again until something better comes along. I believe Patton's quote "The
best is the enemy of the good"[1] is applicable here. Deploy a better
system now and SPF will be a non-starter.
SPF has its problems but for a great many systems the benefits of
stopping spoofing far outweigh the costs of breaking forwarding. Like
greylisting, it's a stopgap measure until better means can be deployed.
IMHO we lose more by doing nothing.
-- Bob
[1] From Patton: "Don't Delay - The best is the enemy of the good. By
this I mean that a good plan violently executed now is better than a
perfect plan next week. War is a very simple thing, and the determining
characteristics are self-confidence, speed, and audacity. None of these
things can ever be perfect, but they can be good." Apparently "The best
is the enemy of the good" is a quote from Voltaire but to be honest, I
can't find it in context to give it proper meaning; Patton's quote
captures my intent.
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 01:39:38PM -0800, Kelson Vibber wrote:
> At 12:16 PM 3/8/2004, Mike Zanker wrote:
> >Well put, Mark - I agree 100%. Yet another technical solution for a
> >non-technical problem.
>
> So the ease with which a spammer can forge your domain name isn't a
> technical problem?
>
The breaking of several major uses of smtp is a technical problem.
One does not solve a technical problem by creating other technical
problems if at all avoidable.
Further, one does not invite attack on an equally (some would argue
more) insecure protocol if one can avoid it.
Lastly, one does not address all these issues by waving one's hands and
saying, "simply rearchitect your SMTP and DNS deployments."
I'm glad DNS attacks have fallen by the wayside. I've no great desire
to see them become popular again.
There's no need to push this out the door and implement today. When an
appropriate (read: does not break major aspects of existing email use)
solution is ready, the spammers will still be waiting.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
RE: Opinions About SPF
Posted by Nick Fisher <ni...@itsinteractive.com>.
> >Well put, Mark - I agree 100%. Yet another technical solution for a
> >non-technical problem.
>
> So the ease with which a spammer can forge your domain name isn't a
> technical problem?
>
As I understand it.... No. It's a social misunderstanding, thinking that the
return address of any one piece of mail is authoritative. It was never meant
to be. It's like assuming that the return address on a piece of snail mail
is where the mail came from...... not so.... For that you look at the
postmark. Therefore you cannot (technically) forge a return address, on
snail mail or email. To forge would be to assume that the original data was
authoritative. So.... kludging the mail system to match social
misconceptions is a technical solution to a non-technical problem. QED.
However I can easily understand how others don't see it that way.
Frankly I doubt that SPF will really be of much use as SRS had to be
implemented on all of the net before SPF will stop generating false
positives. A major downside.
I feel kinda odd saying this but I actually like the MS 'Caller ID for
email' plan better. Ok the name sux and it's the great satan... but
technically it's SPF tweeked to work within the confines of email RFCs. The
MS plan deals with the auth by leaving a breadcrumb trail of headers. By
adding headers to track the path of the email, rather than munging the
envelop-sender the MS plan avoids alot of the problems that SPF makes.
Namely those of anyone who forwards or redirects email having to mung the
envelope-sender.
Nick
Re: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 12:16 PM 3/8/2004, Mike Zanker wrote:
>Well put, Mark - I agree 100%. Yet another technical solution for a
>non-technical problem.
So the ease with which a spammer can forge your domain name isn't a
technical problem?
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by Mike Zanker <mi...@zanker.org>.
On 08 March 2004 10:05 -0800 "Mark C. Langston" <ma...@bitshift.org>
wrote:
[snip]
> In short, it destroys the ability to send email from anything other
> than the domain name of your ISP.
Well put, Mark - I agree 100%. Yet another technical solution for a
non-technical problem.
Mike.
Re: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 10:05 PM 3/8/2004, Jeff Makey wrote:
>Perhaps my biggest objection to SPF is the dishonest way it is marketed as
>an anti-spam tool
Marketed by whom? http://spf.pobox.com focuses heavily on the anti-forgery
aspects.
"SPF fights email address forgery and makes it easier to identify spams,
worms, and viruses when domain owners designate sending mail servers in DNS..."
You may want to look at the "What SPF Is Not" section at
http://spf.pobox.com/intro.html
>it is nothing more than a weak anti-joe-job tool.
Well, whether it's weak or not is debatable - the length of this thread
proves that - but the project's own site states that its goal is to stop
joe-jobs.
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by Kjetil Kjernsmo <kj...@kjernsmo.net>.
On Tuesday 09 March 2004 12:47, Alex van den Bogaerdt wrote:
> Wow. You mean finally the owners^Wpeople paying the bill have
> an incentive to either install a firewall theirselves or pay
> someone to do this for them. This as opposed to shifting the
> costs elsewhere...
Well, the problem is the cost of maintaining a mailing list.... I guess
you could have some sort of whitelisting, but I'd rather see Bill Gates
sued for the damages he inflicts on others and thereby create an
incentive to fix things, rather than having to cope with this...
But I live in a dreamworld, I know... :-)
Cheers,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net webmaster@skepsis.no editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 07:10:03PM -0500, Theo Van Dinter wrote:
> On Mon, Mar 08, 2004 at 03:48:48PM -0800, Mark C. Langston wrote:
> > I never demanded spoofing be corrected. I spoof daily for various
> > legitimate reasons, as do many others. It's convenient; it breaks
> > nothing.
>
> Absolutely true, and you can feel free to keep doing that for as long
> as you want. If you want to accept mail from everyone and everything,
> that's your decision. SPF is not required and unless it becomes part
> of the SMTP protocol, will never be required.
I should also point out in the interest of disclosure that I advertise
SPF records for this domain, and have for several weeks. I'm somewhat
surprised to find that I still get bounces from AOL from
spammer-originated spoofing.
And, since I am advertising -all, there should be no question as to what
is and isn't valid (although spfquery seems to guess at "neutral" for
obvious violations, which just baffles me no end.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by "Keith C. Ivey" <kc...@cpcug.org>.
Jonathan Tai <jo...@tgpsolutions.com> wrote:
> At least SPF prevents MOST joe-jobs... ie. joe-jobs from every
> other ISP in the world.
You mean SPF *will* prevent most joe jobs at some hypothetical
future time when everyone else starts using it. Maybe SPF
proponents aren't responsible for the idea that SPF is about
stopping spam, but they do seem to be responsible for
exaggerating the benefits of adopting it to prevent forgeries.
Right now, regardless of whether you use SPF, you're still
going to get all those AOL bounce messages when someone uses
one of your addresses for spamming.
--
Keith C. Ivey <kc...@cpcug.org>
Washington, DC
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Tue, Mar 09, 2004 at 04:02:35PM -0800, John Hardin wrote:
> On Tue, 2004-03-09 at 15:48, Mark C. Langston wrote:
> > > > With things like SPF, you'll either have to whitelist the entire set of
> > > > dynamic IP blocks the provider uses
> > >
> > > "v=spf1 include:verizon.net"
> >
> > Great. Now everyone from all of Verizon's services can forge email as
> > me.
>
> My solution (I control my DNS server) would be to update my SPF TXT
> record automatically whenever my dynamic IP changes. I'm already doing
> this with A records so I can get to my home network from the office.
>
...which is a solution I suggested elsewhere in this thread. However,
it still won't be feasible for cellular devices, save perhaps Palm and
Wince-based smartphones.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Tue, 2004-03-09 at 15:48, Mark C. Langston wrote:
> Great. Now everyone from all of Verizon's services can forge email as
> me. That's as unacceptable as "v=spf1 include:comcast.net", for much
> the same reason.
>
> If the proposed plan is designed to stop joe-jobs, and if said plan
> breaks certain functionality, the solution to being able to retain that
> functionality is not "allow joe-jobs".
You have to make a choice. If you want to relay mail via your Verizon
cell phone for your non-Verizon e-mail address, you have to allow
Verizon to relay for your domain. If that's not acceptable because
spammers could potentially spoof mail because they're on Verizon, take
the time to set up SMTP AUTH or POP-before-SMTP or set up a dynamic IP
address solution like some others have mentioned.
Or, you have to suffer joe-jobs.
Sitting here and whining that SPF doesn't solve all your problems
without you doing any work won't get anybody anywhere. At least SPF
prevents MOST joe-jobs... ie. joe-jobs from every other ISP in the
world.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by John Hardin <jo...@aproposretail.com>.
On Tue, 2004-03-09 at 15:48, Mark C. Langston wrote:
> > > With things like SPF, you'll either have to whitelist the entire set of
> > > dynamic IP blocks the provider uses
> >
> > "v=spf1 include:verizon.net"
>
> Great. Now everyone from all of Verizon's services can forge email as
> me.
My solution (I control my DNS server) would be to update my SPF TXT
record automatically whenever my dynamic IP changes. I'm already doing
this with A records so I can get to my home network from the office.
Granted, if you are using an ISP-hosted DNS service with a simplified
web interface that might not be an option.
--
John Hardin KA7OHZ
Internal Systems Administrator/Guru voice: (425) 672-1304
Apropos Retail Management Systems, Inc. fax: (425) 672-0192
-----------------------------------------------------------------------
If you smash a computer to bits with a mallet, that appears to count
as encryption in the state of Nevada.
- CRYPTO-GRAM 12/2001
-----------------------------------------------------------------------
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Tue, Mar 09, 2004 at 02:14:03PM -0800, Jonathan Tai wrote:
> On Tue, 2004-03-09 at 12:53, Mark C. Langston wrote:
> > ...and what if the cell user wishes to send email using a
> > long-established address rather than having to use (and expecting others
> > to remember) yet another address? When will we see cell mail clients
> > capable of STARTTLS, POP-before-SMTP, MSA, or SMTP AUTH?
> >
> > With things like SPF, you'll either have to whitelist the entire set of
> > dynamic IP blocks the provider uses
>
> "v=spf1 include:verizon.net"
>
> Done.
>
> - Jon
>
Great. Now everyone from all of Verizon's services can forge email as
me. That's as unacceptable as "v=spf1 include:comcast.net", for much
the same reason.
If the proposed plan is designed to stop joe-jobs, and if said plan
breaks certain functionality, the solution to being able to retain that
functionality is not "allow joe-jobs".
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 06:23:54PM -0800, Jonathan Tai wrote:
> People's cell phones don't connect to the recipient MX and drop off mail
> directly, do they? They will be relaying through their cell provider's
> network. As long as their cell provider publishes a SPF record, I don't
> see how mail from cell phones will break.
... actually the solution there is more of the envelope from being the
actual cell phone email addr, but the header from being whatever the
sender wants. :)
--
Randomly Generated Tagline:
"That thing [the space shuttle] has the glide slope of a brick."
- Joe Ruga at LISA '99
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Mon, 2004-03-08 at 16:26, Mark C. Langston wrote:
> On Mon, Mar 08, 2004 at 07:10:03PM -0500, Theo Van Dinter wrote:
> >
> > Overall, I think most people would prefer stopping spoofing as it makes
> > stopping spam a lot easier (black/whitelists become a LOT simpler and
> > reliable), as long as there are reasonable work arounds for times when
> > spoofing was used. SMTP AUTH + TLS solves a lot of that imho, but it
> > of course requires people to set that up.
For sites too small to set up SMTP AUTH or POP-before-SMTP, there should
be a relatively small number of users and you can put SPF records for
each user's ISP.
For sites too large to list every "blessed server", implementing SMTP
AUTH or POP-before-SMTP shouldn't be a problem.
> And here, you and I differ. I think "most people" don't even know this
> is coming, and when it gets here, "most people" are going to be anywhere
> from mildly irritated to furious that their email no longer works from
> their cellphone/smartphone, their laptop at the local Starbucks, the
> hotspots in the airport, their laptop->cellphone net connection, their
> hotel rooms, their client sites, and so forth.
People's cell phones don't connect to the recipient MX and drop off mail
directly, do they? They will be relaying through their cell provider's
network. As long as their cell provider publishes a SPF record, I don't
see how mail from cell phones will break.
Same goes for laptops, etc. as long as they pick an MX and stick with
it, everyone should be fine. When you sit at Starbucks, who do use as
your relay? Starbucks' mail server?
> "Most people" are going to wonder why they can't send an eCard to
> grandma on Mother's Day. "Most people" are going to wonder why the IT
> department is making yet another apparently unnecessary change to their
> work day yet again, when they'd just gotten used to the last major
> behavioral change that was foisted upon them.
It comes down to setting up SMTP AUTH or POP before SMTP. IT
departments will set this up for "most people" - there is no behavioral
change.
> And yes, eliminating spoofing will stop some spam. It will not,
> however, stop all spam. And that's what "most people" expect, and what
> "most people" demand. If we keep uprooting "most people" every time we
> make what amounts to an incremental change, we will completely burn
> through whatever remaining cachet we've got with "most people".
Like you said, it helps stop spam. And what's more important... it
stops spammers from pretending to be me.
> "Most people" want email to work as easily as possible. "Most people"
> do not want the hoops they have to jump through changing every six
> months. And if "most people" are promised a panaca iff they jump
> through one more hoop, and discover they were misled once they reach the
> other side (and I'm fairly confident that the accurate description of
> the impact will be "this'll stop all spam" by the time it filters down
> to "most people"), they'll be rather upset.
Yes, there is a danger to promoting SPF as an end-all to spam. As
mentioned earlier, it's more effective against joe-jobs than it is
against spam. So if SPF is advertised as an end-all to spam, people
*will* be upset. So don't advertise SPF as something it's not.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 09:58:24PM +0000, Clive Eisen wrote:
>
> sony-erricsson p900 does smtp-auth
That's a single model out of dozens, if not hundreds. And it's a
PalmOS smartphone, which I pointed out earlier is a bit of a special
case in my argument, because OSS authors are likely to be able to
quickly provide a solution.
That's not true of most phones.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Dan Wilder <da...@ssc.com>.
On Thu, Mar 11, 2004 at 10:16:13AM -0800, Mark C. Langston wrote:
> On Thu, Mar 11, 2004 at 09:18:10AM -0800, Dan Wilder wrote:
> >
> > But who also want, or will soon want, to be free of the burden of
> > exponentially increasing spam. The two objectives cannot both be attained.
> >
>
>
> So, your position is that we should surrender the liberties we now enjoy
> for additional security? A large part of me says that the two need not
> be mutually exclusive.
That isn't my position.
My position is there's no prior reason to assume there is no tradeoff.
In some cases, certainly there isn't. In the cases where a tradeoff
is present, what may be acceptable is always a legitimate subject for
discussion.
However this thread has gone on for an awful long time, and is
at this point very far off-topic. I've said my piece and will
now be quiet.
--
Dan Wilder
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Thu, Mar 11, 2004 at 09:18:10AM -0800, Dan Wilder wrote:
>
> But who also want, or will soon want, to be free of the burden of
> exponentially increasing spam. The two objectives cannot both be attained.
>
So, your position is that we should surrender the liberties we now enjoy
for additional security? A large part of me says that the two need not
be mutually exclusive.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Dan Wilder <da...@ssc.com>.
On Wed, Mar 10, 2004 at 04:37:00PM -0800, Mark C. Langston wrote:
> On Wed, Mar 10, 2004 at 04:29:02PM -0800, Dan Wilder wrote:
> >
> > - Mark doesn't have any idea how to insert a "Reply-To:" header
> > in his email giving to his AOL address, or else his correspondents
> > use MTAs with no shred of support for this very ancient and
> > well-honored header.
>
> Mark has every clue about how to insert and correctly use a Reply-To:
> header. Many MUAs, including many of those on mobile devices, don't
> allow the user to insert said header.
I didn't mean you! Some generic "Mark." I should have called him "Dan."
> As I just mentioned, we (those of us having this discussion) are not the
> ones who'll be penalized unduly by the changes wrought by SPF or similar
> approaches. It's the vast majority of end-users who don't have our
> technical knowledge, but who want the freedom and flexibility they see
> us enjoying.
But who also want, or will soon want, to be free of the burden of
exponentially increasing spam. The two objectives cannot both be attained.
--
Dan Wilder
Re: Opinions About SPF
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Wed, 10 Mar 2004, Mark C. Langston wrote:
> Mark has every clue about how to insert and correctly use a Reply-To:
> header. Many MUAs, including many of those on mobile devices, don't
> allow the user to insert said header.
>
> Many more end-users are completely unaware of the existence of this
> header, let alone how and when to use it, and/or how to get their mail
> MUA to insert one.
>
> As I just mentioned, we (those of us having this discussion) are not the
> ones who'll be penalized unduly by the changes wrought by SPF or similar
> approaches. It's the vast majority of end-users who don't have our
> technical knowledge, but who want the freedom and flexibility they see
> us enjoying.
>
> "end-user education" has not been, is not, and never will be an adequate
> answer to the question, "well, how to you propose overcoming this
> problem here?" If it were, viruses and spam would be a non-issue today.
And I don't bother trying to explain CSS, SOAP, XML to my mother when
I tell her that her 100MHz computer running Netscape 3.0 will no longer
work when she tries to do her on-line banking. That she just needs
to get a newer machine because the bank udated its systems.
What about all those cell phone users who bought analog phones?
Do you try to explain the technical details of the FOUR different
competing/incompatible digital cell phone transmission methods to
your parents?
Technology advances, time marches on, last weeks gear is obsolete,
people grumble but they -do- upgrade.
Now, this whole argument is a bit silly. All that is needed is
for those mobile device service providers to make sure that their
gateways set the envelope-from to point to thier own servers and
put the user's prefered 'from' address into the header-from.
That will satisfy the SPF requirements and the message recipients
will see the expected 'From:' address.
If you want to gripe about the bounce issue, the mobile service
provider can handle that too. All they need to do is to have some
kind of database that notes the senders prefered 'From:' address
and will route any bounces that hit the envelope-from to that
prefered 'From:' address.
Heck the MSP can even advertise this as a featured service to
attract new customers.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 04:29:02PM -0800, Dan Wilder wrote:
>
> - Mark doesn't have any idea how to insert a "Reply-To:" header
> in his email giving to his AOL address, or else his correspondents
> use MTAs with no shred of support for this very ancient and
> well-honored header.
Mark has every clue about how to insert and correctly use a Reply-To:
header. Many MUAs, including many of those on mobile devices, don't
allow the user to insert said header.
Many more end-users are completely unaware of the existence of this
header, let alone how and when to use it, and/or how to get their mail
MUA to insert one.
As I just mentioned, we (those of us having this discussion) are not the
ones who'll be penalized unduly by the changes wrought by SPF or similar
approaches. It's the vast majority of end-users who don't have our
technical knowledge, but who want the freedom and flexibility they see
us enjoying.
"end-user education" has not been, is not, and never will be an adequate
answer to the question, "well, how to you propose overcoming this
problem here?" If it were, viruses and spam would be a non-issue today.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Dan Wilder <da...@ssc.com>.
On Wed, Mar 10, 2004 at 06:08:35PM -0600, Bob Apthorpe wrote:
> Hi,
>
> On Wed, 10 Mar 2004, Kelson Vibber wrote:
>
> > At 02:58 PM 3/10/2004, Mark C. Langston wrote:
> > >With SPF, I can decide whether or not MY domains use SPF. However, I have
> > >no control over whether the service currently providing my IP transit is
> > >using SPF, and thus whether any mail sent by me while using
> > >that transit is going to be affected by SPF (e.g., transparent proxies).
> >
> > I think you're misunderstanding something. The publishing side of SPF
> > resides solely in your DNS server. The verification side resides solely in
> > the receiving mail server. The outgoing SMTP server doesn't care about SPF.
>
> I believe that what Mark is getting at is that if
>
> - he prefers (say) to use his AOL address everywhere and
>
> - he sends mail using his AOL address through Earthlink's server, and
>
> - AOL publishes restrictive ("v=spf1 mx -all") SPF records
And
- Mark doesn't have any idea how to insert a "Reply-To:" header
in his email giving to his AOL address, or else his correspondents
use MTAs with no shred of support for this very ancient and
well-honored header.
...
> then any system that makes delivery determinations based on SPF would
> refuse, drop, or badly score his mail. Essentially, he's screwed because
> he doesn't control spoofing policy for his AOL address, AOL does. And
> that's a problem, at least for him and for everyone else relying on the
> current model of lax spoofing policy.
Unless he uses "Reply-To:" instead of attempting to spoof.
Am I missing something terribly obvious here? Mailing lists that
arrogate the destruction and replacement of existing "Reply-To:" headers?
--
Dan Wilder
Re: Opinions About SPF
Posted by Alex van den Bogaerdt <al...@ergens.op.het.net>.
On Wed, Mar 10, 2004 at 02:58:31PM -0800, Mark C. Langston wrote:
> With SPF, I can decide whether or not MY domains use SPF. However, I
> have no control over whether the service currently providing my IP
> transit is using SPF, and thus whether any mail sent by me while using
> that transit is going to be affected by SPF (e.g., transparent proxies).
Ahhhaaaa. You are worried about loosing the ability to force your
thoughts upon other peoples policy.
Yes, you are correct. When you spoof someone else's domain name
and when that domain does not allow you to do so, third party gateways
may opt to block your message.
Easy way around it: use your own domain and set a policy for that domain
yourself. Try "v=spf1 +all".
> So, it boils down to a control issue. With SA, I have control, and when
> I don't have control, the worst that happens is that I'm inconvenienced
> by my email going to a folder I wasn't expecting.
> Imagine for a second that almost every MX on the planet implemented rDNS
> checks. Now imagine that your ISP suddendly botched their rDNS zones,
> and didn't fix them. Your mail starts bouncing, you weren't expecting
> it to, you weren't aware that the problem existed, and you're powerless
> to change the situation (except to change providers).
So? Imagine that your provider does one of the 1001+ other things it
could do wrong. Shit happens.
Using this kind of arguments means you want to get rid of every
protocol the Internet is built on. The "things can go wrong so
this protocol is breaking stuff" is valid for many RFCs.
> (Of course, I'm one of those strange people that seems to think that a
> client connecting directly to the destination MX is still fine. I think
> some of the SPF proponents may be operating under the assumption that
> any and all email should always be handed off through a smarthost
> somewhere, so that only MXes ever talk to MXes.)
If you are connecting to my MX, and if the domain name you are using in
your envelope_from is allowing your IP address, you would not be blocked.
If you are connecting to my MX, and if the domain name you are using in
your envelope_from is NOT allowing your IP address, you WILL be blocked.
See? You _are_ in control.
Either you use _your_ domain and set _your_ DNS records correct, or
you use someone else's domain and _they_ edit DNS. By doing so, they
are authorizing you do use _their_ domain name from _your_ computer.
The current setup @aol does allow you to use "yourname@aol.com" in
the envelope. Would they change "?all" into "-all", they are saying
you MUST not use their domain from your IP address.
SPF gives control back to aol and you seem to dislike that. Just
make sure your envelope_sender is NOT using THEIR name and you'll
be fine.
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags
Re: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 04:01 PM 3/10/2004, Mark C. Langston wrote:
>would you put comcast.net in your allow: for tcpwrappers to enable a
>single person access to your machines?
Of course not. There have been better solutions available for a long time.
>If not, then why would you allow an entire ISP the privilege of
>joe-jobbing your address?
Because it's better than letting the entire Internet do it, which is the
way it works right now.
I don't think SPF is going to be the be-all and end-all of anti-spoofing,
anti-spam, or anti-anything. But it's better than nothing, and while there
are other schemes out there, SPF is the first to get this level of
widespread testing. It's a stop-gap measure, but I'd rather implement a
stop-gap now and a better solution two years from now than wait two years
before doing anything.
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 03:23:52PM -0800, Kelson Vibber wrote:
> At 02:58 PM 3/10/2004, Mark C. Langston wrote:
> >With SPF, I can decide whether or not MY domains use SPF. However, I have
> >no control over whether the service currently providing my IP transit is
> >using SPF, and thus whether any mail sent by me while using
> >that transit is going to be affected by SPF (e.g., transparent proxies).
>
> I think you're misunderstanding something. The publishing side of SPF
> resides solely in your DNS server. The verification side resides solely in
> the receiving mail server. The outgoing SMTP server doesn't care about SPF.
>
Right. So let's take a real-world scenario here. I have a cellphone.
That cellphone has an honest-to-Ghu email client on it. I've got it
configured to send and receive email for $MYACCOUNT@$BIG_CABLECO.com.
So, I write an email and send it to bob@example.com.
That cellphone provider thinks it best to put a transparent SMTP proxy
between my email client and example.com's MX.
$BIG_CABLECO advertises SPF for $BIG_CABLECO.com.
$CELLPHONE_PROVIDER delivers mail purportedly from $BIG_CABLECO.com
directly to bob@example.com, because cellphone mail clients don't have
much clue about relaying outbound mail via servers other than those the
cellphone provider wants you to use.
Mail bounces, because $BIG_CABLECO's SPF records swear that mail's
invalid.
Now, substitute $CELLPHONE_PROVIDER with
$AIRPORT_WIRELESS_ACCESS_COMPANY. With
$HOTEL_HIGHSPEED_NET_ACCESS_COMPANY. With any other situation I've
listed earlier.
Substitute $BIG_CABLECO with $BIG_CORPORATION_FOR_WHOM_I_WORK. With
$HOSTING_COMPANY_THAT_DOESN'T_GIVE_ME_CONTROL_OVER_TXT_RECORDS.
The only way this isn't a problem is if *I* own the RHS of the email
address I want to use, and have full control over the DNS advertising
it.
Relatively few consumers do that.
> If you're connected to Earthlink, and you send mail using your domain name
> and Earthlink's SMTP server to someone at AOL, it doesn't matter whether
> Earthlink has implemented SPF, SRS, or anything else. The only things that
> matter are: (1) Are you publishing SPF information? (2) Is AOL checking SPF
> information?
>
Right. That's the scenario in which I'm the owner of the domain I wish
to use (and further assumes I have control over the DNS entries for said
domain, including the ability to add TXT records. Many, many domain
parking/hosting companies don't allow end-users that level of control
over their zone).
> OK, one other thing: (1a) Is your SPF information accurate? That may be an
> issue if your provider isn't forthcoming, which may be what you were trying
> to get at. In this case, you're actually better off if your provider
> publishes its own SPF record, because you can then just set yours to
> include theirs, and you don't have to worry about whether they redesign
> their network.
>
And here, again, is a solution that requires what equated to
whitelisting the entire ISP's customer base as valid to send for the
domain I wish to use. As I asked another user offlist, would you put
comcast.net in your allow: for tcpwrappers to enable a single person
access to your machines? If not, then why would you allow an entire ISP
the privilege of joe-jobbing your address?
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 06:08:35PM -0600, Bob Apthorpe wrote:
> Hi,
>
> I believe that what Mark is getting at is that if
>
[...snip!]
Thanks, Bob. That's more or less exactly what I'm trying to get at.
The reason is this: We, as people quite comfortable with technology,
are not only able to see the pitfalls in such technology, but the
workarounds as well. We can overcome whatever roadblocks such changes
may create for us.
The average consumer can't.
This wouldn't be a problem, except for a few things:
1) Companies are pushing more and more these days the type of
flexibility and freedom the rest of us have enjoyed for a while. What
used to take geek brow-sweat has become packaged and marketed glitz, and
it's starting to get quite popular with the lowest common denominator
consumer -- both those who buy because they need/want the function, and
those who simply have to have the hot new gadget, and become enamoured
of the flexibility they discover once they have it.
2) Products like cellphones and other "packaged" devices don't keep up
with the cutting, or even the leading edge of technology when it comes
to things like changes in SMTP protocol. It's not their bailiwick.
They're putting out devices with features customers want, but until the
majority of the consumer base is screaming about lack of SMTP AUTH and
the ability to send directly to their smart relay rather than via the
provider's transparent proxy and then directly to the receiving MX, they
won't build that particular nicety in. And the odds of that happening
anytime soon are pretty much zero.
Unfortunately, the odds of SPF, or one of the other competing
approaches, catching on sometime soon are much greater than zero.
The same holds true for things like 802.11b/g: everyone wants it these
days, many people are using it, but few are aware of things like
transparent (or opaque) SMTP proxies, and the implications of their use.
The end-users don't want to have to reconfigure their email client every
time they change locations (ask anyone who does corporate user support
for folks who use Earthlink from home or while on the road; telling them
"that's just the way things are" and having them reconfigure their mail
client to work with or around their port 25 block is a certain ticket to
an earful.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Alex van den Bogaerdt <al...@ergens.op.het.net>.
On Wed, Mar 10, 2004 at 06:08:35PM -0600, Bob Apthorpe wrote:
> > At 02:58 PM 3/10/2004, Mark C. Langston wrote:
> > >With SPF, I can decide whether or not MY domains use SPF. However, I have
> > >no control over whether the service currently providing my IP transit is
> > >using SPF, and thus whether any mail sent by me while using
> > >that transit is going to be affected by SPF (e.g., transparent proxies).
> >
> > I think you're misunderstanding something. The publishing side of SPF
> > resides solely in your DNS server. The verification side resides solely in
> > the receiving mail server. The outgoing SMTP server doesn't care about SPF.
>
> I believe that what Mark is getting at is that if
>
> - he prefers (say) to use his AOL address everywhere and
>
> - he sends mail using his AOL address through Earthlink's server, and
>
> - AOL publishes restrictive ("v=spf1 mx -all") SPF records
>
> then any system that makes delivery determinations based on SPF would
> refuse, drop, or badly score his mail. Essentially, he's screwed because
> he doesn't control spoofing policy for his AOL address, AOL does. And
> that's a problem, at least for him and for everyone else relying on the
> current model of lax spoofing policy.
This is *only* envelope spoofing. AOL has every right to deny Mark to
cause problems for AOL. AOL is the one processing the bounces if Mark
is doing something wrong. Could be as silly as "mrak@aol.com".
Easy way out: use your/a local address as envelope sender (RFC821), use
your aol address in "From:" (the RFC822 part).
This is something that can be implemented at the MUA and/or the MTA. Where
it is best to do so depends on the setup. It is something the systems
administrator can do; no user intervention needed.
This is, BTW, a solution for the forwarding problem as well. If your
MTA is sending messages to my MTA, I will deliver the resulting bounce
to your MTA and NOT TO $innocent_third_party.
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Wed, 2004-03-10 at 14:58, Mark C. Langston wrote:
> Imagine for a second that almost every MX on the planet implemented rDNS
> checks. Now imagine that your ISP suddendly botched their rDNS zones,
> and didn't fix them. Your mail starts bouncing, you weren't expecting
> it to, you weren't aware that the problem existed, and you're powerless
> to change the situation (except to change providers).
Stuff like that happens all the time. If someone on my subnet spams and
gets our class C listed in a RBL, my mail starts bouncing. I'm
powerless to stop it unless I change providers.
> THAT scenario is very much like the one SPF will create: end-user
> ignorance of the change, violation of end-user expectation w.r.t.
> delivery, and complete end-user powerlessness over the situation, except
> to change providers.
Again, this already happens every day with RBLs. So why is SPF being
criticized as a poor solution to a non-existent problem, but RBLs are
okay to use?
> What I'm against is the nave assumption that once SPF is
> deployed, people will simply, quietly, and willingly go to the
> (sometimes rather great) lengths necessary to upgrade their servers to
> accomodate these, and change the configuration of all their deployed
> clients to take advantage of these changes.)
SPF won't cause people to go through the great lengths necessary to
upgrade their servers and clients, but spam, viruses, and forgeries
will. There are studies that claim spam makes up 60%+ of the Internet's
e-mail traffic. As that number continues to increase, people will
*have* to upgrade their servers to support anti-spam/virus/forgery
measures, or else the signal to noise ratio will continue to drop until
e-mail is useless.
Again, it isn't a magic bullet, but SPF helps. Don't write it off as
nothing just because it isn't perfect in every scenario.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by Bob Apthorpe <ap...@cynistar.net>.
Hi,
On Wed, 10 Mar 2004, Kelson Vibber wrote:
> At 02:58 PM 3/10/2004, Mark C. Langston wrote:
> >With SPF, I can decide whether or not MY domains use SPF. However, I have
> >no control over whether the service currently providing my IP transit is
> >using SPF, and thus whether any mail sent by me while using
> >that transit is going to be affected by SPF (e.g., transparent proxies).
>
> I think you're misunderstanding something. The publishing side of SPF
> resides solely in your DNS server. The verification side resides solely in
> the receiving mail server. The outgoing SMTP server doesn't care about SPF.
I believe that what Mark is getting at is that if
- he prefers (say) to use his AOL address everywhere and
- he sends mail using his AOL address through Earthlink's server, and
- AOL publishes restrictive ("v=spf1 mx -all") SPF records
then any system that makes delivery determinations based on SPF would
refuse, drop, or badly score his mail. Essentially, he's screwed because
he doesn't control spoofing policy for his AOL address, AOL does. And
that's a problem, at least for him and for everyone else relying on the
current model of lax spoofing policy.
One solution is to implement MSAs with SMTP AUTH, and send AOL-addressed
mail through AOLs servers via an authenticated channel but again, that
depends on his client supporting SMTP AUTH, intervening firewalls allowing
the traffic, and AOL's willingness/ability to set up an MSA farm.
Woe to he who has an ISP whose administrators are unresponsive, lazy,
overworked, clue resistant, or technically challenged (which is pretty
much all of them.)
The infrastructure is under attack by spammers and must either adapt or
die. Think of SPF as a prehensile tail; it allows you to swing from trees
at the expense of saddling you with yet another appendage the carnivores
can grab ahold of in order to eat you. If you're a clam, the tail might
not help your chances of survival; if you're a monkey, it might. Clams and
monkeys don't have much say in the matter of whether they have a tail;
Mark's complaint (as I understand it within this stupid analogy) is that
tails will obviously make things worse for the clams and it's
irresponsible to give them tails without also giving them feet or teeth or
lasers, etc., to balance out their survivability. Shrugging and saying
"life isn't fair" is rather insulting (dung-throwing by the monkeys
doesn't help either but it's probably unavoidable.)
Now presumably a bigger brain and opposable thumbs would be better
solutions to this problem but those haven't been developed yet. I'd argue
that we're better off seeing how the tail works out, despite its obvious
problems, until such time as we can get brains and thumbs. Provided we can
identify the clams and cut them some slack, we should be okay for a while,
otherwise we lose the tail and we're back where we started, minus a few
dead clams. Essentially, Mark says those are unacceptable and avoidable
losses, others disagree, and we have an an impasse.
Is this an unfair assessment of the state of this argument?
And no, I haven't been drinking.
-- Bob
Re: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 02:58 PM 3/10/2004, Mark C. Langston wrote:
>With SPF, I can decide whether or not MY domains use SPF. However, I have
>no control over whether the service currently providing my IP transit is
>using SPF, and thus whether any mail sent by me while using
>that transit is going to be affected by SPF (e.g., transparent proxies).
I think you're misunderstanding something. The publishing side of SPF
resides solely in your DNS server. The verification side resides solely in
the receiving mail server. The outgoing SMTP server doesn't care about SPF.
If you're connected to Earthlink, and you send mail using your domain name
and Earthlink's SMTP server to someone at AOL, it doesn't matter whether
Earthlink has implemented SPF, SRS, or anything else. The only things that
matter are: (1) Are you publishing SPF information? (2) Is AOL checking SPF
information?
OK, one other thing: (1a) Is your SPF information accurate? That may be an
issue if your provider isn't forthcoming, which may be what you were trying
to get at. In this case, you're actually better off if your provider
publishes its own SPF record, because you can then just set yours to
include theirs, and you don't have to worry about whether they redesign
their network.
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 02:40:26PM -0800, Jonathan Tai wrote:
>
> I don't think SPF is problem-free, but it effectively reduces forgeries
> and joe-jobs, just like SpamAssassin effectively reduces spam and virus
> scanners slow the spread of viruses. There are problems with
> SpamAssassin - FPs, missed spam, resource issues, etc. But people use
> it. Why must perfection be a prerequisite to SPF's adoption?
>
> And yes, I've read your post that says SpamAssassin doesn't reject mail
> before DATA is sent, etc., and that's why it's okay to deploy
> SpamAssassin but not SPF. If you're paranoid about losing mail (like
> me; clients get *really* upset if they don't get a mail they were
> expecting, even if it was the most spammy thing on Earth and deserved to
> be dropped to the floor) then use SPF in "level 2" mode. Level 2 adds
> Received-SPF headers but does not reject the message. SpamAssassin can
> use the Received-SPF header as another metric.
>
The big problem here is this: I can decide whether or not the services
I use implement SA, because I can run SA as a mere user, or choose not
to. If I'm confined to a mail system over which I have no control, I
can be fairly certain that any and all email received is in one of my
mailboxes, whether it's my mbox or a quarantine/spam folder, for my
perusal.
With SPF, I can decide whether or not MY domains use SPF. However, I
have no control over whether the service currently providing my IP
transit is using SPF, and thus whether any mail sent by me while using
that transit is going to be affected by SPF (e.g., transparent proxies).
So, it boils down to a control issue. With SA, I have control, and when
I don't have control, the worst that happens is that I'm inconvenienced
by my email going to a folder I wasn't expecting.
With SPF, either I have control, or I have no control whatsoever, I may
not be aware I'm in a situation where I'm being impacted by SPF
(because, let's be honest, how many people are going to fire up spfquery
every time they log in to find out?), and my mail may be bounced without my
knowledge and against my expectations.
Imagine for a second that almost every MX on the planet implemented rDNS
checks. Now imagine that your ISP suddendly botched their rDNS zones,
and didn't fix them. Your mail starts bouncing, you weren't expecting
it to, you weren't aware that the problem existed, and you're powerless
to change the situation (except to change providers).
THAT scenario is very much like the one SPF will create: end-user
ignorance of the change, violation of end-user expectation w.r.t.
delivery, and complete end-user powerlessness over the situation, except
to change providers.
(Of course, I'm one of those strange people that seems to think that a
client connecting directly to the destination MX is still fine. I think
some of the SPF proponents may be operating under the assumption that
any and all email should always be handed off through a smarthost
somewhere, so that only MXes ever talk to MXes.)
> So again, SPF isn't perfect, but neither are Bayes (needs training),
> rDNS (breaks hosted-at-home servers), and RBLs (FPs due to
> blocking-the-entire-class-C tactics). SPF is easy to implement (simple
> TXT entry on the sending side, an extra cache-able DNS lookup on the
> receiving side), and it's worth implementing because it addresses
> something that none of these other tools addresses: joe-jobs.
Yes, but SPF also increases DNS traffic, draws unwanted attention to
worldwide DNS vulnerability, will force more people to greatly reduce
SOA TTLs to accomodate somewhat frequent SPF record changes (thus
further increasing DNS traffic), relies on a DNS record that has both
length and count limitations, and is trivially spoofable.
SPF also relies on changes to infrastructure (implementation of SMTP
AUTH, SRS, DNSSEC and some paired system (such as SA or a reputation-based
system) to actually be effective. That's hardly "simple".
(Please note: I'm not against SMTP AUTH or DNSSEC. I'm in favor of
both. What I'm against is the na�ve assumption that once SPF is
deployed, people will simply, quietly, and willingly go to the
(sometimes rather great) lengths necessary to upgrade their servers to
accomodate these, and change the configuration of all their deployed
clients to take advantage of these changes.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Wed, 2004-03-10 at 13:29, Mark C. Langston wrote:
> On Wed, Mar 10, 2004 at 01:24:06PM -0800, Jonathan Tai wrote:
> >
> > POP-before-SMTP requires no special client support. Just check your
> > mail before you send any. There is no "problem" to discuss.
> >
> ...and if one uses IMAP instead of POP?
>
You mean like me? IMAP-before-SMTP.
> (and there are still "problems" to discuss. If you think SPF is
> problem-free, however, that discussion will be pointless. Religous wars
> aren't productive.)
I don't think SPF is problem-free, but it effectively reduces forgeries
and joe-jobs, just like SpamAssassin effectively reduces spam and virus
scanners slow the spread of viruses. There are problems with
SpamAssassin - FPs, missed spam, resource issues, etc. But people use
it. Why must perfection be a prerequisite to SPF's adoption?
And yes, I've read your post that says SpamAssassin doesn't reject mail
before DATA is sent, etc., and that's why it's okay to deploy
SpamAssassin but not SPF. If you're paranoid about losing mail (like
me; clients get *really* upset if they don't get a mail they were
expecting, even if it was the most spammy thing on Earth and deserved to
be dropped to the floor) then use SPF in "level 2" mode. Level 2 adds
Received-SPF headers but does not reject the message. SpamAssassin can
use the Received-SPF header as another metric.
So again, SPF isn't perfect, but neither are Bayes (needs training),
rDNS (breaks hosted-at-home servers), and RBLs (FPs due to
blocking-the-entire-class-C tactics). SPF is easy to implement (simple
TXT entry on the sending side, an extra cache-able DNS lookup on the
receiving side), and it's worth implementing because it addresses
something that none of these other tools addresses: joe-jobs.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 01:24:06PM -0800, Jonathan Tai wrote:
>
> POP-before-SMTP requires no special client support. Just check your
> mail before you send any. There is no "problem" to discuss.
>
...and if one uses IMAP instead of POP?
(and there are still "problems" to discuss. If you think SPF is
problem-free, however, that discussion will be pointless. Religous wars
aren't productive.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Greg Cirino - Cirelle Enterprises <gc...@cirelle.com>.
----- Original Message -----
From: "Mark C. Langston" <ma...@bitshift.org>
To: <sp...@incubator.apache.org>
Sent: Wednesday, March 10, 2004 3:38 PM
Subject: Re: Opinions About SPF
| Thus, the coming phones wom't have SMTP AUTH, MSA, STARTTLS, or other
| such support. And all the Sony-Ericcsons, Nokias, Blackberries,
| Motorolas, Handspring/Palm smartphones that are already in the hands of
| consumers are somewhat difficult to upgrade.
Blackberries are easy to upgrade, software based not firmware based.
as for the others... they are probably cheap enough to replace if the need
is there and cannot be upgraded like the Blackberries.
Also this looks like a hand held provider issue to me (and possible revenue stream
for wired email providers)
If the world requires that I have an MX and rDns record for my mailer and I choose
not to provide that, who loses, I think I do. If wireless providers don't provide the
proper requirements, I think they will lose as well.
It all falls under the way standards are made, the most widely used implementations
become standards... look at M$ and ODBC, once non-standard, but after they
bundled it (ODBC) with every product they sold, it eventually obtained standard status.
Regards
Greg
Re: Opinions About SPF
Posted by Clive Eisen <cl...@serendipita.com>.
Mark C. Langston wrote:
>On Wed, Mar 10, 2004 at 12:30:04PM -0800, Kelson Vibber wrote:
>
>
>>At 12:05 PM 3/10/2004, Mark C. Langston wrote:
>>
>>
>>>There are phones, today, with SMTP clients on them. Those phones are
>>>becoming more, not less, popular. The addition of SMTP clients to phones
>>>is becoming more, not less, common.
>>>
>>>
>>Right. Therefore, now is the best time to encourage phone manufacturers to
>>make them capable of SMTP-AUTH: *before* SMTP-capable phones become
>>widespread.
>>
>>It's easier to upgrade a small installed base than a large one.
>>
>>
>>
>
>I agree. But those phones that are coming are already in the finishing
>phases of development and testing; the models to be introduced later
>this year and early next are largely finished. I doubt very much that
>the current state of email is such that any of these companies sees a
>need to undo the feature freeze and implement an SMTP client rewrite.
>
>Thus, the coming phones wom't have SMTP AUTH, MSA, STARTTLS, or other
>such support. And all the Sony-Ericcsons, Nokias, Blackberries,
>Motorolas, Handspring/Palm smartphones that are already in the hands of
>consumers are somewhat difficult to upgrade.
>
>Sure, perhaps some third party may write such a client for those few
>phones based on relatively open platforms (the Palm and WinCE
>smartphones), but most other vendors have a relatively high
>barrier-to-entry for your typical OSS developer, in terms of license and
>IDE fees for their developer programs.
>
>Further, phone companies seem notoriously slow about pushing new or
>upgraded firmware to phone capable of OTA updates. Few if any consumers
>are even aware that they can walk into a retail outlet and request a
>firmware update in person.
>
>So, what you're left with is an entire market segment that's got a huge
>inertia problem (both from the business and technical end) that WILL
>have a large installed base by the time this becomes an issue.
>
>Which is why it's apropos to discuss and find solutions to the problem
>now, rather than when the problem has come to the fore post-deployment.
>
>
>
Sorry this is just wrong ( IMHO :-) )
a) some phones have smtp-auth ( my p900 does)
b) smart phones run an operating systen - if the email client does not
do what you want/the market needs, just install an app that does
they will surely be produced if there is a demand/need - my phone
has an awful browser on it so I installed Opera
--
Clive
Re: pop-before-smtp Was: Opinions About SPF
Posted by "Eric W. Bates" <er...@vineyard.net>.
Greg Cirino - Cirelle Enterprises wrote:
> | > -----Original Message-----
> | > From: Bart Schaefer [mailto:schaefer@zanshin.com]
> | > > POP-before-SMTP requires no special client support. Just check your
> | > > mail before you send any. There is no "problem" to discuss.
>
> SMTP-AUTH is a much better solution than P-b4-S and is more secure
>
> Greg
We run an ISP, and have used a combination of pop-before-smtp and
SMTP-AUTH for the last several years. We use both because customers are
simply ineducable. When we can, we instruct folks to authenticate.
We have not experienced race conditions.
Since the tool tails a log file it is easy to tweak to parse the output
from an imap (pop-before-smtp simply being a shorter name than
parse-logfile-for-successful-authentication-under-other-protocol-before-allowing-smtp).
Yes, many clients attempt to send before a pop; but believe it or not,
the customers seem to prefer clicking "send/receive" twice rather than
call us and learn.
--
eric
Re: Opinions About SPF
Posted by Greg Cirino - Cirelle Enterprises <gc...@cirelle.com>.
| > -----Original Message-----
| > From: Bart Schaefer [mailto:schaefer@zanshin.com]
| > > POP-before-SMTP requires no special client support. Just check your
| > > mail before you send any. There is no "problem" to discuss.
SMTP-AUTH is a much better solution than P-b4-S and is more secure
Greg
RE: Opinions About SPF
Posted by James Nelson <ja...@kcnet.com>.
> -----Original Message-----
> From: Bart Schaefer [mailto:schaefer@zanshin.com]
> Sent: Wednesday, March 10, 2004 3:32 PM
> To: spamassassin-users@incubator.apache.org
> Subject: Re: Opinions About SPF
>
> On Wed, 10 Mar 2004, Jonathan Tai wrote:
>
> > POP-before-SMTP requires no special client support. Just check your
> > mail before you send any. There is no "problem" to discuss.
>
> POP-before-SMTP is a barely-functional workaround, subject to race
> conditions and other failures. I'm frankly amazed that anyone is
> seriously willing to reference it as a justification for anything.
Not to mention the most widely used email clients send before receiving.
Re: Opinions About SPF
Posted by Bart Schaefer <sc...@zanshin.com>.
On Wed, 10 Mar 2004, Jonathan Tai wrote:
> POP-before-SMTP requires no special client support. Just check your
> mail before you send any. There is no "problem" to discuss.
POP-before-SMTP is a barely-functional workaround, subject to race
conditions and other failures. I'm frankly amazed that anyone is
seriously willing to reference it as a justification for anything.
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Wed, 2004-03-10 at 12:38, Mark C. Langston wrote:
> On Wed, Mar 10, 2004 at 12:30:04PM -0800, Kelson Vibber wrote:
> > At 12:05 PM 3/10/2004, Mark C. Langston wrote:
> > >There are phones, today, with SMTP clients on them. Those phones are
> > >becoming more, not less, popular. The addition of SMTP clients to phones
> > >is becoming more, not less, common.
> >
> > Right. Therefore, now is the best time to encourage phone manufacturers to
> > make them capable of SMTP-AUTH: *before* SMTP-capable phones become
> > widespread.
> >
> > It's easier to upgrade a small installed base than a large one.
> >
>
> I agree. But those phones that are coming are already in the finishing
> phases of development and testing; the models to be introduced later
> this year and early next are largely finished. I doubt very much that
> the current state of email is such that any of these companies sees a
> need to undo the feature freeze and implement an SMTP client rewrite.
>
> Thus, the coming phones wom't have SMTP AUTH, MSA, STARTTLS, or other
> such support.
-- snip --
> Which is why it's apropos to discuss and find solutions to the problem
> now, rather than when the problem has come to the fore post-deployment.
POP-before-SMTP requires no special client support. Just check your
mail before you send any. There is no "problem" to discuss.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 12:30:04PM -0800, Kelson Vibber wrote:
> At 12:05 PM 3/10/2004, Mark C. Langston wrote:
> >There are phones, today, with SMTP clients on them. Those phones are
> >becoming more, not less, popular. The addition of SMTP clients to phones
> >is becoming more, not less, common.
>
> Right. Therefore, now is the best time to encourage phone manufacturers to
> make them capable of SMTP-AUTH: *before* SMTP-capable phones become
> widespread.
>
> It's easier to upgrade a small installed base than a large one.
>
I agree. But those phones that are coming are already in the finishing
phases of development and testing; the models to be introduced later
this year and early next are largely finished. I doubt very much that
the current state of email is such that any of these companies sees a
need to undo the feature freeze and implement an SMTP client rewrite.
Thus, the coming phones wom't have SMTP AUTH, MSA, STARTTLS, or other
such support. And all the Sony-Ericcsons, Nokias, Blackberries,
Motorolas, Handspring/Palm smartphones that are already in the hands of
consumers are somewhat difficult to upgrade.
Sure, perhaps some third party may write such a client for those few
phones based on relatively open platforms (the Palm and WinCE
smartphones), but most other vendors have a relatively high
barrier-to-entry for your typical OSS developer, in terms of license and
IDE fees for their developer programs.
Further, phone companies seem notoriously slow about pushing new or
upgraded firmware to phone capable of OTA updates. Few if any consumers
are even aware that they can walk into a retail outlet and request a
firmware update in person.
So, what you're left with is an entire market segment that's got a huge
inertia problem (both from the business and technical end) that WILL
have a large installed base by the time this becomes an issue.
Which is why it's apropos to discuss and find solutions to the problem
now, rather than when the problem has come to the fore post-deployment.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: OT: web-o-trust.org
Posted by Chris Barnes <ch...@tamu.edu>.
Mark C. Langston <ma...@bitshift.org> wrote:
>> Yes, but a centralized system is what is required in my opinion for
>> maximum effectiveness.
>
> And a centralized system provides:
>
> 1) A single target
> 2) A single point of failure
> 3) A "who watches the watchers" problem regarding trust in the
> centralized authority
> 4) Any number of other issues I could have any given cypherpunk rattle
> on for hours about, rather vehemently.
It's good to see we can find agreement about somethings! ;-)
--�
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes@tamu.edu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University
Re: OT: web-o-trust.org
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 03:00:50PM -0600, James Nelson wrote:
>
> > -----Original Message-----
> > From: Mark C. Langston [mailto:mark@bitshift.org]
> > Sent: Wednesday, March 10, 2004 2:40 PM
> > To: spamassassin-users@incubator.apache.org
> > Subject: Re: OT: web-o-trust.org
> >
> > There are proposals out there that offer this sort of WL without a
> > centralized repository for the data.
>
>
> Yes, but a centralized system is what is required in my opinion for maximum
> effectiveness.
And a centralized system provides:
1) A single target
2) A single point of failure
3) A "who watches the watchers" problem regarding trust in the
centralized authority
4) Any number of other issues I could have any given cypherpunk rattle
on for hours about, rather vehemently.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
RE: OT: web-o-trust.org
Posted by James Nelson <ja...@kcnet.com>.
> -----Original Message-----
> From: Mark C. Langston [mailto:mark@bitshift.org]
> Sent: Wednesday, March 10, 2004 2:40 PM
> To: spamassassin-users@incubator.apache.org
> Subject: Re: OT: web-o-trust.org
>
> There are proposals out there that offer this sort of WL without a
> centralized repository for the data.
Yes, but a centralized system is what is required in my opinion for maximum
effectiveness.
Re: OT: web-o-trust.org
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 02:30:05PM -0600, James Nelson wrote:
> I like the idea of SPF, but hate all the proposed implementations. I have
> always been in favor of an MTA registry that would be able to produce a
> policed DNSWL that we could use.
>
> In doing some searching today, I came across web-o-trust.org. Have any of
> you looked at them or are currently using them?
>
> The nicest thing I noticed write away, is that they have already created the
> m4 coded needed to make a DNSWL work. No if I could only compile my own
> list of good MTAs from ISPs across the land I would be in heaven.
>
There are proposals out there that offer this sort of WL without a
centralized repository for the data.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
OT: web-o-trust.org
Posted by James Nelson <ja...@kcnet.com>.
I like the idea of SPF, but hate all the proposed implementations. I have
always been in favor of an MTA registry that would be able to produce a
policed DNSWL that we could use.
In doing some searching today, I came across web-o-trust.org. Have any of
you looked at them or are currently using them?
The nicest thing I noticed write away, is that they have already created the
m4 coded needed to make a DNSWL work. No if I could only compile my own
list of good MTAs from ISPs across the land I would be in heaven.
james
Re: Opinions About SPF
Posted by Bob Apthorpe <ap...@cynistar.net>.
Hi,
On Wed, 10 Mar 2004, Kelson Vibber wrote:
> At 12:05 PM 3/10/2004, Mark C. Langston wrote:
> >There are phones, today, with SMTP clients on them. Those phones are
> >becoming more, not less, popular. The addition of SMTP clients to phones
> >is becoming more, not less, common.
>
> Right. Therefore, now is the best time to encourage phone manufacturers
> to make them capable of SMTP-AUTH: *before* SMTP-capable phones become
> widespread.
>
> It's easier to upgrade a small installed base than a large one.
Aren't phones are pretty much sealed units? Aside from carriers, who else
can install base-level functionality like SMTP AUTH or IMAP support, and
don't the carriers have some level of draconian "upgrade or die" fiat to
control their users' platforms? Also, considering the lifespan of a
handset (<3 years), small number of mobile O/S and handset vendors, and
the generally tighter configuration management of telecoms, wouldn't the
problem of fixing the installed base of mobile devices be orders of
magnitude easier than fixing desktops and servers? Mobile users are very
much a captive audience.
-- Bob
Re: dumb dcc question
Posted by Matthias Fuhrmann <Ma...@stud.uni-hannover.de>.
On Mon, 22 Mar 2004, James Nelson wrote:
> I just installed dcc for the first time. I am running a test of sa 3.0,
> latest cvs. After running spamassassin -D lint I noticed this line in the
> debug output:
>
> DCCifd is not available: no r/w dccifd socket found.
>
> The other dcc lines seem normal. Is this idicating some problem with my
> install of dcc?
seems fine, if SA can find dccproc. DCCifd is the deamon version, used for
better performance. otherwise it uses dccproc. gets called for every mail
scanning.
regards,
Matthias
dumb dcc question
Posted by James Nelson <ja...@kcnet.com>.
I just installed dcc for the first time. I am running a test of sa 3.0,
latest cvs. After running spamassassin -D lint I noticed this line in the
debug output:
DCCifd is not available: no r/w dccifd socket found.
The other dcc lines seem normal. Is this idicating some problem with my
install of dcc?
RE: user_prefs and multiple servers
Posted by James Nelson <ja...@kcnet.com>.
Anyone have any suggestions for this?
I have a case where the smtp and pop server reside on server1. Spamc hands
of the spam for scanning to spamd. I would like to move spamd to server2,
where I am currently handling antivirus scans.
Is it possible for spamd on server2 to use the user_prefs for individual
users located on server1?
Lastly, does anyone know of any known problems running a version of spamc
different than spamd, ie. Spamc from SA 2.63 and spamd from 3.0?
james
user_prefs and multiple servers
Posted by James Nelson <ja...@kcnet.com>.
Currently I am running sa 2.63 on the same server as my primary sendmail
server. In thinking about moving forward with sa 3.0 I would like to move
spamd to a secondary server and using spamc on the primary to make the
connection.
In very limited testing this seems to be working fine with the newest cvs.
My questions is are the user_prefs files on the main server able to be read
by spamd on the secondary server? In my limited testing, this doesn't seem
to be the case. If it can't how can I get around this with out copying all
my users info to this secondary machine?
Also, is there any known problem using spamc from 2.63 with spamd on 3.0?
Re: Opinions About SPF
Posted by Clive Eisen <cl...@serendipita.com>.
Kelson Vibber wrote:
> At 12:05 PM 3/10/2004, Mark C. Langston wrote:
>
>> There are phones, today, with SMTP clients on them. Those phones are
>> becoming more, not less, popular. The addition of SMTP clients to
>> phones is becoming more, not less, common.
>
>
> Right. Therefore, now is the best time to encourage phone
> manufacturers to make them capable of SMTP-AUTH: *before* SMTP-capable
> phones become widespread.
>
> It's easier to upgrade a small installed base than a large one.
>
>> Thus, your argument based on inter-carrier SMS problems is mooted.
>
>
> I won't put words in Chris' mouth, but it seemed to me his point
> *wasn't about SMS* - rather, it seemed to be that, since phones'
> capabilities are constantly changing, now would be a logical time to
> add *useful* features like SMTP-AUTH.
>
> Kelson Vibber
> SpeedGate Communications <www.speed.net>
sony-erricsson p900 does smtp-auth
--
Clive
Re: Opinions About SPF
Posted by Chris Barnes <ch...@tamu.edu>.
Kelson Vibber <ke...@speed.net> wrote:
> I won't put words in Chris' mouth, but it seemed to me his point
> *wasn't about SMS* - rather, it seemed to be that, since phones'
> capabilities are constantly changing, now would be a logical time
> to add *useful* features like SMTP-AUTH.
Your assumption is dead-on accurate.
In fact, I wouldn't use a cellphone for email that didn't have it.
(verizon: can you hear me now?)
--
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes@tamu.edu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University
Re: Opinions About SPF
Posted by Kelson Vibber <ke...@speed.net>.
At 12:05 PM 3/10/2004, Mark C. Langston wrote:
>There are phones, today, with SMTP clients on them. Those phones are
>becoming more, not less, popular. The addition of SMTP clients to phones
>is becoming more, not less, common.
Right. Therefore, now is the best time to encourage phone manufacturers to
make them capable of SMTP-AUTH: *before* SMTP-capable phones become widespread.
It's easier to upgrade a small installed base than a large one.
>Thus, your argument based on inter-carrier SMS problems is mooted.
I won't put words in Chris' mouth, but it seemed to me his point *wasn't
about SMS* - rather, it seemed to be that, since phones' capabilities are
constantly changing, now would be a logical time to add *useful* features
like SMTP-AUTH.
Kelson Vibber
SpeedGate Communications <www.speed.net>
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Wed, Mar 10, 2004 at 01:51:13PM -0600, Chris Barnes wrote:
> Mark C. Langston <ma...@bitshift.org> wrote:
> > With things like SPF, you'll either have to whitelist the entire set
> > of dynamic IP blocks the provider uses, or you'll have to hold your
> > breath and wait for every phone-based mail client to be rewritten.
> >
> > Neither's an acceptable solution.
> >
> > Nobody wants 7 separate phone numbers. Why is it de rigeur to expect
> > people to use 7 different email addresses?
>
> It has already been pointed out (repeatedly) that cell phone messaging
> systems don't even have compaitibility with each other. This means that
> cell phone email is in a state of serious flux and WILL be re-written
> (probably serveral more times).
>
and, as I already pointed out, when I brought up SMS, I was referring to
the popularity of the service, not the underlying protocol. There are
phones, today, with SMTP clients on them. Those phones are becoming
more, not less, popular. The addition of SMTP clients to phones is
becoming more, not less, common.
Thus, your argument based on inter-carrier SMS problems is mooted.
> Having one of those re-writes include SMTP AUTH is not only a logical
> step, it is almost a mandatory one.
When it becomes mandatory, it may happen. It's not, and therefore it
isn't. Heck, cellular software authors are still struggling with
implementing IMAP properly.
>
>
> Personally, I wouldn't use a cell phone for email that *didn't* use it.
>
If you had a mobile cellular device capable of email that
you were expected to use (e.g., for business purposes -- a
Blackberry comes to mind), you'd not have much choice, unless you're
willing to quit or risk being fired due to your unwillingness to use
company-mandated tools.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: [spa] Re: Opinions About SPF
Posted by Alex van den Bogaerdt <al...@ergens.op.het.net>.
Warning: RANT.
On Tue, Mar 09, 2004 at 11:08:06AM -0500, Charles Gregory wrote:
> > No more nigerian scam coming from a2000.nl/chello.nl , unless
> > the proud owner of that super-de-luxe cable connection is willing
> > to pay for the spam it routes.
>
> And isn't it just too bad if the user of that computer system got caught
> by a fresh virus, in between his anti-virus program updates, never knew
> that his anti-virus was circumvented/disabled by the clever virus and that
> he was actually unprotected *and* spamming for a month......
You seem to use the same arguments as I do. At least we agree on that.
The user does not know or does not care. Send the bill. He will know
and he will care. Here we seem to disagree.
> And if that user is a poor commmunity organization with NO extra budget,
> and loses its internet access because of it, well we don't care about the
> masses do we?
People without the necessary skills are not allowed to drive.
People without the necessary skills are not allowed to fly.
People without the necessary skills are not allowed to operate heavy equipment.
Why should I care about people without the necessary skills to run
a computer? Hey, they can hire personnel. That doesn't need to be
full time. Poor community organizations can try and find volunteers.
People should think about this _before_ operating a computer. If they
are unable to either gain the necessary knowledge themselves or hire
it from someone else, that is enough reason to not use a computer.
The fact is: These kind of people (well, most of them) run their
computers without even trying to be secure. These kind of computers
are being contaminated by a virus. These kind of computers are spam
relays. These kind of spam relays send _me_ spam.
I don't care *at*all* if they are aware of the problem. If _they_ are
the problem, I do _not_ want to suffer from _their_ problem. Disconnect,
then send a bill, reconnect when the damage is payed for.
And perhaps it is a good thing if ISPs are stuck with the bill. They
only care about money. When we are able to shift costs to them instead
of paying bandwidth, server capacity and such ourselves, maybe they
start fixing the problem. Many ISPs don't know or don't care about
virus and spam. See my 2nd paragraph and replace "user" by "ISP".
If chello and similar would be proactive and responsive, this mailing
list would probably not even exist in the first place. Sigh, even the
people at MS understand there is a problem.
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags
Re: [spa] Re: Opinions About SPF
Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 9 Mar 2004, Alex van den Bogaerdt wrote:
> On Tue, Mar 09, 2004 at 12:10:28PM +0100, Martin Carpenter wrote:
> > I don't personally have anything new to add to the debate, but I did like
> > this comment from Rob Slade in the latest Risks digest
> > (http://catless.ncl.ac.uk/Risks/23.26.html#subj4):
> > ...
> > In fact, most of these antispam technologies fail in the
> > face of the problem of spam nets set up by viruses.
> > infected machines could use the micropayment "wallet" on
> > the infected machine, thus creating ..... a real cost.
>
> Wow. You mean finally the owners^Wpeople paying the bill have
> an incentive to either install a firewall theirselves or pay
> someone to do this for them.
Wow, yeah, this could mean that we go back to the original concept of the
internet as merely a tool for big business, with the little 'poor' people
squeezed out by costs and/or the fear of costs they cannot control.
And just wait until people figure out that all they have to do is *bail
out* on an ISP that tries to bill them, so then the ISP's will be eating
the costs, because they won't be able to afford legal costs to go after
their clients, and there will go the little ISP's, and eventually any
semblance of competition in the service provider field, as only the large
providers, like the phone companies will invest in legal action against
clients who bail.
But I'm sure we can count on the phone company to keep our internet
service reliable and fairly priced....... Riiiiiiiight.
> No more nigerian scam coming from a2000.nl/chello.nl , unless
> the proud owner of that super-de-luxe cable connection is willing
> to pay for the spam it routes.
And isn't it just too bad if the user of that computer system got caught
by a fresh virus, in between his anti-virus program updates, never knew
that his anti-virus was circumvented/disabled by the clever virus and that
he was actually unprotected *and* spamming for a month......
And if that user is a poor commmunity organization with NO extra budget,
and loses its internet access because of it, well we don't care about the
masses do we?
Of course, I'm slightly less sympathetic to the people who can fork out
$45 a month for access but can't cough up the same amount *once* for
decent virus prevention. Maybe your idea would have some merit with cable
modems. But hey, wait, technically it is ALREADY IN PLACE. Most high speed
services actually have bandwidth limits. If the moron who doesn't protect
his cable modem exceeds that, he *will* pay.......
> I like this idea, a lot.
As a side note, please refer to a previous rant of mine on how computer
stores sell 'complete' computer packages without a decent anti-virus
built-in, and no education as to the 'risks' of running without one.
You want to push for fundamental change? Go for something realistic and
support FREE fully updated virus-checkers like CLAMAV and make sure it
works on Windows, then get computer stores the world over to include them
in their 'packages' as a compulsory item. Why not make a FREE anti-virus
fire-wall system for ISP's? How easy it would be to filter/firewall
viruses for the ignorant customers if the majority of anti-virus companies
weren't charging ridiculous 'per user' fees to ISP's?
Hurray for CLAMAV!
- Charles
Re: Opinions About SPF
Posted by Alex van den Bogaerdt <al...@ergens.op.het.net>.
On Tue, Mar 09, 2004 at 12:10:28PM +0100, Martin Carpenter wrote:
> I don't personally have anything new to add to the debate, but I did like
> this comment from Rob Slade in the latest Risks digest
> (http://catless.ncl.ac.uk/Risks/23.26.html#subj4):
>
> ...
> In fact, most of these antispam technologies fail in the
> face of the problem of spam nets set up by viruses.
> Spam sent from infected machines could simply use the name
> of the owner, thus verifying the identity. Spam sent from
> infected machines could use the micropayment "wallet" on
> the infected machine, thus creating not only problems of
> clean-up for the owner, but also a real cost. Infected
> machines could be used to crack computational puzzles, or
> the owner could be presented with challenges to respond to,
> in a variety of ways.
> ...
Wow. You mean finally the owners^Wpeople paying the bill have
an incentive to either install a firewall theirselves or pay
someone to do this for them. This as opposed to shifting the
costs elsewhere...
No more nigerian scam coming from a2000.nl/chello.nl , unless
the proud owner of that super-de-luxe cable connection is willing
to pay for the spam it routes.
I like this idea, a lot.
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags
Re: Opinions About SPF
Posted by Martin Carpenter <mc...@free.fr>.
I don't personally have anything new to add to the debate, but I did like
this comment from Rob Slade in the latest Risks digest
(http://catless.ncl.ac.uk/Risks/23.26.html#subj4):
...
In fact, most of these antispam technologies fail in the
face of the problem of spam nets set up by viruses.
Spam sent from infected machines could simply use the name
of the owner, thus verifying the identity. Spam sent from
infected machines could use the micropayment "wallet" on
the infected machine, thus creating not only problems of
clean-up for the owner, but also a real cost. Infected
machines could be used to crack computational puzzles, or
the owner could be presented with challenges to respond to,
in a variety of ways.
...
Martin.
Re: Opinions About SPF
Posted by Faisal N Jawdat <fa...@faisal.com>.
> Actually, on my drive home from the office just now, I thought of a
> solution I could live with, that solves the problem for pretty much
> everyone but cell/smartphone users (and only then because the
> software's
> more difficult to get written and distributed):
>
> If there were to be a client implemented, much like that used by the
> free dynamic DNS services, that would update the appropriate TXT record
> for the user when their machine is brought online (preferably via
> DNSSEC, but obviously other methods would need to be used, perhaps
> simple username/password via SSL) with the appropriate exception entry
> in the SPF record, this would eliminate most of my complaints regarding
> legitimate spoofing.
when do we give up and just implement mobile ip?
-faisal
-not exactly serious
Re: Opinions About SPF
Posted by Greg Cirino - Cirelle Enterprises <gc...@cirelle.com>.
----- Original Message -----
From: "Mark C. Langston" <ma...@bitshift.org>
| ...and what if the cell user wishes to send email using a
| long-established address rather than having to use (and expecting others
| to remember) yet another address? When will we see cell mail clients
| capable of STARTTLS, POP-before-SMTP, MSA, or SMTP AUTH?
|
Apparently cellphones are cheap, service is changing as we speak
when cell users can't send mail they will find a service that will let them
as far as using long established addresses? well for the time being
white haired ladies can't carry scissors on airplanes any more.
The newer technology will need to adjust (backward compatability)
until the status quo dictates otherwise.
and all this is only if the SPF model catches on.
If M$ gets it's way with the caller id, the same issues will exist
The main issue as I see it is to prevent every desktop in the
world from being an SMTP server without proper credentials
as is what happens now with servers/desktops running open, and without
MX, rDns records.
Greg
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Tue, 2004-03-09 at 12:53, Mark C. Langston wrote:
> ...and what if the cell user wishes to send email using a
> long-established address rather than having to use (and expecting others
> to remember) yet another address? When will we see cell mail clients
> capable of STARTTLS, POP-before-SMTP, MSA, or SMTP AUTH?
>
> With things like SPF, you'll either have to whitelist the entire set of
> dynamic IP blocks the provider uses
"v=spf1 include:verizon.net"
Done.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by Chris Barnes <ch...@tamu.edu>.
Mark C. Langston <ma...@bitshift.org> wrote:
> With things like SPF, you'll either have to whitelist the entire set
> of dynamic IP blocks the provider uses, or you'll have to hold your
> breath and wait for every phone-based mail client to be rewritten.
>
> Neither's an acceptable solution.
>
> Nobody wants 7 separate phone numbers. Why is it de rigeur to expect
> people to use 7 different email addresses?
It has already been pointed out (repeatedly) that cell phone messaging
systems don't even have compaitibility with each other. This means that
cell phone email is in a state of serious flux and WILL be re-written
(probably serveral more times).
Having one of those re-writes include SMTP AUTH is not only a logical
step, it is almost a mandatory one.
Personally, I wouldn't use a cell phone for email that *didn't* use it.
--
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes@tamu.edu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Tue, Mar 09, 2004 at 03:48:41PM -0500, Greg Cirino - Cirelle Enterprises wrote:
> ----- Original Message -----
> From: "Mark C. Langston" <ma...@bitshift.org>
> | Cf. any recent
> | cellphone, and the burgeoning popularity of smartphones, as well as the
> | coming of smartphones with integrated 802.11b (or whatever's standard at
> | the time), and seamless roaming across the 1xRTT/GPRS/3G and 802.11b
> | nets as desired/required.
> |
> | If you think email on cellphones is a nonissue, I point you at the
> | popularity of SMS, and ask you to wait a year or two.
>
> If I'm not mistaken, don't the cellphone companies who
> allow cellmail provide their own smtp servers to interface
> with the wired community? Assuming that to be the case
> the cellcomps will need to be on board as well, assuming
> SPF catches on.
...and what if the cell user wishes to send email using a
long-established address rather than having to use (and expecting others
to remember) yet another address? When will we see cell mail clients
capable of STARTTLS, POP-before-SMTP, MSA, or SMTP AUTH?
With things like SPF, you'll either have to whitelist the entire set of
dynamic IP blocks the provider uses, or you'll have to hold your breath
and wait for every phone-based mail client to be rewritten.
Neither's an acceptable solution.
Nobody wants 7 separate phone numbers. Why is it de rigeur to expect
people to use 7 different email addresses?
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Greg Cirino - Cirelle Enterprises <gc...@cirelle.com>.
----- Original Message -----
From: "Mark C. Langston" <ma...@bitshift.org>
| Cf. any recent
| cellphone, and the burgeoning popularity of smartphones, as well as the
| coming of smartphones with integrated 802.11b (or whatever's standard at
| the time), and seamless roaming across the 1xRTT/GPRS/3G and 802.11b
| nets as desired/required.
|
| If you think email on cellphones is a nonissue, I point you at the
| popularity of SMS, and ask you to wait a year or two.
If I'm not mistaken, don't the cellphone companies who
allow cellmail provide their own smtp servers to interface
with the wired community? Assuming that to be the case
the cellcomps will need to be on board as well, assuming
SPF catches on.
I believe it is the hotspot community that will need to make
the adjustment unless email hosts provide SMTP Auth which
is common practice, and it doesn't matter what network the
user is on as they could be sending via an SPF mailer from
anywhere.
Greg
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Tue, Mar 09, 2004 at 02:17:12PM -0600, Chris Barnes wrote:
>
> Having worked as in a helpdesk for 10 years gives me a pretty good feel
> for what "most people" are like.
>
> "Most people" don't use email on their cell phones, on a laptop at a
> coffee shop or airport, etc. "Most people" have a single computer
> sitting in a single location in their home connecting to an ISP via a
> dialup connection (although more and more are using cable modems or
> DSL).
>
Actually, "most people" don't own/can't afford a computer. The "most
people" to whom I was referring are business and academic users. The
"most people" to whom you're referring are lowest-common-denominator
consumers. With that distinction, you're correct: your "most people"
won't know, and won't care. Mine will. Loudly.
And the trend is to move your "most people" towards uses currently
popular with my "most people", not the other way 'round. Cf. any recent
cellphone, and the burgeoning popularity of smartphones, as well as the
coming of smartphones with integrated 802.11b (or whatever's standard at
the time), and seamless roaming across the 1xRTT/GPRS/3G and 802.11b
nets as desired/required.
If you think email on cellphones is a nonissue, I point you at the
popularity of SMS, and ask you to wait a year or two.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Chris Barnes <ch...@tamu.edu>.
Mark C. Langston <ma...@bitshift.org> wrote:
> And here, you and I differ. I think "most people" don't even know
> this is coming, and when it gets here, "most people" are going to be
> anywhere from mildly irritated to furious that their email no longer
> works from their cellphone/smartphone, their laptop at the local
> Starbucks, the hotspots in the airport, their laptop->cellphone net
> connection, their hotel rooms, their client sites, and so forth.
Having worked as in a helpdesk for 10 years gives me a pretty good feel
for what "most people" are like.
"Most people" don't use email on their cell phones, on a laptop at a
coffee shop or airport, etc. "Most people" have a single computer
sitting in a single location in their home connecting to an ISP via a
dialup connection (although more and more are using cable modems or
DSL).
All the problems you mention will indeed exist for the cell phone/mobile
users. But those are not "most people". The people who do that are
typically far more techno-savy than "most people" and as such, will be
better able to deal with any problems that a change in
standards/technology/etc might force upon them.
> "Most people" are going to wonder why they can't send an eCard to
> grandma on Mother's Day.
The "most people" who are at home on their single computer in a single
location using a single ISP will still be able to do this.
> And yes, eliminating spoofing will stop some spam. It will not,
> however, stop all spam.
Hint: nothing will stop all spam. Ever. All we can do is try to remain
ahead of the curve (or less far behind the curve).
> "Most people" want email to work as easily as possible. "Most people"
> do not want the hoops they have to jump through changing every six
> months. And if "most people" are promised a panac�a iff they jump
> through one more hoop, and discover they were misled once they reach
> the other side (and I'm fairly confident that the accurate
> description of the impact will be "this'll stop all spam" by the time
> it filters down to "most people"), they'll be rather upset.
AOL and the other major ISPs that have already jumped on this bandwagon
will certainly be a good test of your theory...
--�
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chris Barnes AOL IM: CNBarnes
chris-barnes@tamu.edu Yahoo IM: chrisnbarnes
Computer Systems Manager ph: 979-845-7801
Department of Physics fax: 979-845-2590
Texas A&M University
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 07:41:40PM -0500, Theo Van Dinter wrote:
>
> I guess becomes a "people will vote with their wallets" thing. IMO,
> ISPs can choose to implement SPF if they want to, and it's up to them
> to deal with their users.
>
> For instance AOL has SPF records published. I'm not positive, but find
> it very likely, that they haven't told their 4 million something members.
> With that, they 1) get SPF records and 2) default to "unknown" which means
> "more scrutiny" not "block" in general.
>
> At some point, if AOL sent an edict to the users "thou shalt only send
> aol.com mail through us", they could change it to default to "deny"
> and there you go. It'd still be up to the recipient, who could accept
> the default deny from the DNS admin and block mails that didn't match.
>
Actually, on my drive home from the office just now, I thought of a
solution I could live with, that solves the problem for pretty much
everyone but cell/smartphone users (and only then because the software's
more difficult to get written and distributed):
If there were to be a client implemented, much like that used by the
free dynamic DNS services, that would update the appropriate TXT record
for the user when their machine is brought online (preferably via
DNSSEC, but obviously other methods would need to be used, perhaps
simple username/password via SSL) with the appropriate exception entry
in the SPF record, this would eliminate most of my complaints regarding
legitimate spoofing.
There's still the issue of number/size of TXT records allowable,
however, and the attractiveness of DNS spoofing attacks when SPF is the
blocker-du-jour.
Ideally, I'd rather not live under the yoke of SPF. But if one must
(and prevailing winds would seem to indicate that), it would be nice to
preserve the existing legitimate spoofing uses.
One side effect of this would be an increase in DNS traffic. But we'd
see that anyway with SPF.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 04:26:24PM -0800, Mark C. Langston wrote:
> And here, you and I differ. I think "most people" don't even know this
> is coming, and when it gets here, "most people" are going to be anywhere
> from mildly irritated to furious that their email no longer works from
> their cellphone/smartphone, their laptop at the local Starbucks, the
> hotspots in the airport, their laptop->cellphone net connection, their
> hotel rooms, their client sites, and so forth.
I guess becomes a "people will vote with their wallets" thing. IMO,
ISPs can choose to implement SPF if they want to, and it's up to them
to deal with their users.
For instance AOL has SPF records published. I'm not positive, but find
it very likely, that they haven't told their 4 million something members.
With that, they 1) get SPF records and 2) default to "unknown" which means
"more scrutiny" not "block" in general.
At some point, if AOL sent an edict to the users "thou shalt only send
aol.com mail through us", they could change it to default to "deny"
and there you go. It'd still be up to the recipient, who could accept
the default deny from the DNS admin and block mails that didn't match.
--
Randomly Generated Tagline:
"NT is far less mature than the Unix family, of which Linux is a
member. M$ foolishly ignored 30 years of research and accumulated
wisdom. As a result, they've been repeating all the old mistakes."
- Unknown user on /.
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 07:10:03PM -0500, Theo Van Dinter wrote:
>
> Overall, I think most people would prefer stopping spoofing as it makes
> stopping spam a lot easier (black/whitelists become a LOT simpler and
> reliable), as long as there are reasonable work arounds for times when
> spoofing was used. SMTP AUTH + TLS solves a lot of that imho, but it
> of course requires people to set that up.
>
And here, you and I differ. I think "most people" don't even know this
is coming, and when it gets here, "most people" are going to be anywhere
from mildly irritated to furious that their email no longer works from
their cellphone/smartphone, their laptop at the local Starbucks, the
hotspots in the airport, their laptop->cellphone net connection, their
hotel rooms, their client sites, and so forth.
"Most people" are going to wonder why they can't send an eCard to
grandma on Mother's Day. "Most people" are going to wonder why the IT
department is making yet another apparently unnecessary change to their
work day yet again, when they'd just gotten used to the last major
behavioral change that was foisted upon them.
And yes, eliminating spoofing will stop some spam. It will not,
however, stop all spam. And that's what "most people" expect, and what
"most people" demand. If we keep uprooting "most people" every time we
make what amounts to an incremental change, we will completely burn
through whatever remaining cachet we've got with "most people".
"Most people" want email to work as easily as possible. "Most people"
do not want the hoops they have to jump through changing every six
months. And if "most people" are promised a panac�a iff they jump
through one more hoop, and discover they were misled once they reach the
other side (and I'm fairly confident that the accurate description of
the impact will be "this'll stop all spam" by the time it filters down
to "most people"), they'll be rather upset.
Users are like bears. They're relatively content and docile until
you start poking them with a stick. Poke them repeatedly, and you do so
at your own risk. If you feel a burning desire to poke, there better be
a VERY good reason, and that reason had best be crystal clear to both
you AND the bear, unless you want to deal with the consequences.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 03:48:48PM -0800, Mark C. Langston wrote:
> I never demanded spoofing be corrected. I spoof daily for various
> legitimate reasons, as do many others. It's convenient; it breaks
> nothing.
Absolutely true, and you can feel free to keep doing that for as long
as you want. If you want to accept mail from everyone and everything,
that's your decision. SPF is not required and unless it becomes part
of the SMTP protocol, will never be required.
I, however, have no obligation to accept your mail now or with SPF.
You have no right to tell me how to treat your mail, you can just submit
it to me for consideration. If I decide to not accept it, subject it
to more scrutiny, or fully accept it, it's up to me.
The real issue here is: is the cost of stopping spoofing worth the benefit
of stopping spoofing. There's no straight answer for that. You clearly
like the flexibility it provides and don't want that to break. I never
do it (always send through the "appropriate" server, use SMTP AUTH,
etc,) so I have no problem getting rid of spoofing.
Overall, I think most people would prefer stopping spoofing as it makes
stopping spam a lot easier (black/whitelists become a LOT simpler and
reliable), as long as there are reasonable work arounds for times when
spoofing was used. SMTP AUTH + TLS solves a lot of that imho, but it
of course requires people to set that up.
--
Randomly Generated Tagline:
"Stop stealing my blanket. You're an arctic wolf for god sakes. You're
getting soft." - Due South
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 06:44:11PM -0500, Theo Van Dinter wrote:
> On Mon, Mar 08, 2004 at 03:02:34PM -0800, Mark C. Langston wrote:
> > Problems with solution: Again, their response to "SPF creates a
> > problem" is, "solve the problem by changing your infrastructure."
> > Unacceptable. Furthermore, their justification for this solution is
>
> This is an invalid argument. You want spoofing to stop, so by
> definition you need to stop spoofing. If that causes problems for your
> infrastructure, yes, you'll need to rework your infrastructure.
>
> I'm tired of hearing people blaming SPF for breaking spoofing (which is
> essentially what you're doing w/ travelling salesman, cybercafe, etc,)
> when they want SPF specifically TO BREAK SPOOFING! Either you want
> spoofing to stop working or you don't. Pick one and stick with it.
>
I'd prefer a solution that prohibits undesired behavior without
affecting current desired behavior. If that's impossible, I'd greatly
prefer one that maximizes the former while minimizing the latter.
SPF simply tosses out the latter in deference to the former.
I never demanded spoofing be corrected. I spoof daily for various
legitimate reasons, as do many others. It's convenient; it breaks
nothing.
I applaud SPF for attempting to authoritatively establish identity (even
though they ignore reputation associated with a given identity) without
implementing some form of assymetric key-based system. As ambitious as
the attempt is, it creates more problems than I believe it solves.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by jdow <jd...@earthlink.net>.
From: "Theo Van Dinter" <fe...@kluge.net>
> I'm tired of hearing people blaming SPF for breaking spoofing (which is
> essentially what you're doing w/ travelling salesman, cybercafe, etc,)
> when they want SPF specifically TO BREAK SPOOFING! Either you want
> spoofing to stop working or you don't. Pick one and stick with it.
Then SPF is irretrievably broken. Fix it.
{^_^}
Re: Opinions About SPF
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 03:02:34PM -0800, Mark C. Langston wrote:
> Problems with solution: Again, their response to "SPF creates a
> problem" is, "solve the problem by changing your infrastructure."
> Unacceptable. Furthermore, their justification for this solution is
This is an invalid argument. You want spoofing to stop, so by
definition you need to stop spoofing. If that causes problems for your
infrastructure, yes, you'll need to rework your infrastructure.
I'm tired of hearing people blaming SPF for breaking spoofing (which is
essentially what you're doing w/ travelling salesman, cybercafe, etc,)
when they want SPF specifically TO BREAK SPOOFING! Either you want
spoofing to stop working or you don't. Pick one and stick with it.
--
Randomly Generated Tagline:
"Just 'cuz I don't have an IP doesn't mean I'm not on your network."
- Mike Poor
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 04:31:38PM -0600, David B Funk wrote:
>
> Have you looked at the SPF "Objections Addressed" page?
> http://spf.pobox.com/objections.html
>
I wanted to address this in a bit more detail, so here's a summation of
each addressed objection on that page:
1) Traveling Mailman problem.
Solution: SPF exceptions, SASL (infrastructure change).
Problems with solution: Limit to number and size of TXT records, rapid
burgeoning of number off TXT records individual/group must maintain,
leading to huge administrative headache. Also, the "change your
infrastructure to address problem we created" solution is not just a
non-starter, it's simply rude.
2) Cybercafe.
Solution: MSA (infrastructure change).
Problems with solution: Again, their response to "SPF creates a
problem" is, "solve the problem by changing your infrastructure."
Unacceptable. Furthermore, their justification for this solution is
that ISP's block port 25 outbound. What in Ghu's name makes anyone
think they won't simply start blocking 587 outbound as well?
3) Forwarding and Return-Path.
Solution: Use your ISPs domain for all outgoing email, or connect
through a single (or handful of) "blessed" MXes for whichever domain you
wish to use. The ability to, say, send email using a domain you own
from the dynamic IP granted you by your ISP (as I do) will disappear.
Problems with solution: Many ISPs do not respond to MX problems in a
timely manner. Many ISPs handle a load that unnecessarily increases
delivery times. Many ISPs do not deserve the de facto free advertising
granted them by using their domain name instead of one owned by the
end-user. Many end-users find themselves behind ISPs other than the
one controlling the domain they use for email on a regular basis
-- business travellers, vacationers, busy people with home computers, work
computers, and mobile devices, each with their own ISP and IPs, but each
capable of sending an email with a single domain as the RHS of an email
address. Many end-users take advantage of .forward files and
/etc/mail/aliases functionality to have email sent to other addresses
instead of or including the original destination. Here again, their
solution is "rearchitect your MTA". And here, again, that solution is
simply unacceptable, because it says, "we created a new problem. It's
up to you to fix it. We can't be bothered."
4) Conscientious Objectors (aka "People who don't publish SPF records")
Solution: Treat anyone without an SPF record as suspect.
Problems with solution: This is not a good way to ensure a smooth
transition to a new approach, particularly not one as disruptive as SPF.
Know what the end result will be? Many sites advertising SPF records,
and nobody acting on them.
They even have the nerve to say (and I quote directly from the page):
"Domains who do this are the same domains who run open relays."
I beg to differ, and I find the tone -- and the underlying implications
-- insulting.
5) Throwaway domains.
Solution: SPF doesn't have a solution to this.
Problems with solution: Spammers will simply flock to this gaping hole,
as well as begin dredging up old DNS spoofing and poisoning attacks.
(By the way, that last bit about reputation systems seems to have been
added since last I read that page. I find it interesting, since that's
the approach I favor (and have done some work on), and I've insisted all
along that it must be coupled with other approaches. What bothers me
tremendously about SPF, aside from what I mention above, is that they're
willing to deploy without this crucial dependency, whereas I'd never
advocate rolling out one without the other! Without both pieces in
place, rolling out either is suicide.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 05:11:24PM -0600, David B Funk wrote:
> Read RFC-2821, section 3.10. It says:
> "When a message is
> delivered or forwarded to each address of an expanded list form, the
> return address in the envelope ("MAIL FROM:") MUST be changed to be
> the address of a person or other entity who administers the list.
>
> Note the "MUST".
> If majordomo does not do this then it is broken and should either
> be dropped or fixed (as I have no personal experience with
> majordomo I'm basing this upon your insinuation).
>
> Thus the only addtional condition that SPF requires is that the
> list maintainer address coincide with the list sending system.
>
Majordomo relies on the forwarding capabilities of /etc/mail/aliases.
It does set the envelope-from appropriately.
Thus (according to SPF), SRS must be implemented.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 8 Mar 2004, Mark C. Langston wrote:
> On Mon, Mar 08, 2004 at 04:31:38PM -0600, David B Funk wrote:
> > On Mon, 8 Mar 2004, Mark C. Langston wrote:
> >
> > > I wouldn't go so far as to call it "wonderful". It breaks mailing
> > > lists;
> >
> > No, decent list software sets the envelope-from address to point to
> > itself (check out the headers for this one). The receiving SPF should be
> > looking at the envelope-from not the header-From address.
>
> Paraphrase: Everyone should just stop using majordomo.
Read RFC-2821, section 3.10. It says:
"When a message is
delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be
the address of a person or other entity who administers the list.
Note the "MUST".
If majordomo does not do this then it is broken and should either
be dropped or fixed (as I have no personal experience with
majordomo I'm basing this upon your insinuation).
Thus the only addtional condition that SPF requires is that the
list maintainer address coincide with the list sending system.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 04:31:38PM -0600, David B Funk wrote:
> On Mon, 8 Mar 2004, Mark C. Langston wrote:
>
> > I wouldn't go so far as to call it "wonderful". It breaks mailing
> > lists;
>
> No, decent list software sets the envelope-from address to point to
> itself (check out the headers for this one). The receiving SPF should be
> looking at the envelope-from not the header-From address.
Paraphrase: Everyone should just stop using majordomo.
>
> > it breaks auto-forwarders (not just free email providers, but the
> > standard *nix .forward and /etc/mail/aliases);
>
> No, it does not break it, it just demands more sophistication on the
> forwarder's part. See http://spf.pobox.com/srs.html for one way to
> deal with this particular issue.
Paraphrase: fundamentally change your MTA infrfastructure, and for now,
if you're not using sendmail, you're SOL. Even if you are using
sendmail, you're SOL, because the C lib isn't ready.
>
> > it will cripple email
> > from mobile devices such as cell phones and PDAs, except for those
> > people willing to use the domain name provided by the cell provider, or
> > for those rare few with a phone or PDA capable of SMTP AUTH;
>
> OK, 15 years ago, almost -all- smtp servers were run in open-relay mode.
> It was considered a free service that you providied for your less-well
> connected bretheren. (also a holdover from the UUCP days. How many of
> the readers of this list have -any- clue what that means? ;)
I do.
> Also, nobody thought twice about using telnet and ftp to connect to
> sites remotely (ssh & SSL were not even a dream).
>
> Now even our network routers & switches provide SSH connectivity for
> management.
>
> Things change, time marches on, new problems/threats arize and people
> adapt.
>
Yes. But in every instance you mentioned above, both versions of the
underlying service operated concurrently, with no interference one upon
the other.
This is not true with SPF. Deployed sites will react to nondeployed
sites in a derogatory manner. Deployed sites will force unwanted and
unwarranted behavior change on users of said site.
The analogy doesn't hold.
> > it forces
> > everyone to upgrade to using SMTP AUTH enterprise-wide if you expect to
> > send an email from anywhere other than your desk (e.g., while
> > travelling, at an airport, hotel, coffeehouse hotspot, etc.)
>
> If you need to support devices that -cannot- do SMTP AUTH, there are
> workarounds such as pop-before-smtp. (kluge, but workable, we use it
> here).
Cell phones. Show me a solution that works with cell phone mail clients
as they are TODAY (not as they may be rewritten 3 years from now), and I
might buy into that. I've yet to see one do SMTP AUTH; I've yet to see
one do POP-before-SMTP; I've yet to see a START-TLS implementation.
Or shall we all just upgrade our phones as well?
If you think email from mobile devices is a non-issue, and further
believe it will remain so, you're sadly mistaken.
>
> > In short, it destroys the ability to send email from anything other than
> > the domain name of your ISP.
>
> Have you looked at the SPF "Objections Addressed" page?
> http://spf.pobox.com/objections.html
>
Yes, I have. And the answers amount to, "tough. Change your
architecture." That's not an acceptable solution in a boardroom.
That's not an acceptable solution in environments where architectural
changes occur on the order of months, not days. That's not an
acceptable solution where changes to field deployments are major
logistical undertakings.
And it's not an acceptable solution for those who require a vetting by
an established standards body (i.e., the IETF) before giving such
changes serious consideration.
> I agree that SPF is not a be-all-end-all solution to this mess but its
> the best looking answer so far.
>
A D+ is better than an F. Neither is desireable.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 8 Mar 2004, Mark C. Langston wrote:
> I wouldn't go so far as to call it "wonderful". It breaks mailing
> lists;
No, decent list software sets the envelope-from address to point to
itself (check out the headers for this one). The receiving SPF should be
looking at the envelope-from not the header-From address.
> it breaks auto-forwarders (not just free email providers, but the
> standard *nix .forward and /etc/mail/aliases);
No, it does not break it, it just demands more sophistication on the
forwarder's part. See http://spf.pobox.com/srs.html for one way to
deal with this particular issue.
> it will cripple email
> from mobile devices such as cell phones and PDAs, except for those
> people willing to use the domain name provided by the cell provider, or
> for those rare few with a phone or PDA capable of SMTP AUTH;
OK, 15 years ago, almost -all- smtp servers were run in open-relay mode.
It was considered a free service that you providied for your less-well
connected bretheren. (also a holdover from the UUCP days. How many of
the readers of this list have -any- clue what that means? ;)
Also, nobody thought twice about using telnet and ftp to connect to
sites remotely (ssh & SSL were not even a dream).
Now even our network routers & switches provide SSH connectivity for
management.
Things change, time marches on, new problems/threats arize and people
adapt.
> it forces
> everyone to upgrade to using SMTP AUTH enterprise-wide if you expect to
> send an email from anywhere other than your desk (e.g., while
> travelling, at an airport, hotel, coffeehouse hotspot, etc.)
If you need to support devices that -cannot- do SMTP AUTH, there are
workarounds such as pop-before-smtp. (kluge, but workable, we use it
here).
> In short, it destroys the ability to send email from anything other than
> the domain name of your ISP.
Have you looked at the SPF "Objections Addressed" page?
http://spf.pobox.com/objections.html
I agree that SPF is not a be-all-end-all solution to this mess but its
the best looking answer so far.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 11:57:29AM -0500, Steven W. Orr wrote:
> On Monday, Mar 8th 2004 at 18:42 +0200, quoth Ilan Aisic:
>
> =>A friend pointed me to:
> =>
> =>http://spf.pobox.com/
> =>http://spf.pobox.com/wizard.html
> =>
> =>Before I go and implement it in my DNS, I'd like to solicit opinions about
> =>it from the list.
> =>
> =>--ilan
>
> It's wonderful. Also, there's a an article on SPF in the current Linux
> Journal. It's one of two and it's written by the guy who created pobox.com
>
I wouldn't go so far as to call it "wonderful". It breaks mailing
lists; it breaks auto-forwarders (not just free email providers, but the
standard *nix .forward and /etc/mail/aliases); it will cripple email
from mobile devices such as cell phones and PDAs, except for those
people willing to use the domain name provided by the cell provider, or
for those rare few with a phone or PDA capable of SMTP AUTH; it forces
everyone to upgrade to using SMTP AUTH enterprise-wide if you expect to
send an email from anywhere other than your desk (e.g., while
travelling, at an airport, hotel, coffeehouse hotspot, etc.)
In short, it destroys the ability to send email from anything other than
the domain name of your ISP.
(NOTE: Before anyone goes on about "?all", I'll remind you that the
ultimate goal is to have everyone advertising "-all". I'll also point
out that, though per-IP exceptions are possible, the number and length
of TXT records will put an upper limit on how much massaging you can do
in this manner.)
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by "Steven W. Orr" <st...@syslang.net>.
On Monday, Mar 8th 2004 at 18:42 +0200, quoth Ilan Aisic:
=>A friend pointed me to:
=>
=>http://spf.pobox.com/
=>http://spf.pobox.com/wizard.html
=>
=>Before I go and implement it in my DNS, I'd like to solicit opinions about
=>it from the list.
=>
=>--ilan
It's wonderful. Also, there's a an article on SPF in the current Linux
Journal. It's one of two and it's written by the guy who created pobox.com
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
Re: Opinions About SPF
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 05:59:49PM +0100, Kjetil Kjernsmo wrote:
> AFAICS, it will be in 2.70,
3.0.0. ;)
> And I would assume that they developers wouldn't have added it if it
> wasn't good... :-)
SPF is the only anti-spoofing system that we're 100% behind actually. :)
--
Randomly Generated Tagline:
ome of the San Jose Sharks.
Re: Opinions About SPF
Posted by Kjetil Kjernsmo <kj...@kjernsmo.net>.
On Monday 08 March 2004 17:42, Ilan Aisic wrote:
> A friend pointed me to:
>
> http://spf.pobox.com/
> http://spf.pobox.com/wizard.html
>
> Before I go and implement it in my DNS, I'd like to solicit opinions
> about it from the list.
AFAICS, it will be in 2.70,
http://bugzilla.spamassassin.org/show_bug.cgi?id=2143
And I would assume that they developers wouldn't have added it if it
wasn't good... :-)
Cheers,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net webmaster@skepsis.no editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Re: Opinions About SPF
Posted by Dan Wilder <da...@ssc.com>.
On Mon, Mar 08, 2004 at 09:04:53AM -0800, Bart Schaefer wrote:
> On Mon, 8 Mar 2004, Ilan Aisic wrote:
>
> > Before I go and implement it in my DNS, I'd like to solicit opinions about
> > it from the list.
>
> "It can't hurt but it might not help much."
>
> SPF is designed to solve a specific problem: Joe-jobbing, that is, the
> forgery of your domain-part in the sender addresses of spam.
>
> It specifically cannot prevent a spammer from using any domain whose DNS
> is under his (legitimate or otherwise) control, on mail that is sent
> through open relays/proxies, hijacked PCs, etc., because all the spammer
> would need to do is advertise in his own SPF records that those locations
> are allowed to send his mail.
Or he could simply put up no SPF records at all.
SPF adoption will be at best spotty, and if you're going to bump up
score much for SPF entirely lacking, as opposed to SPF present but
indicating the mail came from the wrong place, you'll see significant
false positives.
That said, SSC's records are ready!
--
Dan Wilder
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 03:01:56PM -0800, Faisal N Jawdat wrote:
> >Let's not forget that SPF has yet to be vetted by the IETF.
> >Implementation seems to be skipping the entire technical evaluation
> >process.
>
> "consensus and working code"
>
Well, I don't yet see consensus. I see code, but it doesn't yet play
well with others.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Faisal N Jawdat <fa...@faisal.com>.
> Let's not forget that SPF has yet to be vetted by the IETF.
> Implementation seems to be skipping the entire technical evaluation
> process.
"consensus and working code"
-faisal
Re: Opinions About SPF
Posted by "Mark C. Langston" <ma...@bitshift.org>.
On Mon, Mar 08, 2004 at 09:34:04AM -0800, Jonathan Tai wrote:
> On Mon, 2004-03-08 at 09:04, Bart Schaefer wrote:
> > On Mon, 8 Mar 2004, Ilan Aisic wrote:
> >
> > > Before I go and implement it in my DNS, I'd like to solicit opinions about
> > > it from the list.
> >
> > "It can't hurt but it might not help much."
> >
> > SPF is designed to solve a specific problem: Joe-jobbing, that is, the
> > forgery of your domain-part in the sender addresses of spam.
> >
>
> True, but the more domains implement it... the more it helps.
>
The more domains implement it, the more DNS spoofing attacks will
rapidly come to the fore again.
Let's not forget that SPF has yet to be vetted by the IETF.
Implementation seems to be skipping the entire technical evaluation
process.
--
Mark C. Langston Sr. Unix SysAdmin
mark@bitshift.org mark@seti.org
Systems & Network Admin SETI Institute
http://bitshift.org http://www.seti.org
Re: Opinions About SPF
Posted by Graham Murray <gr...@gmurray.org.uk>.
Jonathan Tai <jo...@tgpsolutions.com> writes:
> On Mon, 2004-03-08 at 09:04, Bart Schaefer wrote:
>> SPF is designed to solve a specific problem: Joe-jobbing, that is, the
>> forgery of your domain-part in the sender addresses of spam.
>>
>
> True, but the more domains implement it... the more it helps.
And it would help even better if more domains implemented the
checking on their inbound mail servers. I publish SPF -all for this
domain (and the ones I administer at work) and still get joe-job
bounces from AOL even though they publish SPF records for their
outgoing mail.
Re: Opinions About SPF
Posted by Jonathan Tai <jo...@tgpsolutions.com>.
On Mon, 2004-03-08 at 09:04, Bart Schaefer wrote:
> On Mon, 8 Mar 2004, Ilan Aisic wrote:
>
> > Before I go and implement it in my DNS, I'd like to solicit opinions about
> > it from the list.
>
> "It can't hurt but it might not help much."
>
> SPF is designed to solve a specific problem: Joe-jobbing, that is, the
> forgery of your domain-part in the sender addresses of spam.
>
True, but the more domains implement it... the more it helps.
- Jon
--
jon@tgpsolutions.com
Administrator, tgpsolutions
http://www.tgpsolutions.com
Re: Opinions About SPF
Posted by Bart Schaefer <sc...@zanshin.com>.
On Mon, 8 Mar 2004, Ilan Aisic wrote:
> Before I go and implement it in my DNS, I'd like to solicit opinions about
> it from the list.
"It can't hurt but it might not help much."
SPF is designed to solve a specific problem: Joe-jobbing, that is, the
forgery of your domain-part in the sender addresses of spam.
It specifically cannot prevent a spammer from using any domain whose DNS
is under his (legitimate or otherwise) control, on mail that is sent
through open relays/proxies, hijacked PCs, etc., because all the spammer
would need to do is advertise in his own SPF records that those locations
are allowed to send his mail.