In <017801c55fd2$5a348750$6c62fea9(_at_)ibmrkydk2ufvdd> "John
Glube" <jbglube(_at_)sympatico(_dot_)ca> writes:
<snip>
|I strongly disagree that spammers have figured out ways to
|"game" SPF. SPF allows domain owners to publish a very
|wide variety of sender policies. If they want to publish a
|policy that gives Neutral results, that is certainly within
|their right and they should accept the downside of such
|policies. Spamers can freely publish their sender policies
|too, that isn't the point of SPF.
The email infrastructure is extremely complex and very
fragile. By making this comment, one is demanding that
people ignore reality.
Why do I say this? Let's take a simple example. I rent a
server at a data location center to run the online aspects
of my business.
I market my own software from my web site. Sales are
confirmed by delivery of email receipts, along with secure
unique login data to allow for product downloads. Software
upgrade notifications are sent by email. I also run two COI
mailings lists, a web support forum (which requires people
to register and verify their registration) and relay all my
business and personal mail through my server.
I travel a lot and use my laptop while on the road,
connecting through my wireless connection. Should this not
be possible, I want to be able to use any machine that is
available at the time, along with any Internet connection
to send email through my server.
Delivery of my personal, business and transactional email
is mission critical. I can't afford to have this kind of
email go missing because of a problem with mail forwarding
and SPF.
Would you advise this individual to publish a closed or
open SPF record, given the present state of the email
infrastructure?
Now take this situation and magnify it millions of times,
ranging from users who simply send and receive email, all
the way up to providing support and facilities for large
corporation, which is what a large Internet access
providers like EarthLink is facing.
Would you advise EarthLink to publish a closed or open SPF
record?
In both cases, the prudent answer is to publish an open SPF
record.
At the same time, what happens if technologists tell the
world:
* Senders, protect your domain against spoofing, publish an
SPF record.
* Receivers, you can use SPF as a means to authenticate the
RFC 2821 MAIL FROM domain and reject mail based on the
result.
Then what occurs if people believing this is the way
forward, design a protocol based on these assumptions and
then call upon everyone to proceed in the "right" way and
adjust their affairs accordingly.
You will end up with the equivalent of a virtual train
crash.
Why? Because in the real world some people, like Internet
access providers have to publish open records, while the
design requires everyone publish closed records to achieve
its objective.
To put it simply, "she don't work as designed boys."
What do bad guys do? Take advantage of these sorts of
ambiguities and slip through the resulting cracks.
Want to fix the problem? Make it clear that after extensive
testing we have learned that given the complexities of the
email infrastructure, until all the edge cases are
addressed:
* Senders should only publish v=spf1 open records.
* As to receivers, v=spf1 records are best used to verify
the outward bound mail server of the sender, so allowing
the receiving network to filter the mail stream against
internal or external safe lists.
To avoid problems with back scatter, receiving networks
should only reject for malformed v=spf1 records.
Some people may say, well what's the good of that, SPF is
supposed to change the world. It has to the extent that it
began a process, but it is time to learn from reality and
move to the next step.
Look, I understand that I am challenging basic assumptions.
This is why I strongly urge members of the SPF Council to
sit down with the folks at AOL. AOL is your champion. Find
out what AOL has done with v=spf1 records and learn. Then
adjust your design goals for this version of the protocol
accordingly.
|> * Use SPF to both authenticate the mail stream and
|>validate the return path. I don't agree with the
|>present approach of expanding SPF to cover EHELO/HELO
|>checks, simply because SPF was designed to focus on the
|>SMTP mail from authentication.
|
|SPF had checks against the HELO domain from the very first
|spec released almost 2 years ago. All that has changed is
|that over a year ago, this HELO check was said to be ok to
|do separately, and more recently this check has been
|changed to RECOMMENDED.
|
|There is very little new here, and no real "expansion of
|SPF".
Don't compound the design errors by mixing apples and
oranges. The HELO and SMTP MAIL FROM serve different
purposes. As I understand it, the HELO address identifies
the server making contact. The SMTP MAIL FROM address is
the address to which delivery status notices are sent. Each
identity serves a different purpose.
For this reason, each identity deserves its own design
approach, which requires a separate protocol so allowing
focused effort being placed on the problems and
difficulties surrounding the use of that identity for the
purpose of email authentication, given the complexity of
the email infrastructure.
<snip>
|Well, I wish the best of luck to the CSV folks. I confess
|that I've been way behind on email for several months now.
|Could you give a brief description about how the CSV folks
|are progressing? Lots of good news on their mailing list
|about new implementations and deployment?
There is a fable about the tortoise and the hare. The hare
in all its excitement lost the race. People need to bear
that fable in mind, although email authentication is not a
race. Rather it is serious business and protocol designers
need to ensure all the edge cases are considered before
running off and saying this is the way.
|>The whole underlying premise of the SPF design was to
|>ensure that "bounces" went to the right place. How was this
|>to be achieved?
|I disagree that blocking bounces was the "whole underlying
|premise of SPF". That was a hot button for some people,
|but not everyone. Personally, I think the 2821.MAILFROM
|identity is just the most useful identity to validate in
|the current state of email.
|
|Unlike the 2821.HELO identity, the 2821.MAILFROM identity
|is actually used for something and so it is much more
|likely to be correct.
|
|Unlike things like the 2822.From: identity, the
|2821.MAILFROM identity is available at SMTP time. The
|2822.From: identity can also be a list of addresses and it
|has interactions with the 2822.Sender: identity that are
|not aways well understood by everyone.
Given this rational and analysis, why clutter up the design
by recommending that people check the 2821.HELO identity as
well as the 2821.MAIL FROM identity?
Or is the real agenda a political goal, to establish SPF as
the record of choice for checking both the 2821.HELO
identity and the 2821.MAIL FROM identity and so outflank
any perceived threat from designs which focus solely on
checking the 2821.HELO identity?
Having said this, if the sole purpose of this particular
protocol is to document existing usage, then disclaim the
political goal.
Further, given the lessons learned to date, state clearly
the limitations for senders and best usage of v=spf1
records by receiving networks, to filter against safe lists.
This approach serves a couple of purposes:
* It avoids the damage which may arise with senders
unwittingly publishing closed records and all the "edge
cases" involving path authentication, with mail forwarding
being the prime example, by encouraging both senders and
receivers to act prudently using this design.
* It thwarts bad guys from taking advantage of the existing
ambiguity between the design and reality, while freeing the
SPF community to protect the brand and move forward with
all due deliberation in pursuit of spf3.0.
* It enhances your rational for recommending
that receivers not use v=spf1 records for PRA
authentication, since the design premise is entirely
different.
At the same time, by making clear the limitations
surrounding the design until all the edge cases are
resolved, it allows those who recognize the underlying
problems with spf2.0 to make their voice even stronger,
should they so desire.
How can you use an open policy record which should only be
used for filtering against safe lists, because of all the
edge cases, to tell consumers this email is safe?
Simple logic dictates this lack of security must expose
both senders and the consumer to undue risk.
There is an old adage, "the truth will set you free." In
this case, the truth is that until all the edge cases are
resolved, the highest and best use of v=spf1 records is for
filtering against safe lists.
Having said this, it then allows the SPF community to move
forward, learning from the mistakes made, while ensuring
the existing work done can serve the better good.
<snip>
|>I am discounting the trusted-forwarder.org set up, because
|>this is a band aid solution, unless people are prepared to
|>accept that this is an interim step and the
|>trusted-forwarder.org site is changed to reflect this
|>reality.
|
|Uh, please let me know what parts of the
|trusted-forwarder.org website you think needs to be
|changed. I thought it was very clear that it is an interim
|step.
The site makes it clear that this is an interim step. If
you want to stick with the existing design goal, which I
suggest is flawed, my question is how long will it
realistically take before mail forwarders adopt and
implement the needed software patches to allow for
re-injection of a message into the mail stream, presuming
this is the proper way to proceed?
Then ask whether the time frames you have established for
the interim step are realistic, or whether an adjustment is
required.
My second rant in two days. I must stop this.
John
John Glube
Toronto, Canada
voice:416-535-6366; mailto:john(_at_)trusted-email-sender(_dot_)com