ietf-mxcomp
[Top] [All Lists]

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

2005-05-27 19:06:44



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
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085