[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Fri, 2005-05-27 at 22:07 -0400, Terry Fielder wrote:
> Douglas Otis wrote:
> > On Fri, 2005-05-27 at 08:44 -0400, Terry Fielder wrote:
> > 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.
It does not need to be a pad-lock icon to create an impression the
sender has been assured. Calling "server authorization" "sender
authentication" does little to educate users. If anything, this
misrepresentation increases the number of victims, and allows phishers a
new means to gain the confidence of their victim. A "happy face" is
equally misleading, when this is understood to be that the sender has
been authenticated. The mailbox-domain can not be authenticated without
> > 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.
Sender-ID/SPF is being touted as a means to accrue reputations based
upon the SPF record. This is not an innocuous tool. These weak server
authorizations are easily exploited by an abuser. Abuse prevention
depends upon the provider's access control and added impositions of
mailbox-domain restrictions. By the domain owner publishing the SPF
authorization, they enable accrual of a likely unfair reputation.
Instead of alerting domain owners as to what is needed for the
protection of their domain's reputation, promoters are advising domain
owners to consider any concerns over publishing of SPF records to be
irrelevant FUD. This is usually accompanied with rhetoric that
describes some corner case, and its dismissal. In addition to message
loss, I have yet to hear that publishing may cause your domain's
reputation to be irreparably damaged, should the provider fail to
enforce the new needed restrictions. This failure could happen with the
provider enables an open-proxy or open-relay. It may also occur when
the provider permits access to their server's other applications that
could be subverted into sending mail.
No email abuse will be abated without being used in conjunction with a
reputation system. There are not the same exposures created by
DomainKeys, as with SPF. DomainKeys provides for authentication,
whereas Sender-ID does not.
> 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.
Under particular, impractical circumstances, SPF may allow some emails
to be refused on the basis that the server is not authorized. SPF will
not prevent the domain being forged, when access is granted to a shared
server. When the authorization is open-ended, SPF will not prevent
forgery. Again, anti-forgery claims are specious.
> Go promote DomainKeys by showing what it has to offer, rather then
> trying to raise false and unsubstantiated claims against the competition.
Rather than side-stepping this issue, be specific about the claims.
> > 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.
SPF records _will_ be used for the PRA algorithm, that may result in
domain's reputation being damaged when ignored and not assured by the
> > There are some providers that wish to force use of SPF, and there lies
> > the rub.
> 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.
With a high percentage using a common desktop OS, the influence this
creates requires greater consideration. I do not believe the a
community will be able to prevent interpretation of a record's scope
from being applied to the PRA, without making the scope for the record
explicitly expressed. After all, their draft shares the same author,
and there was a very short period of time when this was considered
permissible within MARID group.
> > 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)
Again, don't expect to prevail.
> > As an expert, you would be negligent advising anyone to publish an
> > v=spf1 record, and not insist they also require PRA conflict
> > protections. The first question a wary domain owner would need to
> > ask, "Do you enforce the PRA for all of your customers?"
> 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.
At the same time, domain owners are warned that ?all will eventually
become a basis for refusal. This "neutral" authorization, although
weak, may still be viewed as confirmation sufficient for expressing some
level of "authentication." There have also been warnings regarding the
potential damage weak authorizations may create. Forcing the publishing
of a PRA record is a strange method to indicate that you refuse to allow
the PRA to be evaluated. I would say this suggests just the opposite.
> > Offering advice to ignore Sender-ID would be outright laughable, if
> > it were not so serious. How will you indemnify your customers from
> > such negligence?
> 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
Your customers have NO control over what some recipient may do. This
record does not assure their reputation remains protected. In fact,
there have been statements made to the opposite. There have also been
warnings that in the future this record will be refused.
> > 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.
Both SPF and Sender-ID proponents proposed the use of reputations based
upon server authorization. This raises a legitimate concern. Both SPF
and Sender-ID fail to hold the server administrator accountable for the
operation of the server, and instead unfairly place the feckless domain
owner's reputation at risk. Both SPF and Sender-ID depend upon added
restrictions imposed by the email provider, but should the providers
fail to perform these new added duties, in addition to their normal
duties, the domain owner's reputation is unfairly put at risk.
Both SPF and Sender-ID wreck havoc with email's architectural paradigms
that will cause the loss of valid emails, and lower the integrity of
email delivery. The proponents of Sender-ID claim less loss of
messages. The unfair reputation system created by either SPF or
Sender-ID will lower the integrity of email delivery as well.
> > Now you have both wonderfully weak algorithms being applied to your
> > domain, all thanks to SPF.
> No, the wonderfully weak algorithm is because PRA is abusing SPFv1
> records. Move on.
You can not prevail on an assumed record scope. Both Sender-ID and SPF
attempt to transform "server authorization" into "sender
authentication." If I were to authorize an email provider, would that
mean any message using my email domain from that provider be from me?
> > 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
One would need to be rather gullible to consider this record is
providing any protection, especially for the long term. I would
describe this as a trap. With the very few warning made, don't you find
these to foretell intended strategies?
> >> 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.
Accreditations often depend upon the IP address in the same manner as an
SPF record. This type of service is often used by bulk emails. These
providers likely enjoy exclusive access to the "authorized" servers.
However, exclusive access should not be a requirement for a typical
domain owner. It is often not the case. Even so, not publishing SPF
still affords this domain owner greater protection.
> > 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.
I do not agree. SPF hopes to make this practice endemic. Filtering is
attempting to treat a disease, while also lowering email's integrity.
Only with strong and definitive results, can email's integrity be
retained. Signatures are strong and do not alter email's architectural
paradigms. SPF is weak, and breaks email.
> > 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.
The degree to which IP address lists are ineffective is dependent upon
the diligence afford by large providers to administer their services.
SPF will only likely cause these providers to be less diligent and
assume there can be reliance upon SPF server authorization. This will
result in there being a total mess, and a disaster for many otherwise
responsible domain owners who will loss their ability to utilize their
> > 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.
The domain owner must publish the SPF record. The domain owner is not
the email provider running the authorized servers.
> > 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.
Funny, SPF expects these same providers to do even more, but I suspect
they will do even less.
> > 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.
Your reputation should suffer, and not your customer's.
> > 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.
I did say should. : )
Even so, the lax provider will not harm their reputation under the SPF
reputation strategy, it will be their customers. How self serving.
> > None of these duties can be expected of the domain owner.
> 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.
I can see you don't care the least what happens when reputation is applied.
> > 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.
Blame decades of use of a valuable feature?
> > 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.
It will plague both.
> > 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
> > 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)
The use of a name offers greater freedom for imposing reputation. There
are potentially more names than addresses.
> > 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.
How can a domain owner know how well their ISP defends their domain's
reputation. What recourse do they have when they don't?
> > 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
By ignoring the PRA, you and your customer becomes its victim.
> > 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).
That will not remove the damage.
> > 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.
Usurping SPF based reputations requires SPF records.
> >> 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).
What problem do you see with DomainKeys for example?
> > 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.
SPF does NOT build a better framework. Just the opposite. It leads to
very bad results when authorization is consider to be the same as
> > 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.
All of this looks like a real mess.
> > 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*
The domain owner only needs to trust the signing process and not each
and every MTA involved in the delivery of their message.
> > 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.
They both use the same record for different mailbox-domains and then
presume the sender on that basis. Really bad.
> > 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?
Signatures only requires that the end-points implement the protocol to
be beneficial. SPF or Sender-ID requires each and every MTA implement
the protocol, or their reputation can become seriously damaged.
> > 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.
You are setting yourself up for being forced into using the PRA it would
> > 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.
Not true. It can still be trusted with a signature based system. Just
like the WiFi at the coffeeshop can only be trusted with end-to-end
> > 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).
Perhaps this small feature would be useful, but I doubt that will ever
be practical when considering the impact this has on forwarded email.
The danger happens when too many consider this useful as a basis of
sender authentication, and then use it to apply reputations.
> When signatures actually go into production hopefully all this will be
> irrelevant. But I doubt it. And we have SPF here, and now.
Neither signatures, or Sender-ID will protect network resources. The
requirement of over one hundred lookups by SPF also can not be defended.
CSV however does offer a means to thwart attacks.
> > 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
There is still the effort needed to obtain the many SPF records for each
and every message.
> > 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
This is wishful thinking.