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

On Fri, 2005-05-27 at 08:44 -0400, Terry Fielder wrote:
> Douglas Otis wrote:
> > On Thu, 2005-05-26 at 23:18 +0200, Julian Mehnle wrote: 
> >
> > 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. 
> 
> 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

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 
> their domain

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.


> #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).

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?


> > 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.  
> 
> *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).

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.
> 
> 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.

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.


> > This is a very real concern being completely ignored by providers
> > anxious to rid themselves of their responsibilities with respect to this
> > menacing abuse.  
> 
> SPF is not ignoring concerns.  The concerns you have stated are either 
> 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.  
> 
> 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.

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 is not a reputation scheme.
> 
> SPF is a means to make reputation schemes accurate by preventing forgery.

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.  
> 
> No, it doesn't.  A reputation scheme allows domains to obtain 
> credibility (or not) based on what the domain has done in the past.

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.


> SPF simply improves the ability for reputation schemes to be accurate by 
> 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.
> 
> I would love to see your facts, or testing, to justify this statement. 
> Sounds like FUD.

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. 


> > 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.  
> 
> 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.

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.  
> 
> 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).

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.
> 
> 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).

Somehow considering the alternative does seem on topic.


> > You should put yourself into your customer's position.  Proclamations
> > 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).

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.  
> 
> 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)

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. 
> 
> 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 that mess will not impact your domain's reputation, unless you are
silly enough to offer SPF server authorization construed to be "sender
authentication."


> 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 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. ; )


> > A domain owner that protects the private portion of their signature,
> > 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?

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.


> > 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?
> 
> 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 neighbor from 
> drinking and driving.  Even when they impounded his car he then stole a 
> neighbors 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.

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.


> > 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.
> 
> 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).

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


> > The provider could also offer to relay messages already signed by their
> > customers as well.  Either of these scenarios would be fair.
> 
> But not free.

Yes, free! 


> > 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.  
> 
> 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.
> 
> 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).

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.


> > 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.  
> 
> 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.

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...


> > 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.
> 
> Ditto for any forgery method that can be circumvented.  Including 
> domainkeys.

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.


> > 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
> 
> 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.

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


> > , filtering often employs a practice of
> > placing uncertain results into a junk folder.  With SPF, there are many
> > shades of gray. : (
> 
> 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.


> > The assumption that a mailbox-domain can be authenticated without the
> > 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
> > too weak to base a presumption of having authenticated the sender.
> 
> Your argument does not hold even a drop of substance against the 
> 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 
> anonymous forwarding.

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


> > 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.
> 
> 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?

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. 


> > So are you going to tell a 900 pound gorilla they are wrong?  In the
> > 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.

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.


> > 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.
> 
> 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?

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