Mailing List Archive

draft-newton-maawg-spf-considerations-00
Fresh from the I-D factory:

draft-newton-maawg-spf-considerations-00

http://www.ietf.org/internet-drafts/draft-newton-maawg-spf-considerations-00.txt


-------
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@v2.listbox.com
Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
Amazing, absolutely amazing!

Look at this example:

1 S: 220 milo.example.org SuperDuper Mail Server v1.5
2 C: HELO felix.example.net
3 S: 250 milo.example.org Ok.
4 C: MAIL FROM: <bob@example.com>
5 S: 250 Ok.
6 C: RCPT TO: <alice@example.org>
7 S: 250 Ok.
8 C: DATA
9 S: 354 Ok.
10 C: Subject: This is an example email
11 C: From: Bob <bob@example.net>
12 C: To: Alice <alice@example.com>
13 C:
14 C: This is the body of the email message.
15 C: It is two lines long.
16 C: .
17 S: 250 Ok. 42548455.00000B74
and not ONE security consideration or discussion about the RCPT TO:
validatity.

The assumption is that RCPT is a validate address. THIS IS A POOR
ASSUMPTION IN A PRACTICAL IMPLEMENTATION OF SPF OR ANY PROTOCAL PERFORMING
CHECKS BEFORE THE RCPT STATE. It is without a doubt a major DNS Overhead
Reduction consideration and without a doubt a security consideration.

This lack of consideration alone makes the "implementation" document
worthless to me. Once again, this is a prime example of "Administrator"
types writing technical documentations but who lack implementation insights.

Do me a favor and pass this message to Newton.

----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)



----- Original Message -----
From: "Frank Ellermann" <nobody@xyzzy.claranet.de>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss@v2.listbox.com>
Sent: Thursday, April 21, 2005 5:41 PM
Subject: [spf-discuss] draft-newton-maawg-spf-considerations-00


> Fresh from the I-D factory:
>
> draft-newton-maawg-spf-considerations-00
>
>
http://www.ietf.org/internet-drafts/draft-newton-maawg-spf-considerations-00
.txt
>
>
> -------
> 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@v2.listbox.com
>


-------
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@v2.listbox.com
Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
Fresh from the FUD factory:

> draft-newton-maawg-spf-considerations-00

Sigh... It's really not Andy's fault if he's forced to explain
the "zone cut" as a major difference between "classic SPF" and
"original SPF". It's the same problem on the ASRG list or on
spf-devel.

WTH is going on with the SPF Council and Wayne's draft -01 ?

[Sender-ID]
| The syntax of the record can either be the SPF syntax
| specified by original SPF (Section 2.1.1) (identified by the
| "v=spf1" version identifier) or a slightly different SPF
| syntax (identified by the "spf2.0" identifier).

That's of course hogwash, v=spf1 doesn't work with PRA, period.

| 3.1 User Agents

SPF is almost useless as anti-phishing tool, and PRA isn't much
better. Now that's true. Never mind that SPF never claimed to
be an anti-phishing tool.

| 3.3 Publisher's Intent

That chapter is wrong. First of all v=spf1 is *incompatible*
with PRA no matter what Meng, Jim, the RfC editor, Andy, Phil,
or others say.

NOT RECOMMENDED is really not good enough, SHALL NOT is clear.

| a non-committal SPF record of "spf2.0/mfrom ?all" will signal
| that all PRA checking against this domain will have unknown
| results.

No, see draft-lyon-senderid-core-00 (3.4):

: if the information in a "v=spf1" record is not correct for a
: PRA check, administrators SHOULD publish
[...]
: an "spf2.0/pra ?all" record indicating that the result of a
: PRA chek is explicitly inconclusive.

If fact "spf2.0/pra" is enough to opt-out from this PRA abuse,
5 bytes saved. And certainly _not_ "spf2.0/mfrom ?all", what
a monstrous idea.

Of course v=spf1 publishers won't do this, they just follow
the spec., v=spf1 is _never_ tested against PRA because this
_must_ cause havoc, especially because there are so few FPs.

And the author of this text should know this. Andy was it who
asked Mark to create an spf2.0/mfrom scope and I-D different
from spf2.0/pra exactly for this reason. Mark did this, see
<http://purl.net/xyzzy/home/test/> draft-ietf-marid-* (but not
the 2005 CSV texts pretending to be from the defunct MARID WG)

I'll never trust anybody involved in the MARID disaster, never.

| 6.1 Mechanisms Lookup

Again the worst case of 111 DNS queries (1 TXT, 10 MX, each MX
with 10 names). That's a _theoretical_ limit, one q=mx reply
normally includes the corresponding IPs. And then this worst
case degenerates into 11 queries. Make it 12 for q=spf before
q=txt. And it's a DDoS attack scenario, real sender policies
are not that complex.

The 20 seconds limit is something I'm strongly opposed to, but
Wayne never answered. I hope that nobody implements it - the
DNS timeout is good enough, SPF does not need its own timer.

| receivers and senders may need to reach bilateral transaction
| agreements that bypass SPF in cases where SPF records cannot
| be formulated with more tolerable values.

Yes, that's a good idea.

| 6.2 Zone Cut Issues

Sigh, see above, that's really not Andy's fault. The reason
given to remove the "zone cut" is the most convincing I've seen
so far. I'd still say that it's the problem of the sender to
get his DNS right, but discussing this with clueless "uplinks"
(left to right in a FQDN) could be a royal PITA.

| If no adverse problems are found after a sufficient period of
| time, change the SPF record so that it makes the most
| agressive assertion (i.e. end it in "-all")

That part (6.3.1) should be copied to any SPF FAQ or draft.
Stopping precisely _before_ this statement:

| Due to unknowable forwarding relationships with the Internet
| email infrastructure, it may not be possible for all domains
| to publish SPF records with an agressive assertion.

Forwarding is the business of the receiver, not the sender, and
SPF is a _sender_ policy framework.

| 6.3.3 Use of the 'include' Mechanism

Andy claims that "classic" SPF is here incompatible with the
"original" SPF behavious: For "classic" it's an error if the
included record is not found.

Andy's definition of "original" matches what I'd consider as
"original": draft-mengwong-spf-01 And in this text I read:

: However, if the new query returns none, error, or unknown,
: then processing of the entire SPF query stops immediately
: and returns the error result.
..................^^^^^
Oh yes, the table below this clear statement got it wrong and
proposes to return "unknown", it's just a very old and buggy
spec., that's why there were one - two - three more attempts
to get a proper draft (marid, lentczner, schlitt). "Classic":

: TempError | throw TempError
: PermError | throw PermError
: None | throw PermError

Wayne uses 550 5.5.2 if repeated attempts from exactly the same
sender with the same broken sender policy are useless. That's
the definition of 5xx in RfC 2821.

"Lentczner" (cited by lyon-senderid-core-00) == "classic".

Finally draft-ietf-marid-protocol-03 (sounds familiar ?), same
as "classic". The stupid table in the "original" draft was a
BUG, as far as I'm concerned. And BTW it's not the only BUG in
the "original" draft.

| 7.2 Use of Other Authentication Schemes
[...]
| v=spf1 +all

A chapter about imaginary benefits of "+all", but FUD about
v=spf1 vs. PRA, FUD about "include", not one word about the
real purpose of spf2.0/mfrom or v=spf1 (rejecting forgeries).

Bye, Frank (posted in spf-discuss)


-------
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@v2.listbox.com
Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
Egads! I strongly object to any further progress of this draft without
some major reworking.

Half the important implementation hurdles that face SPF deployment are
not mentioned in this draft at all.
These include clearly defined, well-known, publicized flaws^H^H^H^H^H
items.

(It's also full of typos a spell-check would catch.)

On Thu, 21 Apr 2005 23:41:34 +0200, "Frank Ellermann"
<nobody@xyzzy.claranet.de> said:
> Fresh from the I-D factory:
>
> draft-newton-maawg-spf-considerations-00
>
> http://www.ietf.org/internet-drafts/draft-newton-maawg-spf-considerations-00.txt

-------
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@v2.listbox.com
Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
In <42684379.45AE@xyzzy.claranet.de> Frank Ellermann <nobody@xyzzy.claranet.de> writes:

> Fresh from the FUD factory:
>
>> draft-newton-maawg-spf-considerations-00
>
> Sigh... It's really not Andy's fault if he's forced to explain
> the "zone cut" as a major difference between "classic SPF" and
> "original SPF". It's the same problem on the ASRG list or on
> spf-devel.
>
> WTH is going on with the SPF Council and Wayne's draft -01 ?

Frank: I've been a bum.


That being said, here are my comments on Andy's I-D:

: 2.1.1 Original SPF
:
: The specification in [1] (and its immediate predessor) was the first
: specification considered to contain the basis of SPF.

I disagree that draft-mengwong-spf-00.txt was the first specification
considered to contain the basis of SPF. It is actually one of the
last. Developement of SPF had been going on for about 9 months with
over a dozen different drafts before that particular one.

The first SPF draft to be considered useful for deployment was
draft-mengwong-spf.02.9.3.txt, released Dec 9, 2003. Several
revisions, mostly editorial improvements were made between then and
Feb 11, 2004 when draft-mengwong-spf-00.txt was released.

It may be that the draft-mengwong-spf-00.txt version was the first to
be submitted to the IETF, but it was hardly the first to be the basis
of SPF.

On May 16, 2004 the draft-mengwong-spf-01.txt draft was release, which
I'm pretty sure was also submitted to the IETF.


: 2.1.2 SPF Classic
:
: There exists some ambiguity regarding the term "Classic SPF" or "SPF
: Classic" as it was originally used to distinquish original SPF
: (Section 2.1.1) from a variant of SPF known as Sender ID (Section
: 2.1.3). However, the more recent use of the term "SPF Classic"
: refers to [5]. This specification differs from original SPF (Section
: 2.1.1) in the following ways:
: o DNS lookups that fail to find TXT records will use an algorithm to
: find DNS zone cuts and requery the DNS further up the tree.

As Meng indicated, this has been eliminated from the working documents
for the spf-classic-01 draft.

: o Checking of the fully qualified domain name given in an SMTP HELO
: or EHLO command is optional even if an address is given in the
: SMTP MAIL FROM command.

HELO checking was optional in the draft-mengwong-spf-01.txt draft. At
the time of the writting of that draft, there was only "SPF", and this
draft is generally considered to be the target of what is considered
to be "SPF classic".

The current draft-schlitt-spf-classic-* drafts are aimed at
reconciling the differences between the most common SPF implmentations
and the various SPF drafts. The intent is to be as close to
draft-mengwong-spf-01 as possible, while using the wordsmithng done
during the MARID work group.


So, really, I think you should eliminate the "original SPF" section
since all SPF drafts have been evolving. The hope is that the
draft-schlitt-spf-classic-* versions will be the final product of SPF
version 1.

: 2.1.3 Sender ID
:
: This variant of SPF is defined by [2] , [3] and [4]. It differs from
:
: It should be noted that some proponents of SPF Classic (Section
: 2.1.2) do not consider Sender ID (Section 2.1.3) to be a legitimate
: variant of SPF. This may cause confusion when determining the
: compliance of software.

If, by "some proponents", you mean "all but a few", then yeah.

To reduce the confusion caused by this, you should not call Sender ID
a variant of SPF. You could say that Sender ID has origins in both
SPF and Microsoft's CallerID.

: o The email identity used is determined by the publisher of the SPF
: record.
: o It defines a new email identity that is selected from the headers
: of the email message using an algorithm called the Purported
: Responsible Address (PRA).

Please make sure you mention that there are many known cases where the
use of existing SPF records for Sender ID will cause email to be
incorrectly rejected. Most of these cases aren't common at this time,
but they are likely to grow.


: o The syntax of the record can either be the SPF syntax specified by
: original SPF (Section 2.1.1) (identified by the "v=spf1" version
: identifier) or a slightly different SPF syntax (identified by the
: "spf2.0" identifier).

As you well know, the MARID working group determined that it was not
appropriate for Sender ID to use SPF v1 records and it was decided
that they *MUST* use "spf2.0" records. As you well know, the IETF
requested that the *MARID* documents be submitted as experimental RFCs
and that the current SenderID documents fail on both of these points.


: The domain name given on line 2 (felix.example.net) of the SMTP
: transaction is the HELO identity, and it is suppose to be the fully
: qualified domain name of the mail server sending the email. Original
: SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) specify that an
: SPF DNS TXT resource record by that name is to be consulted to
: determine if the source IP address of the SMTP connection is
: authorized to act on behalf of the HELO identity.

Please change "original SPF and SPF Classic" to "SPF", or "all
versions of SPF".


: The domain name of the email address in Line 4 (example.com) is the
: MAIL FROM identity used by original SPF (Section 2.1.1) and SPF
: Classic (Section 2.1.2)

Same here.


: Lines 10 through 12 are the headers of the email message. The PRA
: algorithm selects an identity from these headers. In this example,
: the PRA specifies the email address in Line 11 and the use of the
: domain name in that email address (example.net) as the Purported
: Responsible Domain (PRD). An SPF DNS TXT resource record by that
: name is to be consulted to determine if the source IP address of the
: SMTP connection is authorized to act on behalf of the PRA identity.
: See [3].

Please change this to "SPF2.0 DNS TXT rouce records" so as to confirm
to what you told the SenderID folks to do.



: Since the PRA is the only identity verified that is part of the email
: message, verification of the PRA is the only part of SPF that
: attempts to insure that end-users see authorized email addresses.
: However, the PRA algorithm does not always select an identity that is
: shown to end users by mail clients. Therefore, SPF is not guaranteed
: to prevent end users from seeing forged identities.

Please change "SPF" to "SenderID".

Also please note that PRA checks both the Sender: header and the
Resent-* headers. In different situations, both of these headers may
be added and they may be added in different orders. As a result, the
PRA can not possibly be correct in all known cases, there will always
be times where it will give incorrect results.

: 3.3 Publisher's Intent
:
: For the purposes of backwards compatibility, Sender ID (Section
: 2.1.3) interprets the first record to be equivalent to "spf2.0/
: mfrom,pra", which is to say that both MAIL FROM and PRA checks are to
: occur. To avoid confusion, senders should explicitly publish spf2.0/
: mfrom records. If a sender has not taken prepatory steps to
: accomodate PRA checking, a non-committal SPF record of "spf2.0/mfrom
: ?all" will signal that all PRA checking against this domain will have
: unknown results.

Opt-out is evil and generally used by spammers.



: 5. Usage of Headers for Check Status
:
: Original SPF (Section 2.1.1) and SPF Classic (Section 2.1.2) defines

Again, get rid of the distinction between "original SPF" and "SPF classic".


: 6. DNS Usage
:
: 6.1 Mechansim Lookups
:
: Network administrators need to be conscious of the fact that SPF
: records can create more load on their DNS servers than just that of
: querying the SPF records.
:
: SPF Classic (Section 2.1.2), which has the most strict upper bounds
: on DNS lookups, allows for 10 SPF mechanisms that may trigger
: subsequent DNS lookups. In turn each mechanism may require more than
: one DNS lookup to fulfill the requirements of the mechanism. The
: theoretical maximum to conduct an SPF check is 111 DNS lookups. For
: instance, the appearance of one "mx" mechanism in an SPF record could
: result in 10 DNS lookups in the process of following the targets of
: the queried DNS MX records.

This is actually one of the real changes between draft-mengwong-spf-01
and draft-schlitt-spf-classic-00. Some implementations of SPF (such
as mine, released in Feb 2003) have always implemented these
restrictions. If it wasn't for the DoS potential, I would have kept
the "ten include/redirect" limit of draft-mengwong-spf-01.



: 6.2 Zone Cut Issues
:

This has been removed, even though it is in draft-mengwong-spf-01. It
just wasn't implemented often enough.


: As stated in Section 2.1, many implementations of SPF adhere to
: original SPF (Section 2.1.1) even though that current branch of SPF
: is described by SPF Classic (Section 2.1.2). Unfortunately, both use
: the same "v=spf1" record identifier, so there exists no easy method
: to differentiante the two programmatically.
:
: Both versions differ substantially in their error case for the
: "include" mechanism. Under original SPF (Section 2.1.1), if an
: "include" mechanism references a non-existent SPF record, SPF
: processing against all email for the domain making the reference
: would cease (essentially resulting in a state equivalent to having no
: SPF record for the domain making the reference).

In draft-mengwong-spf-00, it was allowed for either a "none" result or
a "error" result in the case of an NXDOMAIN. In draft-mengwong-spf-01,
this was changed to only allow the "error" result. Actual
implementations vary quite a bit.


: Under SPF Classic (Section 2.1.2), if an "include" mechansim
: references a non-existent SPF record, SPF processing against all
: email for the domain making the reference would result in a PermError
: state and consequent permanent SMTP rejection of the email.

Ah, this is actually something that I could see changing in the
draft-schlit-spf-classic-* specs.

Unfortunately, draft-schlitt-spf-classic-* can not be consistent with
all well known implementations of SPF and all drafts of the SPF spec.
I think that this is a reasonable choice to make, but could be
convinced to change it. In particular, I could be convinced to change
it to TempError.



Overall, there is a lot of good advice in this document, but I can't
help noticing that much of it is a duplication of what is already in
the spf-classic I-D. I guess it makes a summary of various SPF
specifications, but not all of them and not most of the actual
implementations. It also compares SPF with SenderID, which I guess is
useful.


-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@v2.listbox.com
Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
Wayne wrote:

+1 to anything you said (excl. "bum" until I have checked
what it means).

Excerpts from the complete posted Council IRC log:

| 22:00 * grumpy thought he had fixed the "_libspf2" url problem.

Okay, I missed that bit, the Web page started 22:30 when I
looked at it. Fast-forward summary of the DNS-load issue:

- the SPF wizard shouldn't propose "ptr"
- spf.pobox.com sender policy still found non-compliant
- some spf.pobox.com info considered misleading at best
- a "how-to" for very complex sender policies could help,
maybe an include:not.me strategy at the begin of these
policies could accelerate FAIL or SOFTFAIL results
- Radu plans to implement an "SPF policy optimizer", how
important is this issue for existing sender policies ?

Now I'll cut out other remarks from the IRC-log to catch
Wayne's following "monologue" for the spf-discuss records:

| 22:52 I think we also need to contact the IESG/IETF and
| explain that spf-classic-01 is *NOT* part of the
| MARID process and is *NOT* part of SenderID
[...]
| 22:52 The fact that the SenderID folks chose to base their
| work on the SPF-classic spec is not our problem.
| 22:53 The MARID co-chairs and AD requested that the *MARID*
| drafts be made experimental.
| 22:53 The SenderID folks didn't do that.
[...]
| 22:53 The MARID co-chairs and AD said that the version
| string MUST be changed
[...]
| 22:53 The SenderID folks didn't do that.
[...]
| 22:54 The IETF said that, due to trademark conflicts, the
| "SenderID" name should not be used.
| 22:54 The SenderID folks didn't do that.
[...]
| 22:54 This isn't our problem.

IBTD.

It has been and still is our problem right from day 1 in MARID.
It was our problem when MARID was closed unilaterally without
prior consultation with the WG.
It is our problem with this anonymous note to the RfC editor.
It is our problem with Andy's considerations on SPF, which are
not exactly related to the reality or anything SPF is about.

It started to be our problem right when Caller-ID was added to
the LMAP input to MARID at the last possible moment:
2004-05-20 Caller-ID published
2004-05-21 ASRG co-chair resigns
2004-05-22 [iesg-secretary #33053] sent to ietf-ipr@ietf.org

Or maybe it started with Meng's CYA-slide, where the attempts
to twist SPF into Sender-ID became obvious. No paseran, Frank


-------
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@v2.listbox.com
Re: Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
On Thu, 28 Apr 2005, wayne wrote:

> I disagree that draft-mengwong-spf-00.txt was the first specification
> considered to contain the basis of SPF. It is actually one of the
> last. Developement of SPF had been going on for about 9 months with
> over a dozen different drafts before that particular one.
>
> The first SPF draft to be considered useful for deployment was
> draft-mengwong-spf.02.9.3.txt, released Dec 9, 2003. Several
> revisions, mostly editorial improvements were made between then and
> Feb 11, 2004 when draft-mengwong-spf-00.txt was released.
>
> It may be that the draft-mengwong-spf-00.txt version was the first to
> be submitted to the IETF, but it was hardly the first to be the basis
> of SPF.
>
> On May 16, 2004 the draft-mengwong-spf-01.txt draft was release, which
> I'm pretty sure was also submitted to the IETF.

Earlier [pre-]history of SPF in 2003 and several very early drafts can be
found in my post at:
http://www.gossamer-threads.com/lists/spf/discuss/12879

When I finally find time for it, I plan to write similar history for the
2nd year (and by that time probably for 3rd one). This is not to just keep
people aware of the protocol development history process as I also would
really like to try to collect list of most interesting ideas proposed at
spf and people who have done it so that in the future proper attribution
could be put if these ideas are ever used in drafts and other documents.

> : It should be noted that some proponents of SPF Classic (Section
> : 2.1.2) do not consider Sender ID (Section 2.1.3) to be a legitimate
> : variant of SPF. This may cause confusion when determining the
> : compliance of software.
>
> If, by "some proponents", you mean "all but a few", then yeah.
>
> To reduce the confusion caused by this, you should not call Sender ID
> a variant of SPF. You could say that Sender ID has origins in both
> SPF and Microsoft's CallerID.

Since SPF Council made (going to?) press-release clearly stating that SPF
is not part of SenderID, it would be appropriate for SPF Council to have
made Andrew Newton aware of it by sending him a private copy and request
that reference to whenever its official publish copy is at is to be
included in future version of this draft document if it comes.

--
William Leibzon
Elan Networks
william@elan.net

-------
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@v2.listbox.com
Re: Re: draft-newton-maawg-spf-considerations-00 [ In reply to ]
In <Pine.LNX.4.62.0504280532310.4030@sokol.elan.net> "william(at)elan.net" <william@elan.net> writes:

> On Thu, 28 Apr 2005, wayne wrote:
>
>> [a short terse history of SPF drafts deleted]
>
> Earlier [pre-]history of SPF in 2003 and several very early drafts can
> be found in my post at:
> http://www.gossamer-threads.com/lists/spf/discuss/12879

*blush*.

I went looking for that post when I wrote my terse history, but
couldn't find it, so I reinvented the wheel.

Thanks for the link, and thanks for writing up the history. It *is*
useful.


-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@v2.listbox.com