Subject: New drafts

From: Mark Lentczner <[email-masked]>
Date: Thu, 16 Sep 2004 00:41:46 -0700

Friends -

I've submitted two drafts:

draft-ietf-marid-protocol-03

   Major Changes
   * scopes added (replacing ver-ext)
   * RR Type logic reversed to -00 rules:
     - compliant publish can publish either or both
     - if both are published must be identical
     - compliant receivers can query for either
     - if both are returned, then SPF must be used
   * Fixed RFC 2119 language and usage
   * RR name changed from SPF2 to SPF
   * DNS query results are now referenced by RCODE (From RFC 1045)

   Descriptive Changes
   * New title: "The SPF Record Format and Sender-ID Protocol"
     - yes, now it really DOES describe a protocol!
   * New abstract
   * New introduction that sets out the SenderID framework

   Minor Changes
   * Removed 'p' from deprecated list of macros, 'cause it's not
   * CIDR length defaulting text clarified (section 4.6)
   * Clarifications in the text about DNS lookups for PTR and MX 
mechanisms
   * Minor changes to the ABNF (no changes to legal parses)
   * Various grammar and spelling fixes

draft-ietf-marid-mailfrom-00

   This describes using the Sender-ID protocol with a 2821 Mail From
   scope.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Sep 2004 15:13:39 +0200

On Thu, Sep 16, 2004 at 12:41:46AM -0700,
 Mark Lentczner <[email-masked]> wrote 

> I've submitted two drafts:

They do not appear on http://www.ietf.org/internet-drafts/ (yet?). Any
alternative source in the mean time?

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 18 Sep 2004 19:22:07 +0200

> draft-ietf-marid-mailfrom-00

Thanks, it's almost ready, and it covers the mandatory case
(empty Return-Path) of HELO checks in SPF1.  I like it very
much.  Six typos and other observations:

Line 363 (typo)
<< to determine the list hosts that they allow to use their domain name
>> to determine the list of hosts that they allow to use their domain

Line 415 (policy violation)
<< Tests against some other identity may also be used to override the
<< test against the "Mail From" identity.

Line 455 (designated open relays can be used with spf2.0/mfrom)
<< However, the use of open MTA relays on the Internet has long been
<< noted as a security problem.  Most sites do not run open relays and
<< many refuse e-mail from known open relays.

Line 465 (typo)
<< published SPF records must authorized any MTAs
>> published SPF records must authorize any MTAs

Line 472 (typo)
<< Internal MTAs then do not perform the authorization test To
>> Internal MTAs then do not perform the authorization test.  To

Line 507 ff. (deficits of "exp" are a matter of protocol)
<< The explanation may contain URLs that may be malicious, and/or
<< offensive or misleading text.
                Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 20 Sep 2004 00:12:37 +0200

> draft-ietf-marid-protocol-03

My observations in protocol-03 (minus typos and stuff already
reported by Nate Lion):

Line 7 ("Sender-ID" (tm))
<< The SPF Record Format and Sender-ID Protocol
>> The Sender Policy Framework (SPF) Record Format and Protocol

Short title for all page headers:
<< The SPF Record Format and Sender-ID Protocol
>> The SPF Record Format and Protocol

Then replace the eight remaining strings "Sender-ID" by "SPF".
---------------------------------------------------------------

Line 186 (delete)
<< A compliant domain SHOULD publish authorizations for every
<< defined scope.

Big ISPs may not want to regulate how and where their users use
"their" 2822-From.  That's a matter of the policy of the domain
owner, and it's the reason why we have more than one SPF scope.
---------------------------------------------------------------

Lines 206 - 212 (3 typos and a dubious MUST)
<< When a mail receiver decides to perform a Sender-ID check, it
<< MUST implement and evaluate the check_host() function (see
<< below) correctly and follow the requirements of the particular
<< scope under test.

>> When a mail receiver decides to perform a SPF check, it
>> determines the result of the check_host() function (see
>> below) following the requirements of the particular scope
>> under test.

SPF checks are defined in terms of the check_host() function,
and definitions IMHO don't qualify for an additional MUST.

<< While the tests as a whole or optional, once it has been
<< decided to perform a test it must as performed specified
<< so that the correct semantics are preserved between
<< publisher and receiver.

>> While the tests as a whole are optional, once it has been
>> decided to perform a test it MUST be performed as
>> specified so that the correct semantics are preserved
>> between publisher and receiver.
---------------------------------------------------------------

Line 244 (see also Nate's report)
<< This ensure that domains with published records and mail
<< receiver agree on the semantics of the scope.
>> This ensures that domains with published records and mail
>> receivers agree on the semantics of the scope.

Or say "the mail receiver" instead of "mail receivers".
---------------------------------------------------------------

Line 327 (delete)
<< A domain name MUST have a record of at least one type.

Domains without sender policy are perfectly okay.
---------------------------------------------------------------

Line 339
<< A Sender-ID compliant check SHOULD lookup both types.  If
<< both types of records are returned for a domain, the SPF
<< type MUST be used.
>> A SPF compliant check SHOULD lookup both types if necessary.

This SHOULD is about "do try both ways if the first way didn't
work".  It's not about receivers checking that both records
are identical, that's entirely the problem of the publisher.
The receiver is free to use whatever it gets first as is.
---------------------------------------------------------------

Line 455 ff. (see also Nate's report)
<< 2.1.8  Minor Version
Pleae move this stuff to section 2.1.2 (Version).
---------------------------------------------------------------

Line 520 (typo)
<< The function check_host() take four arguments:
>> The function check_host() takes four arguments:

Line 590 (typo)
<< If the records are in a cache, and has not expired, then
>> If the records are in a cache, and have not expired, then

Line 660 (nitpick)
<< A given mechanism type may always appear multiple times
>> A given mechanism type may appear multiple times
---------------------------------------------------------------

Line 681 (not more than one CIDR)
<< mechanism   = name [ ":" domain-spec ] *( "/" *DIGIT )
>> mechanism   = name [ ":" domain-spec ] [ "/" *DIGIT ]
---------------------------------------------------------------

Line 739 (KISS)
<< Global modifiers MAY appear anywhere in the record, but
<< SHOULD appear at the end
>> Global modifiers SHOULD appear at the end

As long as you don't say MUST the "MAY" is implied by a SHOULD.
---------------------------------------------------------------

Line 758 (delete)
<< A modifier is not allowed to be defined as both global and
<< positional.

That's IMHO obvious, same idea as for SINGULAR vs. MULTIPLE.
---------------------------------------------------------------

Line 767 (typo ?)
<< An intended side effect of these rules is modifiers cannot
<< be defined that modify other modifiers.
>> An intended side effect of these rules is that modifiers
>> cannot be defined to modify other modifiers.
---------------------------------------------------------------

Line 880 (typo)
<< When any mechanisms fetches host addresses to compare with <ip>
>> When any mechanism fetches host addresses to compare with <ip>

Line 887 (typo ?)
<< Should the server return domain does not exist (RCODE 3)
>> Should the server return "domain does not exist" (RCODE 3)
---------------------------------------------------------------

Line 909 (maybe)
<< Mechanisms after "all" will never be tested.
>> Mechanisms after "all" will never be tested. Any "redirect"
>> (5.1) has no effect in the presence of an "all" directive.

Line 918 (maybe)
<< The <scope>, <ip> and <sender> arguments remain the same
<< as current evaluation of check_host().
>> The <scope>, <ip> and <sender> arguments remain always the
>> same.
---------------------------------------------------------------

Line 1012 (the MX priorities are here IMHO irrelevant)
<< Then perform an address lookup on each MX name returned, in
<< order of MX priority.
>> Then it performs an address lookup on each MX name returned.
---------------------------------------------------------------

Line 1189 (typo)
<< provide an way to extend the record format in the future
>> provide a way to extend the record format in the future

Line 1195 - 1198 (delete)
<< This document reserves two modifiers for future definition:
<< "accredit" and "match_subdomains".  Until these are defined,
<< implementations SHOULD ignore them.  There is also one deprecated
<< modifier: "default".  Implementations MUST ignore it.

This document is quite clear about unknown and future modifiers
without this paragraph.  Obviously implementations MUST ignore
undefined modifiers.  What else "SHOULD" they do, if returning
random results is not an option ?
---------------------------------------------------------------

Line 1211 (see also line 918)
<< The <scope>, <ip> and <sender> arguments remain the same as
<< current evaluation of check_host().
>> The <scope>, <ip> and <sender> arguments remain always the
>> same.

Line 1215 (typo ?)
<< the result of current evaluation.
>> the result of the current evaluation.

Line 1309 (typo)
<< a URL with the parameters check_host()
>> a URL with the parameters of check_host()

Line 1312 (upper case both Redirect ?)
<< during execution of a Redirect modifier, the explanation
<< string from the target of the redirect is used.
>> during execution of a Redirect modifier, the explanation
>> string from the target of the Redirect is used.

Line 1394 (typo ?)
<< evaluation limit of an implementation is reached
>> the evaluation limit of an implementation is reached
---------------------------------------------------------------

Line 1466 (KISS)
<< macro-string = *( macro-char / v-char-ms )
>> macro-string = *( macro-char / v-char-dm / "/" )

Line 1473 (delete)
<< v-char-ms   = %x21-24 / %x26-7E
<<             ; visible characters except "%"

Dito in lines 2076 and 2091 + 2092, get rid of v-char-ms, it's
the same as v-char-dm or slash.
---------------------------------------------------------------

Line 1467 and 2077 (ALPHA)
<< macro-char   = ( "%{" ALPHA transformer *delimiter "}" )

Why not use the proper subset sSlLoOdDiIpPvVcCrRtT here ?
---------------------------------------------------------------

Line 1485 (as reported by Nate)
<< o  = domain of <sender>
<< d  = <domain>
>> o  = original domain of <sender>
>> d  = <domain> of evaluated SPF record
---------------------------------------------------------------

Line 1489 (typo ?)
<< v  = the string "in-addr" for if <ip> is ipv4, or "ip6" if <ip>
>> v  = the string "in-addr" if <ip> is ipv4, else the string "ip6"

What's the idea here, why not "ip4" resp. "in-addr.arpa" ?
---------------------------------------------------------------

Line 1497 (undefined term)
<< t  = current timestamp in UTC epoch seconds notation

Please add a reference.  Assume that I have an ISO timestamp
for the year 2170 and need a %{t} formula, or vice versa.

Line 1499 (dito)
<< uppercase versions of all these macros are URL-encoded.
>> uppercase versions of all these macros are percent-encoded.

IIRC that's now the preferred term (compare 2396bis)

I'll try to read the remaining 800 lines in protocol-03 later,
but as far as I'm concerned the stuff is as good as ready for
standards track.
                  Bye, Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Sep 2004 15:38:05 +0200

> draft-ietf-marid-mailfrom-00

I do not find a new version of draft-ietf-marid-core. Is anyone
working on it? The version draft-ietf-marid-core-03 has at least two
big problems:

* depends on PRA so is not compatible with the new plan announced on
Sept. 11th "co-chair judgment of consensus related to last call period
of 23-Aug-2004 to 10-Sept-2004".

* in its 7.2, contains wrong uses of Resent-* headers

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 23 Sep 2004 05:04:06 +0200

> draft-ietf-marid-protocol-03

Now after the IETF has closed MARID, and the IESG has not yet
accepted my appeal, I guess it's the best to continue all SPF
discussions in spf-discuss for the moment.

For SPF I'd like to see an update of draft-mengwong-spf-01.txt,
reflecting all the work that has gone into protocol-03.  The
syntax in protocol-03 is much better than the original syntax.

We probably can't use the stuff about different scopes for now,
therefore I propose to remove this from the "protocol", and
return to the original v=spf1 prefix instead of spf2.0/mfrom.

Without the IETF we can also remove the parts about a new DNS
RR SPF and return to the plain TXT approach.  That's not very
elegant, but the TXT "v=spf1" syntax _is_ common practice, and
introducing any incompatability with this common practice makes
no sense at this moment.

AFAIK the Received-SPF: header in draft-mengwong-spf-01.txt is
the only interesting part of "classic SPF" not yet covered by
protocol-03 plus mailfrom-00.

There are still a lot of minor issues with protocol-03 and
mailfrom-00, but I'm most interested in salvaging as much as
possible from this "fun ride" (quoting Yakov Shafranovich).

                   Bye, Frank