Wayne,
On page 3, paragraph 1, in draft-schlitt-spf-classic you
write:
"The current e-mail infrastructure has the property that
any host injecting mail into the mail system can identify
itself as any domain name it wants. Hosts can do this at a
variety of levels: in particular, the session, the
envelope, and the mail headers. While this feature is
desirable in some circumstances, it is a major obstacle to
reducing end-user unwanted e-mail (or "spam"). Furthermore,
many domain name holders are understandably concerned about
the ease with which other entities may make use of their
domain names, often with intent to impersonate.."
I might suggest:
"SMTP allows any host injecting mail into the system to
identify itself using any domain name. This can be done in
the session, envelope and mail headers, permitting sender
anonymity. Unfortunately, network abuse by unsolicited bulk
emailers, often involving email forgery has reached
epidemic proportions."
My core objection is suggesting SPF classic can form part
of the solution to end-user unwanted e-mail. It can't,
because the concept of unwanted e-mail is totally
subjective.
If one defines the problem this way, the only realistic
solution is to:
* Give the end user various means to control access to his
or her e-mail box;
* Leave it up to the end user to decide what e-mail she or
he wants to receive in her inbox; and,
* Provide a feedback loop option for responsible senders.
SPF is not really part of this solution.
My other objection is that this approach feeds into the
concept of opt-out bulk mailing advocated by the Direct
Marketing Association.
On the other hand, depending on one's view point, SPF
classic may form part of the technical solution to aid in
thwarting email forgery, as one tool in the "solution kit."
Trusting these comments are of value.
John
John Glube
Toronto, Canada
http://www.trusted-email-sender.com
John
John Glube
Toronto, Canada
voice: 416-535-6366; mailto:john(_at_)learnsteps4profit(_dot_)com
private message: http://adcopy.quikonnex.com/
Discover How Anyone Can Get More Buyers
http://www.learnsteps4profit.com
This email contains confidential information. You may not
disclose the contents to anyone else without my consent.
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of wayne
Sent: December 30, 2004 8:05 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] latest and greatest:
draft-schlitt-spf-classic-00
Well, I've made another attempt at submitting this SPF draft to
the
IETF. It looks like my use of a "2" instead of a "0" may have
caused
the delay. I've changed the name to draft-schlitt-spf-classic-00
anyway since the draft-schlitt-spf-XX drafts were really intended
for
just libspf2, while these drafts are intended for the IETF.
The drafts are in a slightly different place now. See:
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-
00.html
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-
00.txt
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-
00.xml
A diff between this version and the previous version can be found
at:
http://www.schlitt.net/spf/spf_classic/changes_from_draft-schlitt
-spf-02.xml.diff.txt
With the last set of changes, the draft was pushed over 48 pages
again. 48 pages is way too long, RFC2822 is only 51 pages. I
went
back and deleted a bunch of stuff and was able to get the draft
back
down to 48 pages, but I'm going to start getting grumpy with
people
who only suggest additions to the text instead of deleting. You
think
there is something important that needs to be added? Well, be
prepared to show something else that is less important and should
be
deleted.
I still haven't gone through and created a list of semantic
changes
from spf-draft-200406. Sorry, I'll try and get to that soon.
The major differences between this schlitt-spf-02 spec and my
last
published schlitt-spf-classic-00 spec are:
* Near the top of the draft, there was a claim that all
references to
things like "return-path" and "reverse-path" instead of "MAIL
FROM"
would only be used in conjunction with a normative reference.
I've
updated the draft to make this actually so. ;-)
* As noted in other replies, editorial changes made by William,
Hector, Alex, etc. were applied. Check the diff for the exact
wording that I used.
* A wildcard example used names like "X.COM" instead of "X.COM.".
(I
probably should change these to example.com, but...)
* A bunch of spelling errors were found by my spell checker, but
I'm
sure a bazillion grammatical errors remain.
Hmmm... It seems like I've put a lot more work into this draft
than
the above list shows, but I guess that was doing bunch of double
checking and research.
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate
your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.822 / Virus Database: 560 - Release Date: 22/12/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.822 / Virus Database: 560 - Release Date: 22/12/2004