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

Douglas Otis wrote:
> 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.

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.

> Publishing SPF provides these recipients with what they believe to be
> confirmations, albeit flimsy, that your domain has actually sent the
> message.  

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

> Publishing any SPF record unfortunately exposes your domain to
> these widely promoted, but contemptibly false assumptions.

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

> 
> Not offering this damning confirmation is the only sure means to avoid
> 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
> 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.

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.

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

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
> duty onto the faceless email provider, who remains unscathed by their
> 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
> their bailiwick, although it then offers an avenue for the forger to
> impugn your reputation.

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

> 
> 
> 
>>SPF cannot be help responsible for #1
> 
> 
> There are some providers that wish to force use of SPF, and there lies
> the rub.

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.

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

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

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.

> 
> How is it that the same author appears on these two drafts, and yet this
> 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
> Sender-ID would be outright laughable, if it were not so serious.  How
> will you indemnify your customers from such negligence?
> 

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


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

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
> wonderfully weak algorithms being applied to your domain, all thanks to
> 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
> 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. : )

No, publish SPF.

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

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

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

> What type of reputation system would base abuse assessments upon totally
> 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
> 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.

You are entitled to your (unsubstantiated) opinion.

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

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)

> Both SPF and Sender-ID premise all assessment upon the domain-owner,
> 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.

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

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

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

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

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

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

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

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
> assumptions are involved when arriving at that conclusion?  This is why
> SPF is so dangerous.

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)

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

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
> be instantiated, where any missing element in this phalanx of required
> protections permits forgery.  SPF may even invite forgery.

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

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

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

> 
> SPF only offers server authorization.  It would be foolish to call this
> 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).

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

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

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

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

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

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

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.

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

I don't see how.

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

Please peruse the archives for SRS and SES.

> While I have seen it argued this problem is
> now the fault of the recipient, it still results in the loss of
> 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
> authorization, at the expense of being forged at this level. 
> 

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*


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

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.

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

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.

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

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

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

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

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

As above, I am going to look at it.

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

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.

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

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

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

But is useless without a receiver implementation.  Sound familiar?

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

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

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

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

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

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

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

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

> As far as
> SPF is concerned, it is there when the message is a DSN.  CSV offers
> 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
> consideration once signatures are prevalent, and then the need will be
> more readily perceived.
> 

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

> 
> 
>>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.
> 
I don't follow your reasoning.


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

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

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

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

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

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


> 
> -Doug
> 
> 

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