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
a signature.
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
provider.
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
domains.
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?
Exactly!
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
forged.
Wrong again.
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.
Access.
(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.
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
authentication.
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
seem.
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
encryption.
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
cache.
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.
-Doug