At 02:31 AM 5/20/2005 +0200, Frank Ellermann wrote:
Fresh from the I-D factory:
05-20 01:39 draft-lyon-senderid-pra-01.txt
05-20 01:39 draft-lyon-senderid-core-01.txt
05-20 01:39 draft-katz-submitter-01.txt
05-17 09:46 draft-ietf-dnsext-wcard-clarify-07.txt
05-17 09:46 draft-shafranovich-feedback-report-01.txt
05-14 10:06 draft-fenton-identified-mail-02.txt
05-14 10:01 draft-spf-6-3-options-06.txt
05-07 07:35 draft-hutzler-spamops-04.txt
05-06 12:15 draft-kucherawy-sender-auth-header-02.txt
05-04 02:01 draft-leibzon-emailredirection-traceheaders-01.txt
05-04 02:00 draft-lilly-field-specification-03.txt
05-03 00:12 draft-stumpf-dns-mtamark-04.txt
draft-lyon-senderid-core-01 now has a proper reference to v=spf1.
But it still says:
SHOULD interpret the version prefix "v=spf1" as equivalent to
"spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.
Doug Otis just posted a review of draft-lyon-senderid-core-01 at
http://mipassoc.org/mailman/listinfo/ietf-clear 5/20/05
Until now, I wasn't taking seriously the worry that Sender ID could tarnish
anything but themselves. I'm still convinced, however, that the best way
to deal with this is a common framework within which all methods can
operate, and none can establish a de-facto standard. One feature of such a
framework would be an authentication header format that makes it easy to
find the method used in any authentication. Filtering and blocking
software could then make distinctions between one method and another.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *