In <017801c55fd2$5a348750$6c62fea9(_at_)ibmrkydk2ufvdd> "John Glube"
<jbglube(_at_)sympatico(_dot_)ca> writes:
Having been around for the period that Frank wrote about, I agree
with his factual review.
Well, my records of spf-discuss traffic disagrees with many of the
"facts" that Frank presented. YMMV.
My biggest problem is that the Community is trying to do a number
of things with SPF at once:
* Put together a document which reflects what SPF was in the
field;
* Wanting to take this document and turn it into a standard, when
there are known issues surrounding SPF.
I appreciate that Wayne has posted the ID draft to various IETF
discuss lists seeking comment. However, the unfortunate reality
is that spammers have figured out ways to "game" SPF.
(See the discussion on this list concerning German spam and
recent discussions on Spam-L.)
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.
* 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".
If you think that checking EHELO/HELO makes sense, I feel it is
better to say to people publish CSV records and either
incorporate CSV checking and that whole design into the SPF
specification, or simply recommend that folks use CSV.
Why? In my view, the design parameters for checking EHELO/HELO
and SMTP mail from are different.
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?
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.
(In essence, a hacked version of CSV.)
Erh, since SPF had deployed HELO checking long before CSV was created,
I think that CSV is a hacked, and undeployed(?) version of SPF.
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.
-wayne