Subject: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/"

From: Douglas Otis <[email-masked]>
Date: Wed, 25 May 2005 16:51:13 -0700

The following is a greeting when subscribing to spf-discuss:
-------------------------------
> Hi!  You have asked to subscribe to the mailing list
> [email-masked].  If this is what you want,
> just reply to this message or click on the link below, 
> and you will be subscribed to the list.
> 
>   http://v2.listbox.com/subscribe/?confirm=xxxxxxxxxxxxxxx
> 
> This list is for open discussion of the proposed SPF standard.
> 
> Subscription to this list, and posting to it, is a privilege, not a
> right.
> The list operates according to the best practices described at
> RFC1855.
> You should also review
> http://www.ietf.org/proceedings/02mar/slides/plenary-3/  
> 
> Revocation of privileges operates according to an abbreviated form of
> BCP83.
> In short: kooks, crazy people, and rude people should expect to be
> unsubscribed.
> ,---
> | The SPF mailing list is intended for constructive discussion and 
> | promotion of SPF. If you believe that the SPF concept is
> | fundamentally flawed, please subscribe instead to the ietf-mxcomp
> | mailing list at http://www.imc.org/ietf-mxcomp/
> '---
> 
> The SPF standard originated as a hybrid of Gordon Fecyk's DMP
> proposal and Hadmut Danisch's RMX proposal.  It now provides
> a superset of their functionality.  More information at
>  http://spf.pobox.com/
> 
> November 2004: The Messaging Anti-Abuse Working Group
> sponsors a white paper titled Sender Authentication: What To Do.
> http://spf.pobox.com/whitepaper.pdf
> Please read it!
> 
> October 2004: Microsoft encourages the publication of SPF
> records.  Microsoft will use a modified form of SPF, known as
> "Sender ID", to check message headers in MUAs.  Most other
> MTA implementations continue to use SPF in its original form,
> to check the return-path at SMTP time.
> 
> Official announcements regarding SPF will be made on this list
> and also on the announcements-only list, [email-masked],
> so you don't need to subscribe to both lists.
> 
> List archives are available at
> http://archives.listbox.com/spf-discuss/current/
> 
> Read and contribute documentation at the Wiki!
>   http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
> 
> FOR DOMAIN OWNERS
> 
> SPF is now ready for widespread adoption.  If you control a
> domain, you should publish SPF records for it now.  You can
> get started at http://spf.pobox.com/wizard.html.  It takes most
> people about 10 minutes to learn about SPF and 5 minutes to
> write the records.
> 
> FOR MAIL ADMINS
> 
> You can download plugins for Postfix, Exim, Qmail, Sendmail,
> Exchange, and other MTAs from http://spf.pobox.com/downloads.html.
> 
> FOR DEVELOPERS
> 
> One of SPF's design goals is to be simple, quick, and easy for domain
> owners to publish records.  We have met this goal at the cost of
> some complexity on the client end.  Most developers accept this
> tradeoff.
-----------------------------------

It would appear subscription to spf-discuss acknowledges acceptance of
the SPF concept.  However, problems related to SPF have become even more
pronounced since dissolution of the MARID WG.  Sender-ID has usurped the
initial SPF record for PRA evaluation, and is advising use of methods in
conflict with bounce-address validation efforts.

The Sender Authentication Whitepaper, passed on to MAAWG from the FTC
conference, has not undergone requested changes.  There are several
assertions that remain misleading and in error.

SPF _is_ fundamentally flawed as it removes accountability from the
email providers, at the expense of the domain owners and consumers.
Contrary to the promotions, SPF will not stop spam.  SPF will not
prevent your domain from being forged, without great diligence by now
anonymous email providers, as well as, universal compliance at each
public MTA, and a slew of modification made to every email client.

I can not accept the premise there are no serious concerns related to
publishing SPF records.  No scheme without a reputation assessment will
prevent email abuse.  Abusers are among the first to adopt changes
offering greater access.  Reputation puts the teeth in any email
protection scheme.  Beware, SPF may bite!

You may get bit by recipients that consider SPF authorization is
equivalent to identifying the source of a message.  This assumption is
unsafe and wholly unfair.  This assumption is unsafe as forgery can
still continue.  This assumption is unfair as a basis for accruing the
reputation of a domain owner, as they often have no administrative
oversight with which to assure their protection.

Instead of SPF records preventing harm when a domain is forged, SPF
authorization may actually cause an otherwise impeccable domain obtain a
bad reputation, when forgery nevertheless continues.  Abusers may
actually utilize your SPF records to usurp previously good reputations.
What is worse, redemption of your reputation may not be practical. 

Abusers may take advantage of your desire to ensure your emails are
delivered.  Abusers may also take advantage of your email provider's
desire to not license Microsoft's Sender-ID algorithm, which sets terms
incompatible with open-source software.

The selected domain offering server authorization is assumed to have
originated the message.  Microsoft calls this unfair assumption, “Sender
Authentication.” Calling Sender-ID “Sender Authentication” would be like
me making a declaration that the postal service is authorized to deliver
my letters, where recipients are then claiming any letter received from
the postal service bearing my name anywhere is authentically or
genuinely from me.  Of course that would be a false assumption, and
Sender-ID is no different.

How will abusers take advantage of these normal desires and false
assumptions?  While strictly limiting authorization to just the email
provider's servers reduces some risk of your domain being forged, this
may cause your messages to become lost as a result.  This loss may occur
when recipients use providers that select accountable domains based upon
the “classic” bounce-address algorithm.  The recipient may forward
messages, which then makes your message appear to be from an
unauthorized server.  Your message may also become lost when sent
through some list-servers, or through servers running older versions of
email protocol.  Why quibble over who is responsible for implementing a
plethora of fixes, where any change to email often takes decades?

The remedy for the loss of your messages is to leave your SPF server
authorization list open-ended.  When from an unknown server, the
open-ended list then declares a lowered level of authorization.  This
lowered level of authorization is intended to alert recipients to
increase the scrutiny given such messages.  However, this lowered level
of authorization will not ensure your reputation remains protected from
forgery.

For example, abusers take advantage of Microsoft's automatic
image fetching to compile valuable lists of active email accounts, just
by using encoded image links.  These abusers don't really care which
folder or level of authorization they obtain.  They don't care that
recipients fail to respond to their email either.  These abusers would
be thrilled to see recipients unsubscribe.  Your concern is whether the
recipient also clicks the “spam” button, when these messages have forged
your domain. 

With SPF records being very public, your domain's reputation will be
exposed to any abuse possible.  Publishing open-ended SPF records may
even act as an invitation, should a SPF reference become mandated by
some providers.  Furthermore, a provider that does not ensure Sender-ID
headers are not in conflict with any of their other customers, may risk
your domain's reputation, especially when this provider's limitation
becomes known.  When viewed by Sender-ID, such providers can not ensure
your domain will not be forged.  Of course, Microsoft may see this
problem as being to their advantage.  Once this becomes enough of a
problem for domain owners, providers may find it necessary to license
Microsoft's algorithm after all.

With phishing techniques becoming seemingly epidemic, Microsoft is quick
to offer Sender-ID as a remedy.  With respect to phishing, Sender-ID
considers the From header as the lowest priority for basing acceptance,
even though this is the header typically seen by the recipient.
Microsoft has made this problem worse by displaying the user friendly
name, known as the “pretty” name, rather than the actual mailbox
address.

Phishing ploys often use disposable domain names for obfuscated links,
which could also provide SPF authorizations. SPF records can also be
constructed to covertly and fully authorize all servers within the
entire Internet.  SPF can covertly enable Zombies anywhere in the world.
Sender-ID, even as a lame phishing deterrent, presumes wide adoption of
proprietary algorithms by mail clients and providers.  Assurances
offered by Sender-ID aware applications are dangerous, due to the
acceptance of hidden headers, and expectations of compliance to these
proprietary algorithms.  This may actually place consumers trusting such
assurances in greater peril.

Sender-ID itself may weaken the integrity of the DNS, where Microsoft
only offers the advice that providers use "properly paranoid DNS
resolvers.”  Sender-ID requires that domain owners trust their email
providers, although many providers do not authenticate their own
customers.  Heedless publishing of SPF will expose domain owners to
substantial risk.  In addition, Sender-ID does not identify these
providers either, so there is little to directly motivate email provider
diligence.

Signatures are a safer alternative to this nonsensical approach that
depends upon a magic wand that mysteriously transforms “server
authorization” into “sender authentication.”  There is already a digital
signature technology, S/MIME, that can be handled by more than 400
million email clients such as Outlook, Outlook Express, Lotus Notes,
Novell Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora,
Becky!, Bat!, Mulberry, Blackberry, and more.  Surely, financial
institutions being phished can afford the digital certificates needed to
verify their From address.

Very soon major providers will offer DomainKeys signatures on outbound
messages, and will be checking these signatures when messages enter
their email gateway. The use of email signatures is on the near horizon.
DomainKeys can be deployed within email gateways, and easily
implemented.  Compared to S/MIME with browser Certificate Authorities,
DomainKeys lowers cost barriers, and does not depend upon the end-user
email applications.  When deployed for solicitations unrelated to
commerce, cost is often a greater concern as well.  Signatures can
indicate where the message originated, regardless of the use of
subsequent relays, or message forwarding, and offer a truly safe means
to defeat phishing attempts. 

Unlike signature methods, Sender-ID limits the domain owner's choice of
providers, and will likely create endless consumer complaints.
Signatures indicate where the message originated without changing
email's architectural paradigms.  Signature verification only requires
the recipient make the required checks, and is not required that these
checks be performed at every intervening server that relays the message.

Even spoofed bounce messages can be curtailed by signing the
bounce-address using Bounce Address Tag Validation.  Domain owners can
sign their own email, and safely use providers that may exercise dubious
diligence, without jeopardizing their domain's reputation or exposing
their recipients to phishing threats.  There is little benefit derived
from jumping upon the Sender-ID bandwagon, but there is much more to
loose when publishing SPF records.  Consider DomainKeys instead.

-Doug

---

From: Julian Mehnle <[email-masked]>
Date: Thu, 26 May 2005 03:02:48 +0200

Douglas Otis wrote:
> > [...]
> > [...]
> the SPF concept.

True.  Constructive criticism is welcome, but the SPF community is for the 
largest part convinced that the concept in itself is not fundamentally 
flawed, so any criticism that implies the contrary is not considered 
constructive.

We have had so many flamewars on spf-discuss in the past that it seriously 
disturbed any constructive work.  That made us, who were concinved of SPF 
and wanted to get some real work done, draw a line.

There are many forums where destructive criticism about SPF is welcome.  If 
you need one, you know where to find one.

> However, problems related to SPF have become even more 

Obviously, this is not an inherent problem of SPF, but a problem of the 
Sender-ID drafts.  We are currently working with the IETF to resolve this 
issue.

> email providers, at the expense of the domain owners and consumers.

This is a highly subjective assessment, nothing more.

> Contrary to the promotions, SPF will not stop spam.

Who is promoting SPF as an anti-spam solution?  I'd really like to know.

> SPF will not prevent your domain from being forged, without great
> diligence by now anonymous email providers, as well as, universal
> compliance at each public MTA,

Absolute security requires absolute deployment.  Not even PGP is going to 
absolutely guarantee the authenticity of your messages if 95% of the world 
can't check your signatures due to lacking PGP support.

> and a slew of modification made to every email client.

Nonsense.  Show us why.

> prevent email abuse.

SPF is about establishing authenticity.  Reputation assessment is separate.

> Abusers are among the first to adopt changes offering greater access.

He who favors messages simply because they yield SPF "Pass" results has not 
understood SPF.

> Abusers may actually utilize your SPF records to usurp previously good
> reputations.

Only if you let them.

> What is worse, redemption of your reputation may not be practical.

So, are you saying that the concepts of accountability and reputation are 
fundamentally flawed?

Besides, did I mention reputation assignment and assessment is separate 
from SPF?

The rest I don't bother commenting on.  I advise people to make up their 
own minds instead of buying into FUD.

> Beware, SPF may bite!

Woof, indeed!

---

From: Carl Hutzler <[email-masked]>
Date: Wed, 25 May 2005 21:24:20 -0400

Is this use of SPF flawed?

helo domain.com
mail from: [email-masked]

Look up domain.com SPF record

If the [connecting IP] = [SPF record] then "trust it more/whitelist"
else
do nothing
end if

Lets not destroy SPF records. They contain valuable reverse MX records 
which cover well over 95% of the email traffic on the internet today. If 
people choose to block based on negative SPF checks, it is their mail 
system and hence their rules.

Perhaps SPF should be updated to have the above logic. Maybe this would 
be an interesting topic to discuss with "them".

Back to my day job :-)

-Carl

-- 
Carl Hutzler
Director, Host Mail Development
America Online
[email-masked]
703.265.5521 work
703.915.6862 cell

---

From: wayne <[email-masked]>
Date: Wed, 25 May 2005 20:46:56 -0500

> Who is promoting SPF as an anti-spam solution?  I'd really like to know.

There are quite a few references on the spf.pobox.com website about
stopping spam.  Meng once said, and I agree with it, that SPF is an
anti-spam product like flour is a food.

-wayne

---

From: John Levine <[email-masked]>
Date: 26 May 2005 02:15:14 -0000

>Who is promoting SPF as an anti-spam solution?  I'd really like to know.

Let's take a look at http://spf.pobox.org.  Hey, look what it says:

  SPF is ushering in a new set of anti-spam systems, where email is
  spam unless proven otherwise.

If history is any guide, some SPF fan will write back in a huff and
say "That doesn't say SPF is an anti-spam solution!  It just says that
SPF is holding a flashlight and will lead the actual anti-spam
solutions to their seats!"

This kind of disingenuous doubletalk has characterized SPF advocacy
since its beginning, and is one of the many reasons that the
mainstream e-mail tech community holds SPF in disdain.  That along
with its egregious design mistakes and its irreparably enormous error
rate, of course.

SPF can help whitelist mail from fixed source senders you already
know.  That's what AOL uses it for, and it's an adequate if overly
complex means to that end.  If the SPF crowd promoted it for that
purpose, I don't think anyone would have a problem with it.  But they
don't and the smoke long ago became unbreathable.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 25 May 2005 20:16:59 -0700 (PDT)

> If the [connecting IP] = [SPF record] then "trust it more/whitelist"

Ok, what do you do with this?:

EHLO coolaid.example.net
MAIL FROM: [email-masked]

Yes, I'm interested in hearing from AOL perspective.

--- 
William Leibzon
Elan Networks
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 26 May 2005 13:06:09 +0200

[...]
> If the [connecting IP] = [SPF record] then "trust it

It's perfectly possible for a spammer to get a PASS.  You
wouldn't whitelist a spammer.  But it's impossible for a
spammer to pretend to be me, he'd get a FAIL (in my case).

Unless I'm this spammer of course.

> valuable reverse MX records which cover well over 95% of
> the email traffic on the internet today.

Is that a guess ?  95% is a rather high number.

> Perhaps SPF should be updated to have the above logic.

You can use it this way.  But whitelisting a PASS only
because it's a PASS is no long term strategy:

    "v=spf1 +exists:{ir}.comcast.blackholes.us -all" 

> Back to my day job :-)

Be careful with mail from these comcast IPs, bye, Frank

---

From: Carl Hutzler <[email-masked]>
Date: Thu, 26 May 2005 07:11:54 -0400

[email-masked] wrote:

> --- William Leibzon
Nothing different. The EHLO is not involved (unless we decide to do CSV 
:-) I should have left it out of my example.

---

From: Carl Hutzler <[email-masked]>
Date: Thu, 26 May 2005 07:20:37 -0400

>Unless I'm this spammer of course.

Actually, we DO WHITELIST SPAMMERS. I mean it happens. We don't want it 
to happen a lot, but it does. See we also monitor everyone on the WL 
very closely via volume, complaint, and bounce rates. So while a spammer 
could get onto the whitelist, they won't be for long. And a new spammer 
will have very low limits placed on how much they can send via a simple 
SPF=whitelist type method. Now if they prove once on the SPF=whitelist 
that they are a good sender, we would bump up their rate limits....or if 
they contact us to get "accredited" via our postmaster.aol.com webpage 
where you can simply ask to be on the whitelist, we might let them in 
with higher limits on day 1. We do this of course for well known 
organizations.

>Is that a guess ?  95% is a rather high number.
OK, 85%. Is that better? Still beats the 80/20 rule easily. How much 
mail is not sent directly from the sending ISP to the destination ISP. 
For AOL it is a small number.

>    "v=spf1 +exists:{ir}.comcast.blackholes.us -all" 

See above. It actually IS very good for AOL because of all our other 
reputation based logic. Perhaps not every ISP can build this, but we do 
have one. Of course many 3rd party products are out there that do what 
we do...SenderBase (volume/bounces), SpamCop (complaints), Spamnet 
(complaints), etc.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 26 May 2005 14:13:45 +0200

Carl Hutzler wrote:

> we also monitor everyone on the WL very closely

So you have PASS => assume WHITE until proven BLACK.

Yes, that's a better idea than C/R systems based on
PASS.

<joke>  postmaster@aol might still get some of these
obscure "rebounces" from me with a subject like...

Erroneous spam bounce to forged address - please use a filter and/or SPF

...but so far "my" spammers behave and gave up to
forge my FAIL-protected vanity domain.  </joke>

  [95% of the mails with a SPF policy]

> OK, 85%. Is that better?

Any number is fine, I only wanted to know whether I
should now troll various IETF lists with "Carl said
95% of the mail traffic already has v=spf1 policies"

Such hype is harmful if it's not true, see John's
ongoing rants about the infamous spf.pobox site - it
doesn't help when I say that I didn't link to it for
almost a year now, or that the SPF Council tried to
fix it for about five months - as long as this didn't
happen it's a weak spot.  SPF is no FUSSP.  FUSSPs
are stupid, like a perpetuum mobile.

> SenderBase (volume/bounces), SpamCop (complaints),
> Spamnet (complaints), etc.

I'm not very happy with SC allowing "misdirectred
bounces" to be reported without a (potential) FAIL.

Squeeze out all bounces isn't the plan.  Bye, Frank

---

From: Mark <[email-masked]>
Date: Thu, 26 May 2005 13:15:56 GMT

> Contrary to the promotions, SPF will not stop spam.

This is typically one of the noob objections. I will show you why, in the
larger scheme of things, SPF most certainly helps the fight against spam.

> ... and a slew of modification made to every email client.

You got yourself confused with the thingy from Redmond, didn't ya? SPF is
inter-MTA based, and requires no changes to email clients
whatso-frickin-ever.

> publishing SPF records. No scheme without a reputation assessment will

How poor, I must say, is your understanding of SPF. Especially so, since
SPF actually greatly helps the reputation assessment! SPF 'funnels', as it
were, the use of domain names through specified, authorized relays. Once
you have 'locked in' the authorized use of an SPF-protected domain name,
you can then confidently consult a reputation service for that domain. To
give an example, with SPF, I can now confidently query:

aol.com.rating.reputationservice.com

> Abusers are among the first to adopt changes offering greater access.

Which example allows me to counter the ever recurring noob-objection: "But
spammers can publish SPF records too, and so 'bypass' security by getting
a PASS!" Counter, because, due to the 'funneling' effect I just spoke of,
spammers will gradually be forced to use only their own domain names. At
which point they can be block-listed by domain name even.

To give an example again, say, a spammer registered "spammer.com", and
published SPF records to produce a "pass". With SPF, I can now confidently
query:

spammer.com.rating.reputationservice.com

You see? Causing a "pass", the spammer has only achieved to hang the noose
around his own, identified neck! This 'bypass', as noobs call it, is an
intended, and desired, effect of SPF.

And thus, SPF helps to facilitate the return of domain name block lists
and/or domain name based reputation databases. And a domain name based
reputation database has great advantages. For one, because the maintainer
of said database no longer has to bother with ever-changing IP addresses.
That is the beauty of SPF: the domain owners themselves define the
authorized IP addresses; the reputation database just lists domain names;
and the one making the query does the SPF query for domain X against the
connecting IP address to see whether the relay is actually authorized to
use the identity.

To sum it up:

1): Spammers causing their registered domains to "pass", only identify and
set themselves up to be block-listed.

2): Email sent with reputable domains, used without authorization by
spammers, are protected -- hence exempt from erroneously being counted
towards spam and bad reputation!

- Mark 
 
        System Administrator Asarian-host.org
 
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 26 May 2005 15:39:31 +0200

Mark writes:
> SPF is inter-MTA based, and requires no changes to email clients 
> whatso-frickin-ever.

The first time I looked at SPF was because I wanted to ensure that an 
email client was okay. Specifically, I wanted to check outgoing mail 
from a roadwarrior machine, and warn the user before sending any mail 
that would likely fail.

That job wasn't so easy. Not so easy.

Arnt

---

From: Mark <[email-masked]>
Date: Thu, 26 May 2005 14:02:05 GMT

> -----Original Message-----
> From: Arnt Gulbrandsen [mailto:[email-masked]]
> Sent: donderdag 26 mei 2005 15:41
> To: [email-masked]
> Cc: Mark
> Subject: Re: "If you believe that the SPF concept is
> fundamentally flawed,please subscribe at
> http://www.imc.org/ietf-mxcomp/"
>
>
>
> Mark writes:

> That job wasn't so easy. Not so easy.

It is up to the ISP/MTA how to deal with their roaming users. Typically,
SMTP AUTH / DRAC is used (that has nothing to do with SPF even, but
everything with your ISP not being an open relay and still allowing its
customers roaming access). So, if you send mail, from the road, through
the relay you authorized, then that relay should SPF "pass" you (provided
you use the correct domain name, of course).

Sending through someone else's, unauthorized relay may, indeed, present a
problem on the receiving end if they check SPF (and thus would reject your
mail). But that is the whole point: either we allow everyone to use every
domain name through every relay (they have access to), or we specify
authorized relays. If we do the latter, then naturally doing the former
will no longer work. I believe that is a good thing.

It will take some mentality adjusting, though; like way back when, when
people said: "I used to be able to send through every SMTP server I
wanted; and now, dangit, I can only use the ones I have been given
access to." That change, too, was a good thing.

- Mark 

---

---

From: wayne <[email-masked]>
Date: Thu, 26 May 2005 12:13:10 -0500

In <[email-masked]> Carl Hutzler <[email-masked]> writes:

> BTW, this issue of allowing someone to send through "someone else's
> relay" is a problem for ALL email authentication approaches except
> perhaps CSV and BATV. 

SRS/SES/BATV/ABBS have key distribution key distribution problems
similar to DK/IIM when end users try to send through someone else's
MTA.

I think that if there was an easy solution, someone would have thought
of it many years ago.  What we have is a bunch of different solutions
which require different changes to the current email environment to
work.  Which one you think is best often depends on your assumptions
about the costs and benefits of each solution.

-wayne

---

From: wayne <[email-masked]>
Date: Thu, 26 May 2005 12:18:12 -0500

In <[email-masked]> Richard Clayton <[email-masked]> writes:

> Hence, since they still want to spam, they will start sending email with
> borrowed domains from borrowed machines...  they are already doing the
> latter, they don't do the former because there's currently no need.  SPF
> would, if adopted, provide the evolutionary pressure for them to do so.
>
> Of course you may feel that if [email-masked] is so dumb as to install
> a spam-sending trojan that it serves him right if example.com gets a
> really bad reputation. However, if I have a need to swap email with
> example.com employees how exactly has SPF improved the situation here ?

example.com can quickly update their SPF record to remove the
offending IP address from their approved list.

-wayne

---

From: Mark <[email-masked]>
Date: Thu, 26 May 2005 18:36:58 GMT

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Richard Clayton
> Sent: donderdag 26 mei 2005 18:44
> To: [email-masked]
> fundamentally flawed, please subscribe at
> In article <[email-masked]>, Mark
> <[email-masked]> writes
>
> >To sum it up:
> >
> > 1): Spammers causing their registered domains to "pass",
> > only identify and>set themselves up to be block-listed.
>
> so it would be foolish of them to keep on using their domains

Ah, but they would not have much of a choice, now, would they? :) Because
registering their own domains, to make them SPF "pass",  was a stop-gap to
begin with, as they could no longer use the more reputable, protected
domains.

> > spammers,
> so they can't borrow domains and send the email from their machines
>
> with you so far :)

Yep; that's the idea.

> Of course you may feel that if [email-masked] is so dumb as
> to install a spam-sending trojan that it serves him right if example.com
> gets a really bad reputation.

In all fairness, yes. I mean, SPF will help you protect against the misuse
of your domain name by unauthorized relays. If you're no longer master of
your domain, so to speak, and your own, authorized machines start sending
out spam, well, then not even SPF can help you. But if you lost control
over your machine, then I'd say you probably have a bigger problem on your
hand than worrying about SPF.

> However, if I have a need to swap email with

If your own machines start spewing spam, against your will and control,
then your first order of business should be to tell your employees not to
chit-chat with others in email until they fixed the flagrant breach of
security. :) Seriously, though, here SPF cannot help you, either: in order
to exercise control over your domain, you kinda have to be in control of
your domain.

> Seems to me SPF might have a few advantages relating to
> back-scatter but that too much email is being forwarded
> for that to work out in the near future. However,
> promoting it on the basis that spammers will not change
> their behaviour doesn't seem to be justified.

Whoever promoted SPF on the basis that spammers will not change should be
taken into the backyard and shot. :) SPF counts on spammers to change!

Try and look at SPF from a 'selfish' perspective: if you protect your own
domain name with SPF, then whatever other domains spammers use, at least
it won't be yours. And that 'selfish' point of view is really all a domain
owner is interested in: "So what if spammers will go use X instead? At
least they're not using Y any more, which is mine. And if that bothers the
domain owner of X, he is free to do the same."

- Mark 

---

---

From: Carl Hutzler <[email-masked]>
Date: Thu, 26 May 2005 10:47:58 -0400

BTW, this issue of allowing someone to send through "someone else's 
relay" is a problem for ALL email authentication approaches except 
perhaps CSV and BATV. DomainKeys, SPF, IIM, and SID all have an issue 
until we can get MUAs to sign with DK/IIM.

-Carl

---

From: Julian Mehnle <[email-masked]>
Date: Thu, 26 May 2005 20:46:11 +0200

> until we can get MUAs to sign with DK/IIM.

If end-users (MUAs) are to use shared private keys (e.g. for a common 
sender domain), the confidentiality of the private keys is at risk.

If end-users are to use user-specific private keys, they could very well 
use PGP or S/MIME right away.  IMO this is the direction things need to be 
going.

---

From: Richard Clayton <[email-masked]>
Date: Thu, 26 May 2005 19:53:32 +0100

In article <[email-masked]>, wayne
<[email-masked]> writes

>offending IP address from their approved list.

fair enough -- but this is reactive and the reputation service will have
been complained to at the same time, possibly well before, example.com
learnt of the problem. The reputation of example.com (which apparently
SPF is going to allow me to judge) will still suffer.

or are you expecting the reputation not to be for example.com but for
each individual part of it...   if so then I'm still unclear what SPF is
bringing to the party here. 

now consider where example.com is a large company (or an ISP) running a
small number of mail servers then (a) the action is NOT going to be to
change the SPF record but to revoke an authorisation and (b) it's even
more opaque as to how the reputation service can reflect that this has
been done or quite what SPF has contributed

once again, I don't mind SPF being promoted for what it will do, but
when it is argued that other things will flow from that then the
justification really doesn't seem to stand up.

I repeat my advice from another place to give up proselytising how SPF
will make a better world and just concentrate on a comprehensible,
interworkable standard that doesn't break anything else. If it then
turns out to have magical powers and cures cancer and stuff then that's
peachy. But its unnecessary to promote that up front.

- -- 
richard                     richard.clayton  @  h i g h w a y m a n . com

"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

---

From: Terry Fielder <[email-masked]>
Date: Thu, 26 May 2005 15:06:28 -0400

Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Please point me to this "comprehensible, interworkable standard that 
doesn't break anything else. "  (Isn't that the FUSSP?)

Meanwhile, I am betting on SPF.

Terry

> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
> 
> iQA/AwUBQpYbLJoAxkTY1oPiEQJ2xQCgoA/MSyIgMRnBKeVsyscCJuFW4vgAn0ag
> WmLALimrRXuZvrDwyiqLmP8i
> =C5i1
> -----END PGP SIGNATURE-----
> 

-- 
Terry Fielder
[email-masked]
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085

---

From: wayne <[email-masked]>
Date: Thu, 26 May 2005 14:57:57 -0500

> peachy. But its unnecessary to promote that up front.

I tend to agree with you.  Unfortunately, one of the problems with
open projects that have no membership requirements and only vague
leadership roles is that anyone can say anything and still claim to be
part of the community.

The membership requirements to be in the SPF community is slightly
less strict than the membership for the IETF, but the organization of
the SPF community is far less formal than the IETF.

-wayne

---

From: Richard Clayton <[email-masked]>
Date: Thu, 26 May 2005 17:41:20 +0100

with you so far :)

>are protected -- hence exempt from erroneously being counted

Seems to me SPF might have a few advantages relating to back-scatter but
that too much email is being forwarded for that to work out in the near
future. However, promoting it on the basis that spammers will not change
their behaviour doesn't seem to be justified.

Or have I missed something, and if so what ?

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin