Subject: draft-schlitt-spf-classic-01.txt

From: Douglas Otis <[email-masked]>
Date: Thu, 26 May 2005 13:02:25 -0700

My previous message was to explain why the MARID reflector is being used
for these comments.  SPF could offer white-listing utility, provided
there is consensus on the record's scope.  Such use requires that this
scope be defined, or not used as a basis for accruing reputations.  Of
course, this would make SPF useless for anything other than
white-listing.  Nor would I trust anyone to honor such exclusion.
However, SPF proponents still insist this mechanism is fair with respect
to assessing reputations.  I say it is fundamentally flawed, as
assumptions of assured identifiers place domain owners in serious
jeopardy.

The email provider must be held accountable in any meaningful approach
for abating abuse.  However, SPF avoids such accountability.  A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners.  Only signatures offer domain owners a
modicum of control and oversight in their pursuit of protecting their
domain's reputation. 

Be that as it may, I see this effort as reducing the harm created by
SPF. : <

1.  Introduction
,----
| The current e-mail infrastructure has the property that any host
| injecting mail into the mail system can identify itself as any domain
| name it wants.  Hosts can do this at a variety of levels: in
| particular, the session, the envelope, and the mail headers.  While
| this feature is desirable in some circumstances, it is a major
| obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").
| Furthermore, many domain name holders are understandably concerned
| about the ease with which other entities may make use of their domain
| names, often with malicious intent.
'----

This paragraph lists many different identities that could be used to
identify the sender, and implies any could be examined to discover
possible server authorization.  As just mentioned, some still consider
this provides a method for performing sender authentication.  These same
individuals will happily block any such domains, once they are assumed
abusers.  After all, abusers can and will also publish SPF records.

A disagreement regarding which of these identifiers MUST be assured by
the sending server (to protect their client's reputation) occurs within
this draft and the draft-lyon-senderid-core-01.txt.  It is amazing that
this happens even though both of these drafts share the same author.  Of
course, protecting one's reputation depends upon this important detail.
However this draft only defines use of MAILFROM within the message, and
ignores this rather serious concern.  This is not FUD, this is just
F. : )

Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
serious harm.  This harm could originate from a Zombied computer of such
a customer.  The abuser may utilize SPF records to obfuscate where the
message originates to prolong their success, when seeing such messages
are not blocked by the sending server.

SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender. (I want to
say based upon "Sender Assumptication.")  How can the domain owner
restore the use of their domain, after their provider naively believes
they can assume how a record will be interpreted which has an undefined
scope?  Wouldn't providers be negligent when advising the use of SPF and
not making strict PRA validations?  Publication of a dummy record for
PRA, which may cause loss of messages, does not seem a satisfactory
solution, as provided in the Sender-ID draft.

10.2.  SPF-Authorized E-Mail May Be UBE
,----
| The "MAIL FROM" and "HELO" identity authorizations must not be
| construed to provide more assurance than they do.  It is entirely
| possible for a malicious sender to inject a message using their own
| domain in the identities used by SPF, to have that domain's SPF
| record authorize the sending host, and yet the message content can
| easily claim other identities in the headers.  Unless the user or the
| MUA takes care to note that the authorized identity does not match
| the other more commonly-presented identities (such as the From:
| header), the user may be lulled into a false sense of security.
'----

An interesting, albeit fuzzy, warning indeed.  Add another warning of a
similar nature.  Because there may be an assumption made regarding
server "authorization" (even potentially a neutral authorization) being
equivalent to sender "authentication," your domain may be attributed for
abuse which forges any identifiers other than MAILFROM.  Microsoft
describes a PRA process based upon this specific SPF record, used in
conjunction with SmartScreen, for example.  This creates the potential
for serious harm to the domain owner's reputation, when providers ignore
potential PRA conflicts.      

Add a warning that examination of the PRA is REQUIRED for cases where
the recipient uses draft-lyon-senderid-core-01.txt, which only utilize
the record syntax described in this draft.  Publishing an SPF record
will not ensure which identifier will be held accountable for abuse.  If
your email-provider does not license the PRA algorithm, there should be
no expectation that your domain's reputation is being protected.

I'll be happy to agree with Carl about the white-listing utility of an
SPF record.  To repair this draft, there appears little choice, but to
adopt the later version of the SPF record which includes the scope of
the identifiers assured by the sender.  That was the reason for
including scope in the first place.  Ignoring this issue would be
ignoring a rather big elephant in the room.  It would also represent
serious negligence on the part of the provider.

10.  Security Considerations
,----
| SPF implementations SHOULD limit the total amount of data obtained
| from the DNS queries.  For example, when DNS over TCP or EDNS0 are
| available, there may need to be an explicit limit to how much data
| will be accepted to prevent excessive bandwidth usage or memory
| usage, and DoS attacks.
|
| MTAs or other processors MAY also impose a limit on the maximum
| amount of elapsed time to evaluate check_host().  Such a limit SHOULD
| allow at least 20 seconds.  If such a limit is exceeded, the result
| of authorization SHOULD be "TempError".
'----

With this draft mandating more than one hundred DNS lookups, this raises
a concern regarding how the 20 second time limit is employed.  A local
recursive DNS resolver may act as a UDP amplifier.  Congestion avoidance
depends upon the application making the requests to wait, in order to
maintain stability.  

There should be some language that warns against doing these many
lookups in parallel, and simply timing out the effort to resolve server
authorization for a particular message.  If parsing routines have not
made these provisions, then setting up a two-tier DNS resolver where the
Internet facing DNS resolver is not recursive and is rate limited on
port 53, could offer a solution.

There should also be a warning about acceptance of duplicate records.
The same two-tier approach would offer protection when older DNS
resolvers are being used that do not ensure replicate lookups are
prevented.  
 
-Doug

---

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

Thanks for your review.

Douglas Otis wrote:
> little more than domain owners.

Why do you think ISPs must be held accountable instead of domain owners?

> Only signatures offer domain owners a modicum of control and oversight in
> their pursuit of protecting their domain's reputation.

Why?

> [...]
> serious harm.

If you are talking of cross-user forgery, see SPF, section 10.4[1].  This 
isn't something that can generally be solved by an authorization protocol 
that works with a granularity of IP addresses.

If you are talking of something else, I don't know what it is.

> This harm could originate from a Zombied computer of such a customer.
> The abuser may utilize SPF records to obfuscate where the message
> originates to prolong their success, when seeing such messages are not
> blocked by the sending server.

How could SPF records be used to "obfuscate" a message's origin?  The last 
time I looked, SPF didn't suppress the generation of "Received:" headers.

> that attribute domain abuse based upon the "assumed" sender.

So what?  Receivers are already doing the same with IP address white- and 
black-lists.  The world has not gone up in flames, though.

> How can the domain owner restore the use of their domain, after their
> provider naively believes they can assume how a record will be
> interpreted which has an undefined scope?

(I assume you aren't implying that the concepts of accountability and 
reputation are fundamentally flawed.)

There are no SPF records with an undefined scope.  If, for v=spf1 records, 
receivers choose to apply Sender-ID's inconsistent scope definition (PRA) 
over that of SPF itself, is it SPF's fault?

Have you complained already to Microsoft and the IESG about Sender-ID 
redefining v=spf1 records?  If not, why do you keep bringing up this issue 
here?  To say that even though this inconsistency is not SPF's fault, 
another draft can always be employed to destroy its usefulness?

What if I submitted a draft to the IETF that conflicted with the DomainKeys 
specification?  Would that make DomainKeys useless (or harmful)?

> [...]
> With this draft mandating more than one hundred DNS lookups,

The SPF specification does not "mandate more than one hundred" DNS lookups.  
It mandates that a receiver must be prepared to perform at most 111 DNS 
lookups.  This does not mean that the usual case is anywhere near that.

> this raises a concern regarding how the 20 second time limit is employed.
> A local recursive DNS resolver may act as a UDP amplifier.  Congestion
> avoidance depends upon the application making the requests to wait, in
> order to maintain stability.
> [...]

This sounds like a valid concern.

> There should also be a warning about acceptance of duplicate records.

What do you mean by "duplicate records"?

Again, thanks for your review.

Julian.

References:
 1. 
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01.html#cross-user-forgery

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 May 2005 21:02:08 -0700

> Why do you think ISPs must be held accountable instead of domain owners?

Abating abuse requires diligence.  This diligence involves the
monitoring of servers.  To protect the privacy of other customers, much
of an MTA server's operation remains hidden from the domain owner, who
is often just one of many typical customers.  With SPF reliance on the
mailbox-domain, the server's administrator remains anonymous.  Negligent
server operation will not directly impact the administrator, but instead
impacts the domain owner.  A reputation system should hold accountable
those who are expected to maintain diligence in respect to security,
access, and operation.  Holding an innocent, feckless party accountable
is simply an unfair practice.  Dare I say even foolish?

By the time a domain owner is made aware that volumes of abuse has
emerged from some SPF authorized server, forging their mailbox-domain in
some unexpected header, the reputation of their domain may have become
unsuitable for email.  The means to recoup their reputation in this
situation may not be practical. 

The domain owner may be innocent.  They may also view their domain as
highly valuable.  They may also be required to seek expensive legal
avenues to uncover the cause of their dilemma.  With SPF building upon a
filtering paradigm, there may be no outward indication their messages
are being silently dropped or placed into junk folders either.  It is
not clear how the domain owner will recover reliable use of their email
domain after publishing SPF and then being exploited.

This is a very real concern being completely ignored by providers
anxious to rid themselves of their responsibilities with respect to this
menacing abuse.  Nevertheless, abating abuse requires holding
administrators accountable and ensuring they stay on top of security,
access, and operational issues.  A reputation scheme MUST identify the
source of abuse, and not the "assumed" source of abuse.  A reputation
scheme must hold those responsible, accountable.  SPF fails badly on
both of these issues.  It is folly to think SPF will improve the
integrity of email or diminish the rate of abuse.  A reputation scheme
based upon SPF authorization is certain to dramatically reduce email's
integrity for the majority of domain owners.

> > their pursuit of protecting their domain's reputation.

By retaining a signature operation within their administrative control,
the domain owner would have far greater control over the fate of their
domain's reputation.  They could utilize the services of an email
provider to relay email from a dynamic location, without fear other
abusive messages may be confused as being from them.  If their relay
provider was lax at security or preventing abuse, the domain owner can
seek a different provider to rectify any resulting problems.

You should put yourself into your customer's position.  Proclamations
that with SPF, some domain can not be forged are specious.  This of
course assumes closed-ended list, where the domain owner maintains
exclusive access to their servers.  Closed-ended lists are not
practical, nor do most domain owners manage their own MTAs with
exclusive access. 

A domain owner that protects the private portion of their signature,
does not depend upon an email provider to protect their reputation.
Especially an email provider with dubious motives asking them to publish
SPF records.  How on Earth can publishing an SPF record be in the
interest of the domain owner, after Microsoft proclaims server
authorization is the same as sender authentication?

A DomainKeys signature associated with the Sender header allows the
provider to accept accountability for their customers, without mandating
their customers change their email addresses or publish DNS records.
The provider could also offer to relay messages already signed by their
customers as well.  Either of these scenarios would be fair.

With prior knowledge of the sender, perhaps in the case where an SPF
record is being used to establish a white-list, SPF could offer utility.
White-listing may be practical for typical bulk emailers, but not for
the majority of email domains.  However, DomainKeys could supplant
reliance upon white-listing, without the overhead needed to maintain a
complex database that may create problematic overlaps.

> that works with a granularity of IP addresses.

You misunderstood the concern.  An email provider likely handles
customers using many different mailbox-domains.  Yes, there could be
cross-user forgery within a domain, but that was not the concern.  There
could also be cross-domain forgery.  The provider is expected to make
assurances that some range of domains is permitted specifically for
those provided access to the MTA.  If the provider does not properly
authenticate the user (some still exchange passwords in the clear), or
does not evaluate the PRA, the domain owner is placed at risk by
publishing SPF records.  The sender does not know what the recipient
uses to base their reputation assessments.  Someone can get seriously
hurt heedlessly publishing SPF.

> time I looked, SPF didn't suppress the generation of "Received:" headers.

Anyone that utilizes a large provider and publishes an SPF record that,
in effect, proclaims such use, could enable an abuser to send from the
correct server, while still lying about who they are.  SPF does not
prevent this problem.  SPF requires assumed checks that may or may not
be performed.  In fact, some of these checks may require a license. : (

The abuser may wish to play this game until they have scorched the
reputation of that domain, before usurping the identity of the next
available victim, all while thanking SPF for making their fun possible.

> black-lists.  The world has not gone up in flames, though.

Quite typically, providers that employ a black-hole listing service,
will indicate the website of this service in the error message returned
in the session refusal.  The person sending the message can opt to
immediately try a different provider to send their message.  They may
also elect to complain to the black-hole listing service that indicated
the MTA they utilized is not properly administered.

Perhaps the server administration permitted access to the wrong person,
perhaps they accidentally enabled an open-proxy in their network,
perhaps they even allowed an open-relay.  Whatever the problem, the
sender often knows where to go for restitution.  As SPF is intended to
assist the filtering of messages, filtering often employs a practice of
placing uncertain results into a junk folder.  With SPF, there are many
shades of gray. : (

> reputation are fundamentally flawed.)

The assumption that a mailbox-domain can be authenticated without the
use of a signature is fundamentally flawed.  Server authorization is far
too weak to base a presumption of having authenticated the sender.
Server authorization in the manner of SPF also wrecks havoc on email's
architecture.  There is no reason for this, when signatures require less
effort and create less collateral damage.

> over that of SPF itself, is it SPF's fault?

So are you going to tell a 900 pound gorilla they are wrong?  In the
end, the gorilla will have their way with you.  ; )

> another draft can always be employed to destroy its usefulness?

Strange, I see the same author on both drafts?  Who's fault is that?
Depreciate the use v=spf1 to be assured of avoiding this serious
conflict.

> specification?  Would that make DomainKeys useless (or harmful)?

What patent licensing restrictions would you impose?  Are you large
enough to make your claims a serious concern?  Would you be asking
domain owners to fall into a trap, which over time as a ubiquitous
reputation program is applied, necessitates domain owners find providers
that license your scheme?

> lookups.  This does not mean that the usual case is anywhere near that.

Odd, but I see a required minimum as a mandate, and 111 is more than
100.  If there are on average 5 queries created for every lookup, this
could mean 555 queries are required to resolve a server's authorization
for a single message. 

> What do you mean by "duplicate records"?

DNS transactions are only protected by a 16 bit integer.  Often routines
utilize the UDP port to multiplex results.  The sequence of Domain Name
Server queries dictated by an SPF script may expose the port being used.
There is also a further risk that replicate queries, as possible with
Bind 8 for example, may again greatly increase the chances of guessing a
transaction.  As this can be caused to happen repeatedly, success does
not need to be 100% for this to be a concern.  The two-tier
recursive/non-recursive resolver was suggested as a defensive measure.
It just seems more informative than recommending DNS paranoia. 

-Doug

---

From: Terry Fielder <[email-masked]>
Date: Fri, 27 May 2005 08:44:00 -0400

> situation may not be practical. 

Interesting so if SPF fails then SPF will fail.

I say this because the only way the domain owners reputation could have 
gotten tarnished was if either:
1)  they did not implement SPF to protect forgery of their domain
OR
2)  they did implement SPF, and it failed to protect the forgery of 
their domain

SPF cannot be help responsible for #1

#1 can only happen if SPF doesn't work, but if SPF doesn't work then all 
this is moot.

Perhaps Doug, you are not talking about SPF, because "some unexpected 
header" sounds an awful lot like you are referring to the la-la 
dreamland that is PRA.

And SPF is *not* PRA.  Please don't confused between PRA and SPF (no 
matter what Meng has on the damn pobox website).

> are being silently dropped or placed into junk folders either.  

*sigh*

PRA may do silent dropping of email after acceptance..

SPF does MTA time rejection, so the sending MTA *must* know that the 
email was undeliverable, which guarantees all real, legit connecting 
MTA's get a clear rejection on the delivery status.

SA is the only major filtering that uses SPF after the fact, and even a 
FAIL scores less then 1 (0.8 something by default) and SA recommends not 
rejecting emails that score less than 5-10, then SPF unto itself cannot 
be what caused the rejection after acceptance.  Something else scored 
the other 4-9 points that were need to cause the email to be rejected by SA!

So don't say SPF causes silent dropping of email, its simply not true. 
Certainly not in the recommended use of SPF (MTA time rejection) and not 
even in the common not recommended use of SPF (SA).

> It is

Domain owners can be exploited if they don't publish SPF, nothing 
changes by publishing SPF except, if SPF really does work (as time has 
shown once forwarders are fixed), SPF may prevent forgery that is the 
exploitation that could have resulted in bad reputation.

> menacing abuse.  

SPF is not ignoring concerns.  The concerns you have stated are either 
unfounded or apply to PRA, not SPF.

> Nevertheless, abating abuse requires holding
> access, and operational issues.  

Are you suggesting every MTA operator review all inbound email for 
forgery/spam/viruses and do something with the ones that are bad?  Glad 
I am not paying that bill.

> A reputation scheme MUST identify the
> source of abuse, and not the "assumed" source of abuse.  

SPF is not a reputation scheme.

SPF is a means to make reputation schemes accurate by preventing forgery.

> A reputation
> both of these issues.  

No, it doesn't.  A reputation scheme allows domains to obtain 
credibility (or not) based on what the domain has done in the past.

SPF simply improves the ability for reputation schemes to be accurate by 
preventing forgeries from affecting the reputation database.

> It is folly to think SPF will improve the

I would love to see your facts, or testing, to justify this statement. 
Sounds like FUD.

> the domain owner would have far greater control over the fate of their

Smells like you want to sell domain owners (or their ISP/MSP) something. 
  A certificate perhaps?  At least now I know your motivation for 
attacking SPF.

> They could utilize the services of an email
> abusive messages may be confused as being from them.  

Thank you for endorsing the use of SPF (because that is what SPF does, 
only without the need for MUA upgrades to check signatures, and no need 
for buying certificates).

> If their relay

Which is a good idea no matter what security protocols one implements 
(or not) for their domain.  Hence, thanks for the advice (albeit off 
topic or not specific to SPF).

> that with SPF, some domain can not be forged are specious.

Only when receiving MTA's don't implement SPF (or some other form of 
domain anti-forgery technique).  But those MTA's don't matter because 
they won't bother to implement submission of forged emails to domain 
based reputation lists (or would be irresponsible if they did).

>  This of
> exclusive access to their servers.  

Please explain, because I don't understand how you could possibly think 
that (recall the include and redirect mechanisms).

It does require that if they relay through their ISP's mail server(s) 
that their ISP publishes SPF, but how is that unreasonable?  (No domain 
authentication/authorization scheme can work 100% unless it has 100% 
deployment, and cannot be held responsible for not working where it is 
not deployed)

> Closed-ended lists are not

Ah, so now you are talking about cross customer forgery within the same 
ISP.  Well, either your ISP has to implement protocols to stop cross 
customer forgery (or be proactive about dealing with it, but I don't buy 
that)  or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY.

But bottom line, the majority of forgery I doubt very much comes from 
the same ISP as the domain owner.  (That's my experience from my log 
files, its someone else, often over seas, faking to be a user from my 
domain to see if I foolishly whitelisted by own domain name).

> does not depend upon an email provider to protect their reputation.

Unless of course, there are other people in the world how have not 
implemented signature protection.  Hmm, where have I heard before there 
could be failures if a protocol doesn't have 100% deployment?

> authorization is the same as sender authentication?

If you see the folly of what Microsoft is trying to do to use SPF 
records in ways not intended, GREAT!  But that is not fault of SPF.

No matter what they did, the police could not stop my neighbour from 
drinking and driving.  Even when they impounded his car he then stole a 
neighbours car.  Does this mean that to solve the problem the police 
should take cars away from everyone?  No.  They put the guy in jail 
because HE was the one that did wrong.

And SPF should not be discouraged because MS is abusing it.  MS should 
be stopped from abusing it.

> their customers change their email addresses or publish DNS records.

That's a great idea.  Let me know when there is a free version of 
DomainKeys.  And it works with mailing lists.  And it doesn't "violate 
the anonymity" of email (not that I believe that email should be 
anonymous, but that's one of the big whines I hear against correcting 
forwarding).

> customers as well.  Either of these scenarios would be fair.

But not free.

> complex database that may create problematic overlaps.

I hear the words but I just don't see the weight of the arguments.

> publishing SPF records.  

Uh, NO.  SPF records should not be used to evaluate the PRA.

> The sender does not know what the recipient

They do for receivers that correctly implement protocols (e.g. do not 
use SPF records for PRA).

Someone could get seriously hurt if other protocols like TCP keepalives 
are not properly implemented.  That doesn't mean we shouldn't use TCP. 
(repeat my drunk driving lecture here).

> prevent this problem.  

Neither does domain keys, until of course the ISP/MSP upgrades the MTA 
to prevent cross customer forgery.  Once that is done, then EITHER 
method works.  Amazing, if everything is done then everything works, and 
if only some things are done then only some things work.  Fascinating.

> SPF requires assumed checks that may or may not

Huh?

> available victim, all while thanking SPF for making their fun possible.

Ditto for any forgery method that can be circumvented.  Including 
domainkeys.

> the MTA they utilized is not properly administered.

Email that fails authorization/authentication do not get 
checked/submitted to lists BECAUSE they have failed.  Its only if the 
email passes that you then check the domain against lists.

> assist the filtering of messages

NO NO NO.  It is to be used for MTA time rejection, not post acceptance 
filtering.  And SA uses it for post acceptance filtering, but SPF unto 
itself will not cause the email to be rejected due to the incredibly low 
score a FAIL is assigned.

> , filtering often employs a practice of

SPF is *not* PRA.  Please stop the FUD.

> use of a signature is fundamentally flawed.  

In your opinion, especially if your opinion is to sell domainkeys.  The 
only thing that could be considered "flawed" is that it disallows 
anonymous forwarding without implementing some other forwarding method 
(such as SRS, SES).

> Server authorization is far

Your argument does not hold even a drop of substance against the 
HELO/EHLO name checking of SPF.

And it doesn't hold any credence if one (like I) don't believe in 
anonymous forwarding.

> effort and create less collateral damage.

But signatures cost more money, requires MTA's everywhere to upgrade 
(even those that don't WANT to participate), how is that not collateral 
damage?

> end, the gorilla will have their way with you.  ; )

The Open source community is a 1000 pound gorilla, once it aligns its 
forces.  Just because some big powerful idiot is king, does not mean the 
kings way is right.  Look through the history books, its what mutiny and 
revolution are all about.

> Depreciate the use v=spf1 to be assured of avoiding this serious

Cute.  Why can't you just deploy DomainKeys, and let the best product 
win.  Why must you resolve to attack SPF?  Are you that fearful that SPF 
will succeed in the end that you feel a need to attack it to try to get 
DomainKeys deployment to catch up?

> What patent licensing restrictions would you impose?  

Nothing valid.  But who said the MS patent crap is valid?  Its not even 
issued yet, just applied for.

> Are you large
> enough to make your claims a serious concern?  

You don't need to be large to apply for a patent.  But your missing the 
point, the point was if someone applied for a patent that conflicted 
with domainkeys, does that make domainkeys bad?  I think not.

> Would you be asking

Um, that sounds like PRA, not SPF.  Nothing like SPF at all in fact. 
Interesting though, I wonder if it sounds like domainkeys?

> could mean 555 queries are required to resolve a server's authorization

Which would be cached.  And the boundary case is likely only reached on 
those trying to spam or do a DOS attack.  But spammers don't win, 
because their email is still delayed.  And DOS attackers, well dealing 
with DOS is a fact of life no matter WHAT protocols one implements.

> It just seems more informative than recommending DNS paranoia. 

Agreed.  IF one is using a DNS service with known vulnerabilities and IF 
this and IF that THEN, well, you deserve to be vulnerable, don't you?

Terry

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 May 2005 14:36:45 -0700

> 1)  they did not implement SPF to protect forgery of their domain

Publishing SPF, even offering low levels of "server authorization," is
mistakenly viewed by some as "sender authentication" of the domain.
Publishing SPF provides these recipients with what they believe to be
confirmations, albeit flimsy, that your domain has actually sent the
message.  Publishing any SPF record unfortunately exposes your domain to
these widely promoted, but contemptibly false assumptions.

Not offering this damning confirmation is the only sure means to avoid
being assessed in this manner.  Rather than being incensed and reckless
by publishing SPF records, when weary of the spoofs and thinking SPF is
your salvation against this sea of troubles, consider your options
carefully.  Know your exposures.  SPF and abusers together pose very
serious threats.

> 2)  they did implement SPF, and it failed to protect the forgery of 

You have again assumed the domain owner publishing SPF is in a position
to wage a defense against the forgery of their domain.  SPF places this
duty onto the faceless email provider, who remains unscathed by their
acts of negligence.  They may even claim proprietary checks are outside
their bailiwick, although it then offers an avenue for the forger to
impugn your reputation.

> SPF cannot be help responsible for #1

There are some providers that wish to force use of SPF, and there lies
the rub.

> matter what Meng has on the damn pobox website).

Millions of users soon will be running an application that will accrue
"user feedback" against the Purported Responsible Address algorithm
confirmed with the v=spf1 record, as widely promoted.  You would be
rather foolish to ignore this.  As an expert, you would be negligent
advising anyone to publish an v=spf1 record, and not insist they also
require PRA conflict protections.  The first question a wary domain
owner would need to ask, "Do you enforce the PRA for all of your
customers?"  

How is it that the same author appears on these two drafts, and yet this
conflict is not taken far more seriously?  Offering advice to ignore
Sender-ID would be outright laughable, if it were not so serious.  How
will you indemnify your customers from such negligence?

> even in the common not recommended use of SPF (SA).

Yes, the PRA may make this much worse.  What happens at the back-end,
when the PRA algorithm is a plug-in for Outlook?  Now you have both
wonderfully weak algorithms being applied to your domain, all thanks to
SPF.  You need to strongly advise against the use of v=spf1.  It must
go!  Don't publish v=spf1 records, and if you have published them, they
need to be removed, or at least replaced with a different version that
includes scope.  When used for white-listing, the scope "ADMIN" could be
used. : )

> > It is not clear how the domain owner will recover reliable use of
> > their email domain after publishing SPF and then being exploited.
> 

What do you mean the domain owner's reputation can still be exploited?
What type of reputation system would base abuse assessments upon totally
unconfirmed identifiers?  Hopefully, the only confirmed identifiers,
such as the MTA IP address, would then be used.  It would be incredible
to have a domain assessed for not publishing an SPF record.  I would
even commend them!  Ask that their MTA properly confirm their HELO, that
they use S/MIME, DomainKeys, or any other strong method that identifies
the source of the message.  SPF's weak and broken authorization scheme
will wreck havoc on email's delivery integrity.

> unfounded or apply to PRA, not SPF.

Both SPF and Sender-ID ignore the identity of the server administrator.
Both SPF and Sender-ID premise all assessment upon the domain-owner,
where the server administrator _never_ enters into consideration.

> > Nevertheless, abating abuse requires holding administrators
> > accountable and ensuring they stay on top of security, access,
> > and operational issues.  
> 

I am suggesting the MTA administrator is the _only_ one that can respond
when there is a security problem, or inappropriate access is being
granted.  The MTA administrator should monitor all outbound logs and
watch for excessive errors, or unusual levels of outbound email.  They
also need to investigate abuse reports of their outbound email.  None of
these duties can be expected of the domain owner.  The domain owner has
scant few tools to even know when there is a problem, and even fewer for
correcting the situation.  The MTA administrator has many tools and can
respond. 

> > A reputation scheme MUST identify the source of abuse, and not the
> > "assumed" source of abuse.  
> 

SPF will not prevent forgery in most cases.  In those cases where
forgery still occurs, disaster!  SPF will change forgery from a nuisance
(remedied with bounce address tag validation), into a total meltdown of
the domain.  You really need to avoid making specious claims about what
SPF may accomplish, without also considering what it may not accomplish.

> > A reputation scheme must hold those responsible, accountable.  SPF
> > fails badly on both of these issues.  
> 

Do you really consider SPF is a means to authenticate the sender?  What
assumptions are involved when arriving at that conclusion?  This is why
SPF is so dangerous.

> preventing forgeries from affecting the reputation database.

Publishing SPF does not prevent forgeries.  Many other protections must
be instantiated, where any missing element in this phalanx of required
protections permits forgery.  SPF may even invite forgery.  (Even
assuming it was practical to impose strict authorization to maintain
this claim.)  In the typical case, the domain owner will likely be
blithely unaware of the essential elements needed to guard their
reputation.  You have already declared that you will permit PRA forgery,
as in your view, this is not your concern.

SPF only offers server authorization.  It would be foolish to call this
a forgery prevention scheme, as likely anyone with access to the same
server may be able to forge messages from a domain that authorizes the
server with SPF.  These SPF records are public, so the abuser will not
be guessing who they can impersonate. : (

> > It is folly to think SPF will improve the integrity of email or
> > diminish the rate of abuse.  A reputation scheme based upon SPF
> > authorization is certain to dramatically reduce email's integrity
> > for the majority of domain owners.
> 

Yes, I heard that speech several times.  I would strongly advise you to
consider strong identifiers that can be defended.  A domain owner would
be incredibly foolish to place their domain's reputation into the hands
of an email provider that scoffs at monitoring their server as being too
expensive.  While SPF may permit providers a "What, me worry?" attitude,
it will be the consumer that will pay dearly. 

> A certificate perhaps?  At least now I know your motivation for 

Boy are you barking up the wrong tree.  Turn around, I think someone
wants to see your license. : )

> > They could utilize the services of an email provider to relay email
> > from a dynamic location, without fear other abusive messages may be
> > confused as being from them.  
> 

You do not need to buy certificates for either DomainKeys or Identified
Internet Mail.  I have no financial incentive for recommending either of
these proposals being consider ahead of SPF, other than a desire to see
email remain a viable means to openly exchange information.  SPF does
not offer a fig leaf of protection.

You assume the email provider, who ensures access to the server, also
limits what is sent through the server.  In the age of Zombied computers
everywhere, expect anyone with access will try anything.  Your only
protection with SPF depends upon a poorly defined set of assurances that
must be made by a dubiously diligent provider.  They may believe as you
do, that SPF is its own protection.  After all, it would not be their
reputation damaged would it?

> > If their relay provider was lax at security or preventing abuse, the
> > domain owner can seek a different provider to rectify any resulting
> > problems.
> 

Somehow considering the alternative does seem on topic.

> based reputation lists (or would be irresponsible if they did).

You have made the point as to why there are advantages avoiding the
publishing of SPF.

> > This of course assumes closed-ended list, where the domain owner
> > maintains exclusive access to their servers.  
> 

It remains impossible to list servers of those recipients that forward
their email, for example.  While I have seen it argued this problem is
now the fault of the recipient, it still results in the loss of
messages.  The remedy is to offer a lowered level of server
authorization, at the expense of being forged at this level. 

> > Closed-ended lists are not practical, nor do most domain owners
> > manage their own MTAs with exclusive access. 
> 

But that mess will not impact your domain's reputation, unless you are
silly enough to offer SPF server authorization construed to be "sender
authentication."

> domain to see if I foolishly white-listed by own domain name).

It is futile to go after today's behavior without considering how that
behavior may change.  Is it any wonder those promoting SPF don't want to
talk directly about these concerns, and instead treat their audience
like a bunch of patsies ready to believe anything?  "Don't listen to
anyone raising concerns about SPF/Sender-ID, they're just trying to
spread FUD!"  I have heard this speech several times already.  I wonder
if I should take this as a personal attack. ; )

> could be failures if a protocol doesn't have 100% deployment?

The signature can be ignored by the recipient without harm.  It only
requires the sender to implement a signature scheme.  They then do not
need any protective cooperation by every down stream server, as does
SPF/Sender-ID.

> No matter what they did, the police could not stop my neighbor from 
> neighbors car.  Does this mean that to solve the problem the police 

How can you say Microsoft is wrong, and an SPF cabal is right?  Again,
both drafts even share the same author.  Why blame anyone for there not
being any definition on the scope of the SPF record.  Depreciate v=spf1,
advise its removal, and get on with life.

> anonymous, but that's one of the big whines I hear against correcting 

Yes, there is a free version:
http://domainkeys.sourceforge.net/

> > customers as well.  Either of these scenarios would be fair.

Yes, free! 

> Uh, NO.  SPF records should not be used to evaluate the PRA.

Tell that to Microsoft.  Let me know how that goes. : )

> > The sender does not know what the recipient uses to base their
> > reputation assessments.  Someone can get seriously hurt heedlessly
> > publishing SPF.
> 

What makes any SPF cabal the protocol authority?  The SPF record did not
have a defined scope, where a scope was added when it became apparent
Sender-ID would attempt to use the same silly path registration scheme.
Microsoft claims their algorithm breaks less often and see their claim
equally valid, their view of scope should prevail.

> if only some things are done then only some things work.  Fascinating.

Sender-ID and SPF depend upon universal checks at each public MTA.
Signatures schemes only requires a sender implementation. 

> > SPF requires assumed checks that may or may not be performed.  In
> > fact, some of these checks may require a license. : (
> 
> Huh?

Yes, the PRA you wish would go away.  Its back...

> Ditto for any forgery method that can be circumvented.  Including 

While forging a message with SPF only requires access to any authorized
server (not even to the SMTP application), and the forgeries can
commence.  That can not be said of DomainKeys.

> score a FAIL is assigned.

You mean no one will ever receive a bad reputation based upon SPF server
authorization?  The concern was what happens when they do.

> SPF is *not* PRA.  Please stop the FUD.

This problem is valid in both cases, and yes worse with PRA.  Please
stop attempting to disavow Sender-IDs use of the v=spf1 record.   I
suggest if anyone needs to be consulted, you should query the author of
both drafts.

> HELO/EHLO name checking of SPF.

You don't really expect anyone to care about the HELO do you?  As far as
SPF is concerned, it is there when the message is a DSN.  CSV offers
much lower overhead for this check anyway.  I suspect it will come into
consideration once signatures are prevalent, and then the need will be
more readily perceived.

> And it doesn't hold any credence if one (like I) don't believe in 

Thought so, but then you don't care about who is administering the
server.

> (even those that don't WANT to participate), how is that not collateral 

These are myths at this point.  The overhead required affects the CPU on
the mail server that has adequate margins to permit signatures without
upgrading equipment.  Signatures offer less overhead.  They even
represent less impact that SPF/Sender-ID. 

> revolution are all about.

In some areas perhaps.  I am 100% behind the open source effort.  But be
serious, Microsoft controls too many desktops at this time to be
ignored.  You do so, only at your peril.

> DomainKeys deployment to catch up?

I am pointing out what I see is still VERY wrong the SPF draft.  I am
placing my comments here because I think SPF, when used in the manner
advocated, place the email community at risk.  I would rather provide a
REAL means for people to publish a record that says I DO NOT ASSURE THE
PRA IDENTITY, without that becoming a liability.  The way it is
currently defined, SPF is little more than a trap.  

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 27 May 2005 18:22:41 -0400

> these widely promoted, but contemptibly false assumptions.

  Let's correct the false assumptions then, rather than throwing out
the proposal.  Many people believe putting their computer on the net
is OK.  When they get viruses, the answer isn't to ban the net, it's
to fix their beliefs.

> being assessed in this manner.

  Not giving people tools is the best way to ensure they won't hurt
themselves.

  I find it curious that there's opposition to a "harmful" proposal
like SPF, but the "harmful" practice of sending unauthenticated email
from anywhere on the net is called "roaming", and is deemed to be a
requirement of SMTP.

  Weird.

  All I know is that SPF has harmed me a lot less than "roaming" has.
The endless dribbles of email from clueless people to "postmaster" or
"webmaster" claiming that my domain has spammed them is tiring.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 May 2005 17:10:22 -0700

> is OK.  When they get viruses, the answer isn't to ban the net, it's

One major assumption needing corrected is the assumed scope implied by
an v=spf1 record.  There are vendors able to exercise significant
influence with respect to their view of the scope implied by this
record.  You have another group that feels they can declare a default
scope, in a manner they consider appropriate, albeit in conflict.  Those
holding the Presumed is better than Purported need to recognize they
will not prevail.

A reasonable means to extricate the draft from this situation would be
to depreciate the use of v=spf1, advise its removals, and then document
a new spf2 scope.  Even define a scope like "ADMIN", that indicates
there are _no_ assurances being made within mail stream regarding any
identifier.  It would simply be used to indicate addresses being
administered by a particular domain.  One could say "To ensure this
administrative domain does not accidentally get blocked, apply this to
your white-list." 

> from anywhere on the net is called "roaming", and is deemed to be a

I would not hand a child a circular saw, and then say don't worry about
pulling this trigger.  SPF is handing a dangerous tool to the domain
owner without advising them of the serious risks they assume when
publishing.  I find that outrageous.

I am not against authenticating the source of email.  The use of SPF
does not authenticate the sender, it only provides "server
authorization" which is being construed as being "sender
authentication."  There are valid alternatives that I would happily
endorse, such as DomainKeys, or even CSV.  A mailbox-domain assertion
depends on too many assumptions to ever be safe as an identifier serving
as a basis for reputation.

>   Weird.

As difficult as dealing with IP addresses are, they represent a stronger
identifier when logged against repeated events of abuse.  They also more
directly impact the administrator.  If there is an open-proxy or address
spoofing situation, perhaps assisted by way of a tunnel, they need to
squelch that problem.  I too would like to see authentication move into
the name space.  As I said, DomainKeys or CSV provides both safe and
fair names that can be authenticated.  These identifiers can be
defended, and do not put the average consumer at risk of seeing their
domain's utility being destroyed by a negligent provider.  Yes,
providers will be required to remain vigilant, unlike that suggested by
some SPF proponents.

> "webmaster" claiming that my domain has spammed them is tiring.

I offered suggestions that a domain assertion could be added to the CSV
record that indicates all of a domain's emails are signed.  This would
be a lightweight, single lookup extension that could allow any domain a
means to identify any message that purports to be from your domain, but
then must validate their signature.  There are other issues related to
signatures where this would be a useful tool.  

I describe this at:
http://www.kelkea.com/ietf/draft-otis-mass-reputation-01.html

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 27 May 2005 20:29:42 -0400

Douglas Otis <[email-masked]> wrote:
> scope, in a manner they consider appropriate, albeit in conflict.

  This is a political issue, and not a flaw in the technical proposal.

> SPF is handing a dangerous tool to the domain owner without advising
> them of the serious risks they assume when publishing.  I find that
> outrageous.

  As you've said.  The proponents have disagreed, and "never the twain
shall meet."

> record that indicates all of a domain's emails are signed.

  Which is a great idea.

  Alan DeKok.

---

From: Terry Fielder <[email-masked]>
Date: Fri, 27 May 2005 22:07:33 -0400

> mistakenly viewed by some as "sender authentication" of the domain.

Agreed, educate the masses.  But good luck, because there are a lot of 
computer users without the faintest clue of how things work.  Hence why 
phishing is so effective.

> message.  

I doubt most users have a clue what SPF means.  Or domainkeys.  Or PRA.

> Publishing any SPF record unfortunately exposes your domain to

Yes, along with the false assumption that domainkeys is the FUSSP.

> being assessed in this manner.  

What confirmation???  The users don't see a little lock symbol which 
they can misinterpret to see as secure.  They simply don't see messages 
that were rejected at the MTA.

> Rather than being incensed and reckless

SPF does not present the problem, abusers do.  But abusers find 
loopholes in all methods.  If they didn't, then we would already have 
the FUSSP.

> to wage a defense against the forgery of their domain.  

Um, they waged the defense by publishing SPF knowing that means MTA's 
that check SPF will reject the forgery of their domain.  That *is* 
waging the defense.

> SPF places this
> acts of negligence.  

"Act of negligence":  Clearly you see SPF as a threat to your product. 
Go promote DomainKeys by showing what it has to offer, rather then 
trying to raise false and unsubstantiated claims against the competition.

> They may even claim proprietary checks are outside

SPF is not proprietary.  SPF is not PRA.  PRA is proprietary.  And where 
does domainkeys lie?  Free?  Open source?

> There are some providers that wish to force use of SPF, and there lies

When they do, its relevant for all I have seen, because said providers 
are the domain DNS hoster and MSP for the domain, so they know where the 
emails will come from.  And if someone wants their SPF record to be 
enhanced to include other MSP or IP's etc, I am sure they can.

If the domain providers pushing SPF were so bad, and were doing their 
customers so bad, they wouldn't have any customers left:  This is a free 
society and the masses will take their money and business where they 
want to.

> rather foolish to ignore this.  

I do not ignore it.  I am very prepared to advise everyone to disable 
the PRA when the latest version of exchange/whatever comes out.  (Course 
I also advise everyone to get rid of M$ Exchange)

> As an expert, you would be negligent

Don't need to, PRA should not be scooping SPFv1 records, they are proven 
incompatible.  PRA should use their own SPF2.0 records.  Don't blame SPF 
because PRA is doing something bad, blame PRA.  And domain owners have a 
defense against the PRA, publish the counter PRA record:
"spf2.0/pra ?all"
so PRA does not misinterpret the SPF as a PRA data.

> conflict is not taken far more seriously?  

I don't pretend to understand or care to understand who was underhanded 
or bought or ulteriorly motivated that ended MARID up where it got.  It 
doesn't matter.

> Offering advice to ignore

I advise everyone of the need to ensure PRA is disabled, and if there 
are concerns that others they communicate with do not disable PRA then 
they should publish the SPF2.0 record:
spf2.0/pra ?all

> when the PRA algorithm is a plug-in for Outlook?  

Umm, MTA checking algorithm's should *never* be applied at the MUA, 
because its too late to do an MTA reject.

Don't blame SPF because PRA is bad.

You keep successfully arguing against PRA, thanks for being on the SPF 
side.  Too bad you cannot find any legitmate arguments against SPF.

> Now you have both
> SPF.  

No, the wonderfully weak algorithm is because PRA is abusing SPFv1 
records.  Move on.

> You need to strongly advise against the use of v=spf1.  It must

No, publish SPF.

And if someone actually is stupid enough to deploy/enable PRA, then 
publish the anti-pra record:
spf2.0/pra ?all

> What do you mean the domain owner's reputation can still be exploited?

There are some listings that use current domain name accreditation, even 
though there is nothing to stop the domain from being forged.

> unconfirmed identifiers?  

None, I sure hope.  But they do exist, even if it is admins fighting the 
spam battle with local machine rules instead of subscribing to public 
lists.  And you have missed the point, SPF can make the lists better, it 
cannot make them worse.  So worse case is it doesn't make their accuracy 
better then they already are.

> Hopefully, the only confirmed identifiers,
> such as the MTA IP address, would then be used.  

You seem to have missed the point of IP based reputation lists are not 
sufficient, case and point: the IP repuation lists currently reduce 
spam, but not even to a bearable amount.

> It would be incredible

You are entitled to your (unsubstantiated) opinion.

> Both SPF and Sender-ID ignore the identity of the server administrator.

Nope, SPFv1 looks at the HELO, Sender-ID does not.  Don't confuse SPF 
with SenderID/PRA.  (I need a macro here so I can easily repeat that to you)

> where the server administrator _never_ enters into consideration.

Wrong again, the server admin has to do at least *something* to have SPF 
running on the server.  And sometimes, as you argued above, its even the 
server administrator that takes things into their own hands and 
publishes on the domain owners behalf, knowing where the MX's are for 
the domain and its ISP/ESP/hoster.

> granted.  

And if the resources were there for MTA administrators, we wouldn't have 
a spam problem.  But they don't, and so there exists a spam problem.

> The MTA administrator should monitor all outbound logs and
> watch for excessive errors, or unusual levels of outbound email.  

Perfect:  Oops, a while ago a flood of spam went through our server, 
sorry I did not notice it before a few million got through.

> They
> also need to investigate abuse reports of their outbound email.  

Obviously stated by someone who doesn't spend much time handling user 
email complaints.

> None of
> these duties can be expected of the domain owner.  

For the small time vanity domain where the owner has no idea, doesn't 
matter, recall your statement above about the ISP/MSP/hoster publishing 
the SPF on behalf of the domain.  Problem solved, even if the domain 
owner cannot follow the instructions of the various tools to generate 
SPF records.

> The domain owner has

And does, with SPF, something that is tried, works except on forwarding 
cases that should never exist anyway, and has measureable deployment.

> SPF will not prevent forgery in most cases.  

Wrong (the current SPF deployment testing shows it), please resist 
making unsubstantiated claims.

> In those cases where
> forgery still occurs, disaster!

In *what* cases can forgery still occur if SPF is properly implemented?

>  SPF will change forgery from a nuisance

You need to avoid making specious claims of problems that are not 
actually caused by SPF but by PRA.

> Do you really consider SPF is a means to authenticate the sender?  

No, neither should you claim that SPF makes the claim.  SPF says that 
the MTA is authorized to send emails from said domain, so the email 
*could* be legit.
SPF does not guarantee emails are good.  It just guarantees they are not 
forged.

> What

No assumptions, using the same methodolgy that is applied to IP 
reputation lists, can be provided for domain name reputation lists. 
Only spammers have lots of IP's for their spamming activity, but fewer 
domains with good reputation (and the reputation would turn bad after a 
bit of abuse)

> Publishing SPF does not prevent forgeries.  

Yes it does.  If you cannot trust that the MTA that you allow to send 
your email cannot be trusted to not send forgeries from your domain, 
then you have bigger problems with your ISP that not even signature 
methodolgies can resolve.

> Many other protections must
> protections permits forgery.  SPF may even invite forgery.

Oh I cannot wait to hear why, please enlighten me with your wisdom.

> (Even

Never said that.  In fact I said I would fight the PRA, its worse then 
useless.

> a forgery prevention scheme, as likely anyone with access to the same

*likely*  (If you cannot trust your MSP, you need to get a better one).

> be guessing who they can impersonate. : (

Your silly, without SPF you can still *easily* find out where the vast 
of majority of domain names call home, by examining MX and other types 
of SPf records.

> it will be the consumer that will pay dearly. 

I will certainly consider other methods of authentication, in fact I 
would love to.  I look forward to one being available, and deployable, 
and free (as in beer).

> wants to see your license. : )

Could be, and they can see my license, because I publish SPF.  :)

> reputation damaged would it?

SPF is not the FUSSP.  Never said it was.  It just helps to build a 
better framework so other mechanisms can work better.  The fact that in 
the short term it will quash spammers and viruses who have not adapted 
is cool, but irrelevant.

> You have made the point as to why there are advantages avoiding the

I don't see how.

> their email, for example.  

Please peruse the archives for SRS and SES.

> While I have seen it argued this problem is
> messages.  

If bad "anonymous" forwarding is still allowed.  I don't think it 
should.  My servers don't do it, we re-inject so the end rejections come 
back to the intermediate account.

> The remedy is to offer a lowered level of server

That's a good point.  But not even keys saves you if you cannot trust 
the MTA that is authorized to send your email.  *sigh*

> silly enough to offer SPF server authorization construed to be "sender

Wrong again, I have already encountered small time mail admin who 
blacklisted my domain name based on an infected computer that had few 
addresses in the contact list, but one of my sales offices was.  Just a 
local blacklist, not any big damage, but sufficient headache nonetheless.

> if I should take this as a personal attack. ; )

You can do what you like, its intended as a personal attack.  But please 
stop talking down SPF because PRA has serious flaws, because that is an 
unfair attack against SPF.

> both drafts even share the same author.  

Irrelevant, the different drafts are *different* because just that: They 
say completely different things.

> Why blame anyone for there not

You have peaked my interest, I will look at it, domain keys had sounded 
so much like a money grab before.

>>>customers as well.  Either of these scenarios would be fair.

As above, I am going to look at it.

> Tell that to Microsoft.  Let me know how that goes. : )

MS has made many bad mistakes.  They still live with many of them. 
People still cope by disabling bad ideas like IIS web printing and crap 
like that.

> equally valid, their view of scope should prevail.

Unsubstantiated claims are irrelevant, which is why Marid ended to allow 
for testing mode.

> Signatures schemes only requires a sender implementation. 

But is useless without a receiver implementation.  Sound familiar?

> Yes, the PRA you wish would go away.  Its back...

But not to stay, not with a license anyway, because many (like myself) 
will not sign.

> commence.  That can not be said of DomainKeys.

If you cannot trust your MTA, you cannot trust it, not for anything.

> authorization?  The concern was what happens when they do.

If the reputation lists find that SPF PASS is not sufficient to say its 
from the domain, that does not preclude SPF still being useful to reject 
the emails that definitely are *not* from the domain (and even better is 
the fact that it is done at SMTP time).

> You don't really expect anyone to care about the HELO do you?  

I hope that someday the poorly configured MTA's will be forced to use a 
valid HELO.

> As far as
> much lower overhead for this check anyway.  

Compared to the SPF worst case, yes.  Compared to the average case, my 
understanding is not.

> I suspect it will come into

When signatures actually go into production hopefully all this will be 
irrelevant.  But I doubt it. And we have SPF here, and now.

> Thought so, but then you don't care about who is administering the
I don't follow your reasoning.

> represent less impact that SPF/Sender-ID. 

NO, DNS load can be outsourced to a DNS server, and mitigated by a DNS 
cache.

> ignored.  You do so, only at your peril.

If you think spam is solved at the desktop.  It is not.  I don't see how 
it ever can (or should) because you are still wasting resources allowing 
the spam to get to the desktop when one could quash it at the MTA.

Have you noticed how many peolple have stopped using IE and have started 
using firefox?  Revolution...

> currently defined, SPF is little more than a trap.  

Not when you can negate the PRA concern with: spf2.0/pra ?all

---

From: Douglas Otis <[email-masked]>
Date: Sun, 29 May 2005 13:57:54 -0700

> phishing is so effective.

It does not need to be a pad-lock icon to create an impression the
sender has been assured.  Calling "server authorization" "sender
authentication" does little to educate users.  If anything, this
misrepresentation increases the number of victims, and allows phishers a
new means to gain the confidence of their victim.  A "happy face" is
equally misleading, when this is understood to be that the sender has
been authenticated.  The mailbox-domain can not be authenticated without
a signature.

> Yes, along with the false assumption that domainkeys is the FUSSP.

Sender-ID/SPF is being touted as a means to accrue reputations based
upon the SPF record.  This is not an innocuous tool.  These weak server
authorizations are easily exploited by an abuser.  Abuse prevention
depends upon the provider's access control and added impositions of
mailbox-domain restrictions.  By the domain owner publishing the SPF
authorization, they enable accrual of a likely unfair reputation.

Instead of alerting domain owners as to what is needed for the
protection of their domain's reputation, promoters are advising domain
owners to consider any concerns over publishing of SPF records to be
irrelevant FUD.  This is usually accompanied with rhetoric that
describes some corner case, and its dismissal.  In addition to message
loss,  I have yet to hear that publishing may cause your domain's
reputation to be irreparably damaged, should the provider fail to
enforce the new needed restrictions.  This failure could happen with the
provider enables an open-proxy or open-relay.  It may also occur when
the provider permits access to their server's other applications that
could be subverted into sending mail. 

No email abuse will be abated without being used in conjunction with a
reputation system.  There are not the same exposures created by
DomainKeys, as with SPF.  DomainKeys provides for authentication,
whereas Sender-ID does not.

> that check SPF will reject the forgery of their domain.  That *is* 

Under particular, impractical circumstances, SPF may allow some emails
to be refused on the basis that the server is not authorized.  SPF will
not prevent the domain being forged, when access is granted to a shared
server.  When the authorization is open-ended, SPF will not prevent
forgery.  Again, anti-forgery claims are specious.

> trying to raise false and unsubstantiated claims against the competition.

Rather than side-stepping this issue, be specific about the claims.

> SPF is not proprietary.  SPF is not PRA.  PRA is proprietary. 

SPF records _will_ be used for the PRA algorithm, that may result in
domain's reputation being damaged when ignored and not assured by the
provider.

> > There are some providers that wish to force use of SPF, and there lies
...
> society and the masses will take their money and business where they 

With a high percentage using a common desktop OS, the influence this
creates requires greater consideration.  I do not believe the a
community will be able to prevent interpretation of a record's scope
from being applied to the PRA, without making the scope for the record
explicitly expressed.  After all, their draft shares the same author,
and there was a very short period of time when this was considered
permissible within MARID group.  

> I also advise everyone to get rid of M$ Exchange)

Again, don't expect to prevail.

> > As an expert, you would be negligent advising anyone to publish an
> > v=spf1 record, and not insist they also  require PRA conflict
> > protections.  The first question a wary domain owner would need to
> > ask, "Do you enforce the PRA for all of your customers?"  
> 

At the same time, domain owners are warned that ?all will eventually
become a basis for refusal.  This "neutral" authorization, although
weak, may still be viewed as confirmation sufficient for expressing some
level of "authentication."  There have also been warnings regarding the
potential damage weak authorizations may create.  Forcing the publishing
of a PRA record is a strange method to indicate that you refuse to allow
the PRA to be evaluated.  I would say this suggests just the opposite.  

> > Offering advice to ignore Sender-ID would be outright laughable, if
> > it were not so serious.  How will you indemnify your customers from
> > such negligence?
>  
> 

Your customers have NO control over what some recipient may do.  This
record does not assure their reputation remains protected.  In fact,
there have been statements made to the opposite. There have also been
warnings that in the future this record will be refused.  

> side.  Too bad you cannot find any legitmate arguments against SPF.

Both SPF and Sender-ID proponents proposed the use of reputations based
upon server authorization.  This raises a legitimate concern.  Both SPF
and Sender-ID fail to hold the server administrator accountable for the
operation of the server, and instead unfairly place the feckless domain
owner's reputation at risk.  Both SPF and Sender-ID depend upon added
restrictions imposed by the email provider, but should the providers
fail to perform these new added duties, in addition to their normal
duties, the domain owner's reputation is unfairly put at risk.

Both SPF and Sender-ID wreck havoc with email's architectural paradigms
that will cause the loss of valid emails, and lower the integrity of
email delivery.  The proponents of Sender-ID claim less loss of
messages.  The unfair reputation system created by either SPF or
Sender-ID will lower the integrity of email delivery as well.

> > Now you have both wonderfully weak algorithms being applied to your
> > domain, all thanks to SPF.  
> 

You can not prevail on an assumed record scope.  Both Sender-ID and SPF
attempt to transform "server authorization" into "sender
authentication."  If I were to authorize an email provider, would that
mean any message using my email domain from that provider be from me?

> publish the anti-pra record:

One would need to be rather gullible to consider this record is
providing any protection, especially for the long term.  I would
describe this as a trap.  With the very few warning made, don't you find
these to foretell intended strategies?

> though there is nothing to stop the domain from being forged.

Accreditations often depend upon the IP address in the same manner as an
SPF record.  This type of service is often used by bulk emails.  These
providers likely enjoy exclusive access to the "authorized" servers.
However, exclusive access should not be a requirement for a typical
domain owner.  It is often not the case.  Even so, not publishing SPF
still affords this domain owner greater protection.

> better then they already are.

I do not agree.  SPF hopes to make this practice endemic.  Filtering is
attempting to treat a disease, while also lowering email's integrity.
Only with strong and definitive results, can email's integrity be
retained.  Signatures are strong and do not alter email's architectural
paradigms.  SPF is weak, and breaks email.

> spam, but not even to a bearable amount.

The degree to which IP address lists are ineffective is dependent upon
the diligence afford by large providers to administer their services.
SPF will only likely cause these providers to be less diligent and
assume there can be reliance upon SPF server authorization.  This will
result in there being a total mess, and a disaster for many otherwise
responsible domain owners who will loss their ability to utilize their
domains.

> the domain and its ISP/ESP/hoster.

The domain owner must publish the SPF record.  The domain owner is not
the email provider running the authorized servers.

> a spam problem.  But they don't, and so there exists a spam problem.

Funny, SPF expects these same providers to do even more, but I suspect
they will do even less.

> sorry I did not notice it before a few million got through.

Your reputation should suffer, and not your customer's.

> > They also need to investigate abuse reports of their outbound email.  
> 

I did say should.  : )

Even so, the lax provider will not harm their reputation under the SPF
reputation strategy, it will be their customers.  How self serving.

> > None of these duties can be expected of the domain owner.  
> 

I can see you don't care the least what happens when reputation is applied.

> cases that should never exist anyway, and has measureable deployment.

Blame decades of use of a valuable feature?

> In *what* cases can forgery still occur if SPF is properly implemented?

Exactly!

> actually caused by SPF but by PRA.

It will plague both.

> SPF does not guarantee emails are good.  It just guarantees they are not 

Wrong again.

> domains with good reputation (and the reputation would turn bad after a 

The use of a name offers greater freedom for imposing reputation.  There
are potentially more names than addresses.

> methodolgies can resolve.

How can a domain owner know how well their ISP defends their domain's
reputation.  What recourse do they have when they don't?

> Oh I cannot wait to hear why, please enlighten me with your wisdom.

Access.

> Never said that.  In fact I said I would fight the PRA, its worse then 

By ignoring the PRA, you and your customer becomes its victim.

> *likely*  (If you cannot trust your MSP, you need to get a better one).

That will not remove the damage.

> of majority of domain names call home, by examining MX and other types 

Usurping SPF based reputations requires SPF records.

> would love to.  I look forward to one being available, and deployable, 

What problem do you see with DomainKeys for example?

> the short term it will quash spammers and viruses who have not adapted 

SPF does NOT build a better framework.  Just the opposite.  It leads to
very bad results when authorization is consider to be the same as
authentication.

> back to the intermediate account.

All of this looks like a real mess.

> the MTA that is authorized to send your email.  *sigh*

The domain owner only needs to trust the signing process and not each
and every MTA involved in the delivery of their message.

> say completely different things.

They both use the same record for different mailbox-domains and then
presume the sender on that basis.  Really bad.

> But is useless without a receiver implementation.  Sound familiar?

Signatures only requires that the end-points implement the protocol to
be beneficial.  SPF or Sender-ID requires each and every MTA implement
the protocol, or their reputation can become seriously damaged.

> But not to stay, not with a license anyway, because many (like myself) 

You are setting yourself up for being forced into using the PRA it would
seem.

> If you cannot trust your MTA, you cannot trust it, not for anything.

Not true.  It can still be trusted with a signature based system.  Just
like the WiFi at the coffeeshop can only be trusted with end-to-end
encryption.

> the fact that it is done at SMTP time).

Perhaps this small feature would be useful, but I doubt that will ever
be practical when considering the impact this has on forwarded email.
The danger happens when too many consider this useful as a basis of
sender authentication, and then use it to apply reputations.

> irrelevant.  But I doubt it. And we have SPF here, and now.

Neither signatures, or Sender-ID will protect network resources.  The
requirement of over one hundred lookups by SPF also can not be defended.
CSV however does offer a means to thwart attacks.

> NO, DNS load can be outsourced to a DNS server, and mitigated by a DNS 

There is still the effort needed to obtain the many SPF records for each
and every message.

> Not when you can negate the PRA concern with: spf2.0/pra ?all

This is wishful thinking.

-Doug

---

From: Graham Murray <[email-masked]>
Date: Tue, 31 May 2005 09:49:00 +0000

> mean any message using my email domain from that provider be from me?

I cannot comment on Sender-ID, but as I understand it (as the one who
publishes SPF records for the domain) SPF does not attempt to do this. An SPF
pass does *NOT* indicate that the mail is genuinely from the domain (though in
the cases of the domains I control it probably does as I also control the mail
servers), but an SPF fail indicates that the mail is definitely NOT genuinely
from the domain. So an SPF pass should not be counted as sender
authentication, even domain keys does not do this (it only authenticates the
domain and that the mail has not been 'tampered with')- if you want to
authenticate the sender you will have to use an MUA cryptographic system like
S/MIME or PGP/MIME etc.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 May 2005 12:07:14 -0700

> authenticate the sender you will have to use an MUA cryptographic system like

Not granting an RFC for Sender-ID will not prevent the promised use of
the PRA algorithm with version 1 SPF records.  While you may not desire
such PRA treatment of your email, publishing _any_ SPF record, as
currently defined, enables use of the PRA algorithm.  The way this use
can be prevented would be to depreciate version 1 SPF records, and to
define scopes with version 2 SPF records that clearly indicate which
identities are 'assured' within messages.  Also add a scope of 'ADMIN'
where no identifiers are assured, to allow the SPF records be used for
purely white-listing purposes.

Being practical, remove the HELO scope from the SPF records.  CSV can
assure a single lookup for this purpose, and CSV offers a mechanism to
declare domain-wide email policies, to increase email requirements of
such things as CSV itself, or email signing, etc.  In this way, CSV
offers DoS protections for any subsequent email extension.

Many have commented that a "benefit" of SPF is it forces abusers to use
their 'real' domain name, so they can be identified and stopped.  This
comment illustrates an expectation that SPF provides "sender
authentication" where an abuser can not forge the mailbox-domain.  While
possible, with add restrictions imposed by the email provider, the
domain owner remains completely at the mercy of an email provider's
diligence at _every_ MTA involved in the transport of the message, and
not just those MTAs that have been directly authorized by the SPF
record.  A mistake on the part of an email provider, such as
misconfiguration of a firewall, and the domain owner's reputation
suffers.

A domain owner will have few resources to know the cause of their
reputation woes, and will need to wait for the TTL of their SPF records
to expire, before ill-advised publishing can be retracted, assuming they
even know which servers are at fault.

SPF offers many shades of gray, such as Pass, Neutral, SoftFail, or
TempError.  An abuser could have their forged messages accepted at any
of these levels.  Reputation and "assumed sender authentication" will
combine to sort out these results.  It is very likely an abuser, finding
they _can_ forge a domain with a published SPF record, will cause the
messages from that domain to become filtered and redirected into junk
folders.  As the reputation factor becomes more significant, there may
then be an outright rejection of the message from the forged domain.

Once the message becomes rejected, meaning the reputation is now badly
tainted, the recovery of the domain for email may be extremely
difficult.  Such a system is sure to cause the integrity of email
delivery to suffer.  Controlling abuse requires the administrator of the
email server to play a critical role.  Essentially, it requires that
they control access to the server.  Use of an IP address or the
DomainKey signature will directly impact the administrator of the
significant (offending) email server.  SPF may not affect such
administrator.  Hence a possible lackadaisical attitude regarding their
obligations. 

To abate abuse, there must be a low tolerance for abuse, and strong
identifications for the source of the abuse.  Once there is any blocking
put in place, it should directly impact the administrator of the email
server causing the problem.  SPF may eventually provide feedback to the
domain owner, but the domain owner may have no ability to meaningfully
respond in a timely manner.  At that point, they may also have no
ability to recover either.

It is not surprising so little is being said about the implied duties
required to protect domain owners when they publish SPF records, or the
potential for the harm that may result.  As far as the email provider is
concerned, the less said the better.  A naive domain owner is willing to
risk their reputation without asking for any indemnification from their
provider.  At this time, there is no SPF record that can be published
without also requiring the PRA be examined and assured.  The many
different mailbox-domains must be limited to those domains allowed for
each authenticated user.  With SPF, providers must vet who is allowed to
use a particular domain, and be sure to enforce each and every identity
that _could_ be used in any SPF related reputation scheme.

The "opt-out" scenario described by Sender-ID is really little more than
a ploy to have domain owners publish PRA specific records.  This record
strategy is already prone to the Machiavellian "user feedback" button.
Ignoring Sender-ID would be at your peril.  At some point, snap.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 May 2005 23:05:24 -0700

On Wed, 2005-06-01 at 00:36 -0400, Hector Santos wrote:

> > While possible, with add restrictions imposed by the email provider,
> > the domain owner remains completely at the mercy of an email
> > provider's diligence at _every_ MTA involved in the transport of the
> > message, and not just those MTAs that have been directly authorized
> > by the SPF record.  A mistake on the part of an email provider, such
> > as misconfiguration of a firewall, and the domain owner's reputation
> > suffers.
> 
> And how is CSV immune from these same set of possible routing scenarios?

The HELO name would be indicative of the domain administrator running
the MTA, irrespective of the mailbox-domains contained in messages sent
by the MTA.  If the MTA is not properly administered, it would be this
MTA and the administrator of this MTA identified by a reputation scheme
that rates HELO names.

Those that would normally send messages over a HELO blocked MTA would be
free to look elsewhere to obtain email services.  If the mailbox-domains
were rated and blocked instead, as with SPF, a poorly maintained MTA
could continue to send abusive and even forged emails, but then the
domain owners would find use of their domains blocked, no matter which
other provider they tried.  Not fair for the domain owner, nor effective
at preventing abuse. : (

> Are you saying that once CSV authorizes a submission at the MSA, then there
> is no need to further perform CSV during the route and only at the MDA?

CSV would be checked once for every HELO presented.  The basis of any
reputation should be with respect to the administrator.  Only the
administrator is in a position to take immediate and knowledgeable
corrective action.  Normally an administrator's reputation evaluation
would only need to be done once for any number of messages.  Unlike SPF,
which may entail many many lookups, CSV requires just one for its basic
use, and done just once per MTA for a substantial reduction in overhead.
This low overhead makes CSV suitable for protecting network resources.

> What if you have this topology?
> 
>         MUA ---> MSA1/MTA1 -----> MTA2 ---->  MDA3
>
> MSA1 and MDA3 is CVS ready.  MTA2 is not.
> 
> How does MDA3 handle this using CSV?  What is the policy here?

CSV offers a means to protect network resources on a name basis.  CSV
would permit name reputation accrual for the MTA, rather than just for
its address as done today.  Thus updating addresses would not impact the
MTA administrator to the same extent as it does today.  As CSV uses the
SRV record, there would be no address maintenance involved in an address
change either.  (Beyond the normal A record reassignment of the
interface of course.)  

By elevating the network reputation protection service to the name
space, rather than just address space, CSV offers a means to extend DoS
protections for other uses, such as email signatures as described in:
http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt

CSV also provides a means to establish domain-wide assertions without
the use of wildcards as well.  Of course this would be greatly
facilitated by a convention that expects the HELO to resolve to a CSV
record.

If MDA2 claimed to be from a domain that had a domain-wide policy that
required a CSV record (per the SRV Port assertions), then a lack of such
a record would become a basis for MTA3 to refuse messages from MTA2.

There could also be a simple fallback that depends upon an address space
reputation service, instead of name space.  Regardless of the use of
addresses or HELOs, there is no expectations that new conventions are
adhered to by each MTA.  The HELO name would be authenticated directly,
and would be acting under the auspices of the MTA administrator.

On top of this network HELO name reputation protection scheme, a
signature domain name reputation protection scheme could be constructed.
In either case, HELO or signature domain, the name reputation would
reflect the diligence of the administrator guarding access at each MTA.
Of course, in the case of the signature, this provides valuable end-user
protections, and not network resource protections.

Signature schemes would also assist MTA administrators identify
problematic accounts without unfair assumptions.  CSV and Signatures are
fair and safe alternative to path registration.

-Doug