Subject: I-D ACTION:draft-ietf-marid-protocol-01.txt

From: [email-masked]
Date: Mon, 16 Aug 2004 15:19:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the MTA Authorization Records in DNS Working Group of the IETF.

	Title		: The Sender-ID Record: Format and Interpretation
	Author(s)	: M. Wong, M. Lentczner
	Filename	: draft-ietf-marid-protocol-01.txt
	Pages		: 41
	Date		: 2004-8-16
	
This document defines the format of a record that domains publish to
   authorize a set of hosts to send mail on its behalf.  This document
   also defines the check_host() function that mail receivers evaluate
   to see if a particular host is authorized to submit a particular
   piece of mail.  This document only describes the particulars of the
   syntax and the algorithm of the function.  See the MARID Core draft
   (draft-ietf-marid-core) for how these are used in the context of
   sending and receiving Internet mail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-marid-protocol-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-marid-protocol-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: John Leslie <[email-masked]>
Date: Wed, 18 Aug 2004 17:52:47 -0400

I recognize how hard it is to put together a spec: in no way do I
wish to belittle the work that went into this. But RFCs are forever.
(Please be assured I was at least this picayune with Dave and Doug's
drafts.)

   OTOH, this was a lot of work. I don't think I'll review all the
other drafts so closely unless someone asks...

[email-masked] <[email-masked]> wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-02.txt

Meng/Mark asked:
] 
] In the interests of openness, rather than contacting the authors
] directly, please post to either:
]     the ietf-mxcomp mailing list
]  or
]     the spf-discuss mailing list.

So, here goes:

] Abstract
] This document defines the format of a record that domains publish to
                                                    ^^^^^^^
] authorize a set of hosts to send mail on its behalf...
                                           ^^^
   grammatical mismatch.

] This document only describes the particulars of the syntax and the
] algorithm of the function.

   I'd leave out the "only", and possibly add a few words to the next
sentence to clarify where the "semantics" are defined.

] 1.  Introduction
] Owners of domain names publish SPF records to make declarations about
] hosts that are and are not permitted to use their domain names...
                             ^^^^^^^^^
   "Permitted" isn't a very helpful word here.

   Granted, this is an "introduction", and we've already disclaimed any
intent to describe semantics; but I fail to see how "permitted" gives
the right connotations or denotations.

   If we avoided the passive voice, and talked about "intend to permit"
to use their domain names, I think we'd be far better off.

   We might also consider the word "authorize", though I'd strongly
recommend sticking within RFC2828 definitions of that word. BTW, we
might consider listing RFC2828 in the references...

] Mail receivers perform tests, which read published records to
] determine how a domain's declarations apply to particular hosts in
                                                                  ^^
] during mail reception.
  ^^^^^^
   I think you mean just "during".

] 2. Permitted Sender Records
] ...
]      record = version *( 1*SP ( directive / modifier ) ) *SP

   I know the Table of Contents already mentioned ABNF being "collected"
in Appendix A; but I think it would make things easier if we mentioned
in the text here that the full ABNF description of the syntax is in
Appendix A, and that parts of it are quoted in the text which follows.

] 2.1.1  SPF DNS RR Type
] ...
] Sender-ID compliant mail originating zones MUST publish SPF2 type
] records, and MAY publish TXT type records that have identical content.
               ^^^
   Perhaps we should warn folks about broken resolvers that won't be
able to retrieve SPF2 RRs: this text makes it sound as if the problem
is only finding DNS servers that correctly publish them.

] A Sender-ID compliant MTA MUST look up SPF2 RR type, it MAY lookup
                                 ^^^^^^^                      ^^^^^^
   We should try for consistency of spelling...

] TXT record at the same time, or wait for negative answer.  SPF2 type
] SHOULD be used if available.

   There's an implementation issue here: it's easy to imagine cases
where the TXT RR will arrive first, or even where the negative response
to the SPF2 query may never come. I think it would help to hint at this
issue.

] It is recognized that the current practice (using a TXT type record),
                        ^^^^^^^^^^^^^^^^^^^^
   A bad term, IMHO. RFCs are forever. I'd delete it, and replace the
parenthetical phrase with "using a TXT record" (without parentheses).

] Example RRs in this document are shown with the SPF2 record type,
] however they could be published with a TXT type.
                    ^
   Do you mean "also be published"?

] 2.1.3 Multiple Records
] A domain MUST NOT publish multiple records with the same version
] section, or with version sections that differ only in ver-minor or
] ver-ext fields.  Such multiple records would cause a system checking
] them to select multiple records for processing and will result in a
] permanent error (see Section 3.4.1).
] 
] Note that this rule still allows a domain to publish the same record
] twice, once as a TXT RR and once as a SPF2 RR, as only the SPF2 RR
] records will be considered.

   I think the intent is to state that you may not publish two SPF2
records with the version string starting with "spf2." or two TXT records
starting with "spf2."; but that it is clearly OK to publish one SPF2
and one TXT (ignoring the issue of whether they must be identical).

   I'm not sure that's what this text says.

   Also, it's easy to imagine cases of a "minor" extension giving a
domain reason to publish different records to be interpreted by
receivers who are or are not updated to reflect the extension. We
should be clear whether we're forbidding such a practice.

   You never specify what ver-ext should be used for. I think of it
as similar to SMTP extensions, but I may be far afield of the intent.
Since you seem to specify that its actual value must be ignored, I
must admit to being confused.

] 2.1.5 Multiple Strings
] Text DNS records (both TXT and SPF2 RR types) can be composed of more
] than one strings.]
           ^^^^^^^
   Usual usage is "more than one string".

   This section mainly (IMHO) deals with the feature where DNS servers
silently break a string into multiple substrings for purposes of
storing and reporting. I think it would be better to limit the text
to describing that practice and how to deal with it.

   We certainly should not be encouraging people to advertise text
strings that would require they be split.

   Also, this text as written tends to confuse multiple strings in a
single text-type RR with multiple RRs.

] 2.1.6  Record Size

] It is STRONGLY ENCOURAGED that published records remain small enough
] that query results will fit within 512 octets in order to keep DNS
] answers from falling over to TCP.  Since the answer size is dependent
] on many things outside the scope of this document, it is only
] possible to give this guideline: If the combined length of the DNS
] name and the record text is under 480 characters, then DNS answers
] should fit in UDP packets.

   This is not quite sufficient: _all_ records to be returned must fit
in the 480 bytes. (Since we seem to be headed for a situation in which
both SPF2 and SPF1 TXT records will be published for the same domain
name, this is not an academic quibble.)

] Nonetheless, Sender-ID compliant sites MUST use DNS recursive servers
] that support EDNS0 [RFC2671] and [RFC3226] in order to be able to
] receive large DNS RR sets

   This language confuses. I think you mean Sender-ID receivers MUST
query DNS servers that support EDNS0 (DNS Extension Mechanisms), not
mentioning that they also must uses resolvers which support EDNS0 to
make those queries.

   In any case, this is a capital-MUST, and I feel an obligation to
ask whether we really want to say that a sender or receiver is _not_
doing sender-ID if they don't <whatever>: personally, I would prefer
this MUST weren't there; but if we decide we want it, I think we
need to be _really_ clear what exactly MUST be done, and by which
parties to sender-ID.

] 2.1.8 Minor Version
] This document only specifies records with a minor version of "0".
] All published records MUST start with "spf2.0/pra".
] 
] Future versions of this document may define other minor versions to
] be used.

   This leaves me confused as to how we could manage a transition to
the next minor version. I recommend giving careful thought to that
expandability issue.

] 3.5.1  Term Evaluation
]...
] Mechanisms usually contain a ":" or "/" character after the name.

   I suspect that, in the wild, mechanisms will more often be
specified without these.

   Do you perhaps mean, 'most mechanisms allow a ":" or "/" ' ?

] 3.7 Domain Spec

] Several of these mechanisms and modifiers have a <domain-spec>
] section.  The <domain-spec> string is macro expanded (see Section 7).
] The resulting string is the common presentation form of a fully
] qualified DNS name: A series of labels separated by periods.  This
] domain is called the <target-name> in the rest of this document.
                       ^^^^^^^^^^^^^
   It's not clear to me whether <target-name> refers to the macro-
expanded version. (It seems it should, but this doesn't clearly
say so.)

] 4.2  "include"

   There's a lot of room for confusion between "include" and "redirect".
If one looks long enough, it becomes clear that the basic difference
is that "include" returns, thus can generate only four conditions,
while "redirect" doesn't return, thus can generate all seven.

   I think it would help to say so in as many words.

] The Include mechanism is intended for crossing administrative
] boundaries.  While it is possible to use includes to consolidate
] multiple domains that share the same set of designated hosts, domains
] are encouraged to use redirects where possible, and to minimize the
] number of includes within a single administrative domain.

   This text is particularly confusing. In fact, it _still_ confuses
me after multiple readings, and after I think I understand the
differences between "include" and "redirect".

   Unless we can clarify just what point we're trying to make, I'd
recommend deleting it.

] 4.3 "a"

   Here we get into serious IPv4 vs. IPv6 territory.

   I assume that if <ip> is v4, one implements an "A" lookup, while
if <ip> is v6, one implements an "AAAA" lookup. It wouldn't hurt, IMHO,
to say so explicitly.

   Also, since we _are_ aware of DNS servers which return incomplete
lists, it wouldn't (IMHO) hurt to hint at that -- at least to the
point of saying that <ip> is tested against the list returned.

   (Personally, I am careful enough to go through the ABNF to find
just what "dual-cidr-length" means: not everyone will be. I don't
have a specific recommendation about this; but examples might help.)

] 4.4 "mx"
]...
] Then perform an A lookup on each MX name returned,

   This is incorrect in the IPv6 case. (The grammatical structure also
doesn't match the previous sentence.)

   I'm not enough of a DNS expert to remember for sure, but I think
resolvers are required to return A and/or AAAA RRs if they are known
and they fit. It wouldn't hurt to check the actual rule, and make
the text match the rule more closely.

] This behavior breaks with the legacy "implicit MX" rule.  See
] [RFC2821] Section 5.  If such behavior is desired, the publisher
] should specify an "a" directive.
        ^
   I think you mean "also specify".

] 4.5 "ptr"
]...
] For each record returned, validate the host name by looking up its
] IP address.

   Since this has known failure cases, we need to be quite explicit.
Fortunately, we're almost there in the pseudocode which follows.
IMHO, we should still clarify the v4/v6 issue; regardless, we're not
"looking up its IP address" -- we're doing an A or AAAA query and
searching the list returned.

] This mechanism matches if the <target-name> is an ancestor of the
] name of <ip>,
  ^^^^^^^^^^^^
   I think you mean "validated host name".

] 4.6 "ip4" and "ip6"
] These mechanisms test if <ip> falls into a given IP network.
                                ^^^^^^^^^^
   I think you mean "is contained within".

] The <ip> is compared to the given network.  If they match,
                                                 ^^^^^^^^^^
   Better to say "<cidr-length> high-order bits match".

] 5.2 exp: Explanation
]...
] If <domain-spec> is empty, or there are any processing errors,
] temporary (such as SERVFAIL) or permanent (such as NXDOMAIN), or if
] no records are returned, or if more than one record is returned, then
] the explanation string empty with no further computation.
      ^^^^^^^^^^^^^^^^^^^^^^^^
   I'm not sure I know what you meant here...

] Note: During recursion into an Include mechanism, explanations do not
] propagate out. 
  ^^^^^^^^^^^^^
   I assume you mean that a "Fail", "SoftFail", or "Neutral" result
while recursed to an "include" mechanism should ignore the "exp="
modifier in the included SPF2 record and use the "exp=" modifier of
the outermost check_host(). Language to that effect, IMHO, belongs
under the "include" section, rather than here. (Or in addition; I
really don't care.)

   It's less clear whether the "TempError" and "PermError" must
similarly ignore the "exp=" in the included SPF2 record. That, IMHO,
_needs_to_ be stated in the "include" section, as well as here.

] But during execution of a Redirect modifier, the explanation string
] from the target of the redirect is used.
                                         ^
   I'd add:

" for a "Fail" result of a mechanism in the redirected record

   Also, I think it would help to explicitly state whether the "exp="
modifier may be used for any other result.

] 6.1 Unrecognized Mechanisms and Modifiers
] New mechanisms can only be introduced by new versions of this
] document.

   At first blush, I'd expect future versions of this document to
increment the <ver-minor>. But here, we run afoul of the requirement
(elsewhere) that there may not be two records which differ in
<ver-minor>.

   This strikes me as a Catch-22: we can't publish for both old and
new versions of check_host() without publishing for both <ver-minor>s;
while we're prohibited from publishing one record for each.

   While I _can_ wrap my mind about the idea that we have a <ver-minor>
field which MUST always be ignored, I'm having trouble wrapping my
mind around the idea that we MAY introduce new mechanisms, but all
receivers that haven't been updated yet MUST fail to evaluate our
SPF2 records in a useful way.

] 6.2 Processing Limits
]...
] MTAs or other processors MAY also impose a limit on the maximum
] amount of elapsed time to evaluate check_host(). 

   This fails to make it clear whether the time limit applies:
- to the entire process, including all "include"s and "redirect"s;
- to all "include"s but separately to a "redirect";
- separately to all "include"s and "redirect"s;

   If we want that to be a local option, we've got a problem trying
to guess which kind of limit the processor is imposing.

   If we specify one of the above, the guessing is much easier, but
I'd still rather have an explicit error code for the timeout.

] Such a limit SHOULD allow at least 20 seconds.  If such a limit is
] exceeded, the result of authentication SHOULD be "TempError".

   This strikes me as a bad idea.

   With "TempError", the default action (per core-3) is to reject with

" 450 4.4.3 Sender ID check is temporarily unavailable

The sender has no fully plausible alternative to simply retrying the
email, according to whatever schedule the sending MTA may have
programmed. Typically, this continues for days, possibly giving one
warning which usually says, "You do not need to retry," and offers
the user no mechanism for purging the queue.

   However, the actual situation is likely to be that that particular
receiver chooses not to evaluate a record as complicated as the one
the submitter's domain has published. This information may _never_
reach anyone capable of resolving the issue; and in the meantime,
we're generating useless DNS traffic (which by definition exceeds
what the recipient is willing to handle).

] 7.1 Macro definitions
]...
] The uppercase versions of all these macros are URL-encoded.

   Does this mean all macros, or just the three preceding ones?

] The "p" macro expands to the validated host name of <ip>.
]...
] There are two deprecated macro letters: "p" and "h".

   I'm guessing you mean the first sentence overrides the second.
In any case, one of them should go, IMHO.

] 9. IANA Considerations
]...
] [[Missing application review policy]]

   We need to specify at least the allocation method (e.g. first-come-
first-served).

] B.1 Simple Examples
]...
] spf2.0/pra mx/8 mx:example.org/8 -all
]    -- any sending host in 192.0.2.128/24 or 192.168.2.136/8 passes

   CIDR lengths are inconsistent. I'd rather not try to guess what was
intended...

--
John Leslie <[email-masked]>

---

From: wayne <[email-masked]>
Date: Thu, 19 Aug 2004 23:11:03 -0500

> (Please be assured I was at least this picayune with Dave and Doug's

Thanks for the review John!  I hope many of your points make it into a
new draft.

> the next minor version. I recommend giving careful thought to that

The creation of a minor version number was mandated during the IETF-60
session.  No semantics of what the minor version number should do were
given.  I've talked with both Mark and Meng about this, and we all
agree that we can't think of any use for a minor version, which was
why it wasn't there in the first place.  

>    I think it would help to say so in as many words.

I'm not sure what you mean by "four conditions", but I don't think
your understanding is correct.  An include: can cause both PermError
and TempError, and if there is a match, it can generate any of Pass,
Fail, SoftFail and Neutral.

Personally, I think that "include" is a really bad name for this
mechanism.  I think a much better name would be something like
"if-pass".  I've seen a lot of people get tripped up by thinking that
the include mechanism effectively includes another record, which it
doesn't.  Since we are going to have to republish everything anyway,
it would be possible to rename the the include mechanism without
causing any problems.

> if <ip> is v6, one implements an "AAAA" lookup. It wouldn't hurt, IMHO,

Up in section 4., there is the following text:

   When any mechanisms fetches host addresses to compare with <ip>, when
   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
   address, AAAA records are fetched.

I tend to agree that this should be made more explicit

> field which MUST always be ignored,

Yeah, I guess if someone can come up with a very clear purpose for the
minor version, I think it will just be a forever-wart caused people
who happened to go to the IETF-60 session and didn't really think
things through.

>                              [...], I'm having trouble wrapping my

The whole "unknown mechanism" logic in for SPF and SenderID is totally
bogus.  There is *nothing* that can be done with unknown mechanisms
that can't be better done with unknown modifiers.  Worse, they cause
confusion and allow for typos to cause sporadic failures.

For example, if someone publishes "spf2.0/pra mx ipv4:1.2.3.4 -all"
they will never get to the -all.  If most of the valid email comes
from the MX IP addresses, this error will not show up most of the time.

This is actually a very common error in SPF records.  The result of
this "unknown mechanism" stuff is that SenderID will be less reliable,
with zero upside.

> ] amount of elapsed time to evaluate check_host(). 

I have to admit that I'm very disappointed that these processing
limits have not been improved.  Right now the only way a SenderID
implementation can prevent DoS attacks against third parties is to not
be RFC compliant.

The DoS problem isn't with the domain owner generating records that
require too many DNS lookups on their server.  Domain owners will
quickly figure out that that is a bad idea.

The DoS problem isn't with the receiver of the email.  If SenderID
checking is too expensive, they will simply become non-RFC complaint
and abort the checks.

The problem is that a malicious domain owner can set up SenderID
records that cause traffic to a third party victim.  Then, by using
some simple SMTP sessions, the malicious can greatly amplify their
bandwidth by generating bogus DNS request and use the receiving MTA to
hide who is actually doing the attacks.  The load created on each
individual receiving MTA can easily be made low enough that they will
not notice that they are being used as part of an attack.

-wayne

---

From: Tripp Cox <[email-masked]>
Date: Fri, 20 Aug 2004 01:42:09 -0400

> why it wasn't there in the first place.

As SPF 2.0 is a policy that speaks only to how to deal with the PRA, I 
could see a minor version being useful if additional policy classes are 
added.

For example, today:

example.com.	IN	SPF2	"spf2.0/pra mx a:smtp.example.com ?all"

Tomorrow:

example.com.			IN	SPF2	"spf2.1/pra mx a:smtp.example.com ?all"
					IN	SPF2	"spf2.1/csa mx a:smtp.example.com a:listserv.example.com 
-all"
4.3.2.1.IN-ADDR.ARPA	IN	SPF2	"spf2.1/mta a:smtp.example.com"

Where pra is the policy a receiver should apply when performing 
authorization based on the PRA, csa on the EHLO domain, and mta on the 
client IP.

Perhaps a major version change would be in order if, say, SPF were to 
adopt an XML or binary record structure in the DNS.  Perhaps also if 
the existing language's mechanisms are modified.

---

From: wayne <[email-masked]>
Date: Fri, 20 Aug 2004 07:48:14 -0500

In <[email-masked]> Tripp Cox <[email-masked]> writes:

> could see a minor version being useful if additional policy classes
> are added.

There is no need to use the minor version for the ability to extend
the SPF2 records to different scopes.

The current marid-protocol I-D gives the following ABNF for the
version token:

   version     = "spf2." ver-minor "/pra" [ ver-ext ]
   ver-minor   = 1*DIGIT
   ver-ext     = "," *VCHAR

So, things like "spf2.0/pra,mailfrom" and "spf2.0/pra,helo" are
perfectly valid.

Personally, I would *really* like to see this changed to use the
following ABNF:

   version     = "spf2." ver-minor "/" ver-scope *( "," ver-scope )
   ver-minor   = 1*DIGIT
   ver-scope   = "pra" / name

Where name is already defined as:

   name        = alpha *( alpha / digit / "-" / "_" / "." )

This would mean that SPF2 records would not *have* to be used for the
PRA.  It would also allow SPF2 records to be used for SPF-classic
usage.  For the vast majority of domains that have the same policies
for both the PRA usage and the SPF usage, people could publish:

        SPF2 "spf2.0/spf,pra ..."

-wayne

---

From: Tripp Cox <[email-masked]>
Date: Fri, 20 Aug 2004 11:53:23 -0400

>    name        = alpha *( alpha / digit / "-" / "_" / "." )

I agree.  Implementors may want to use SPF2 records for a number of 
reasons, which may or may not include PRA policy expression.  If one 
explicitly desires to not publish a PRA policy (e.g. for IPR reasons) 
and still use SPF2, such usage may break implementations expecting the 
presently-defined SPF2.0 version records.

How would you propose that we handle changes made to the SPF record 
directives and/or syntax?  Let's say, for example, that the macro 
language is extended.  In this case, legacy SPF2.0 parsers could be 
confused when encountering unexpected macro strings.  Would we address 
that by making an increase in the major version number?

Would it still be useful for the publisher to somehow advertise which 
scopes its record does/does not support, or is the mere presence or 
absence of them in the record sufficient?

In any case, I see no harm in leaving in the minor version number.  
Perhaps we'll never need it, but it is easier to put it in now than 
later.

Tripp

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Aug 2004 17:56:58 +0200

>         SPF2 "spf2.0/spf,pra ..."

Nice idea.  I also like your proposal to rename include: to
"if-pass:" (or similar).  

Maybe now is also the time to drop SOFTFAIL, UNKNOWN should be
good enough, and "exists:" allows debugging without the active
help of the recipient.
                           Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Aug 2004 12:38:12 -0700

> So, things like "spf2.0/pra,mailfrom" and "spf2.0/pra,helo" are

There is a way to define the mail channel with a single DNS lookup, but
this TXT script seems like a dog with a bone.  If there is to be
extensions considered, then excluding PRA should be one such
consideration, if nothing else then to be excluded from repudiations
based upon RFC2822 content.  This also helps prevent the need for "open"
lists to allow the use of a return mailbox.  I can see many reasons for
not including PRA.

So should "spf2.0/mailfrom"  as example.  

version = "spf2." ver-minor [scope]
ver-minor = 1*DIGIT
scope = "/" *VCHAR ","

-Doug

---

From: Roy Badami <[email-masked]>
Date: Sat, 21 Aug 2004 04:21:50 +0100

>>>>> "wayne" == wayne  <[email-masked]> writes:

    

I like this proposal; I think it is more flexible than what we
currently have in the drafts.

I think I'd prefer ver-token to ver-scope -- at this point there's no
need to suggest a particular use for the extention mechanism, even by
implication, and there may be other uses we haven't yet though of that
will make us regret the ver-scope name.

The idea would be that only records with 'pra' present as a ver-token
would be considered by the Sender ID draft.  Yes, a future standard
can always stop Sender ID from interpreting the record by changing the
version string incompatibly (eg by bumping the major version) but this
approach gives more flexibility in terms of the way that the Sender ID
can be extended...

    -roy