Re: [spfbis] Review of draft-ietf-spfbis-4408

["Murray S. Kucherawy" <[e-mail]>]

On Sun, Jul 15, 2012 at 10:07 PM, Scott Kitterman <[e-mail]>wrote:

> > 1.  Introduction
> >
> >    The current email 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.
> >
> > [MSK: Does "the session" refer to HELO/EHLO, rDNS, or something else?]
>
> Good question.  I don't actually recall.  I went back and looked and that
> paragraph first appears in the draft done for MARID.  The pre-MARID drafts
> don't have anything like it at all and it wasn't touched after.  My guess
> would be the SMTP session and the identity in question is HELO/EHLO.
>
> This paragraph seems to beg for editorial improvements, so I'd welcome
> text if
> someone is up to it.
>

The current email infrastructure has the property that any host injecting
mail into the system can use any DNS domain name it wants in each of the
various identifiers specified by [RFC5321] and [RFC5322], plus the "reverse
pointer" which is the purported hostname of the SMTP client as far as the
DNS is concerned [RFC1035].


>
> >    Although this feature is desirable in some circumstances, it is a
> >    major obstacle to reducing Unsolicited Bulk email (UBE, aka spam).
> >    Furthermore, many domain name holders are understandably concerned
> >    about the ease with which other entities can make use of their domain
> >    names, often with malicious intent.
> >
> > [MSK: Would ADMD from RFC5598 be helpful in place of "domain name
> holders"
> > above or "domain owners" below?]>
> >    This document defines a protocol by which domain owners can authorize
> >    hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
>
> Sort of.  I think it would have to be something like "ADMD owning the
> domain",
> since there are plenty of non-domain owning ADMDs.  I'm not sure how much
> that
> helps.
>

The opposite is true though: Every domain is owned by an ADMD.  Your
suggestion seems okay to me.

>    It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
>    identity, but also separately check the "HELO" identity by applying
>    the check_host() function (Section 4) to the "HELO" identity as the
>    <sender>.
>
> [MSK: We need to explain why this is RECOMMENDED.  We might later, but I
> haven't gotten that far yet and I might forget to come back and delete
> this.  :-)]

It doesn't.  It's RECOMMENDED as a general practice both in the sense of
> "being a useful thing to do" and for overall consistency of results.  I
> don't
> know that the latter is enough of an interoperability point to keep the
> 2119
> language.  The SPF design,  up to the point where local policy starts, is
> meant to be pretty deterministic and get consistent results.
>

I think saying exactly that is probably sufficient.


>
> >    If domain owners choose to publish SPF records, it is RECOMMENDED
> >    that they end in "-all", or redirect to other records that do, so
> >    that a definitive determination of authorization can be made.
> >
> > [MSK: RECOMMENDED in RFC2119 terms is effectively a SHOULD.  I don't
> think
> > we should do this, as that's strictly a local policy matter and not one
> of
> > interoperability.]
>
> Agreed.  This needs to be reworded into something along the lines of "If
> the
> domain owning ADMDs purpose in publishing the SPF record includes allowing
> other parties to make a definitive determination of which hosts are not
> authorized by the ADMD to send mail from the domain, then they MUST
> publish a
> record that ends in "-all" or redirect to other records that do."
>

That's probably fine, especially if there's a "however" type reference to a
section that discusses caveats in use of SPF, such as its known failure
modes (forwarders, for example).


>    When changing SPF records, care must be taken to ensure that there is
> >    a transition period so that the old policy remains valid until all
> >    legitimate email has been checked.
> >
> > [MSK: There's no way to ever know this.  Who's to say that a message
> hasn't
> > sat queued for a month and finally goes through, or something erroneously
> > begins relaying and thus re-evaluating a ton of old mail?  We saw that
> all
> > the time at Cloudmark, where someone would report an entire chunk of
> > his/her inbox as "spam" all at once.  Re-evaluations like that could have
> > undesirable effects.  Thus, I think that last bit isn't actionable.  DKIM
> > talked about overlapping selectors as a transition policy, but I'm not
> sure
> > it applies here.  Don't know what to suggest either.]
>
> Microsoft's original Caller ID for Email specification suggested 30 days,
> but
> they also envisioned checking in MUAs, which SPF never has (people do it,
> but
> it often doesn't end well).  The intent of this was to warn people that
> there
> needed to be a transition, but we didn't try to define the time requirement
> because, as you say, there's no way to know.  This should probably move to
> section 9.
>

Sure, let's try that.


>
> > 2.5.  Interpreting the Result
> >
> >    This section describes how software that performs the authorization
> >    should interpret the results of the check_host() function.  The
> >    authorization check SHOULD be performed during the processing of the
> >    SMTP transaction that sends the mail.  This allows errors to be
> >    returned directly to the sending MTA by way of SMTP replies.
> >
> > [MSK: I have an open ticket in the tracker about check_host(), so I'll
> make
> > my first comment about it here though there will be many more later.  The
> > very string "check_host()" looks like a function definition, and as I
> said
> > in the tracker item, the IETF prefers to avoid the business of API
> > definitions.  It's possible that I might be able to search-and-replace it
> > into something more palatable.  This is just a placeholder comment to
> note
> > that I still think it's an issue and I'm figuring out how to suggest we
> > deal with it.]>
>
> It looks like later you started replacing check_host() with CheckHost.  If
> it's just a string replacement like that, I don't object.  I don't like the
> idea of creating diff for things like this, but as long as there's support
> in
> the group for it, no problem.
>

The chatter in Paris suggested simply adding a paragraph before the
definition of check_host() that says emphatically that this is not an API
definition, but rather the mechanism is used to illustrate the algorithm; a
compliant SPF implementation MUST do something semantically equivalent to
what we describe for check_host().  Pete said this was probably
acceptable.  It's probably less work than all the s// I did here as well.
We should probably try that approach, in retrospect.


>
> >    Performing the authorization after the SMTP transaction has finished
> >    can cause problems, such as the following: (1) It might be difficult
> >    to accurately extract the required information from potentially
> >    deceptive headers; (2) legitimate email might fail because the
> >    sender's policy had since changed.
> >
> > [MSK: How is (1) above specific to post-transaction processing?  Seems
> to me
> > it's a problem at the end of DATA as well.]>
> >    Generating non-delivery notifications to forged identities that have
> >    failed the authorization check is generally abusive and against the
> >    explicit wishes of the identity owner.
>
> I guess this is a bit implementation dependent.  In Postfix, the MTA I'm
> most
> familiar with, all of the information from the SMTP session is still
> available
> to me through it's policy interface.  Meng Wong was also a Postfix user,
> IIRC,
> so this wording may be too implementation specific and need to be
> generalized.
> I'd appreciate help on text.
>

Just change "after the SMTP transaction has finished" to "other than using
the return-path and client address at the time of the MAIL command during
the SMTP session", and I'd be happy.


>
> > [MSK: I think we should say more here.  For example, how exactly is it
> > abusive?  The recipient has done exactly what it was asked to do, yet
> it's
> > abusing someone?  Rather than saying it's abusive, I suggest we say it
> > introduces backscatter, and then define that term.]
>
> Makes sense.  If someone can suggest a definition or a reference for a
> definition (even better), I would appreciate it.
>

RFC3834 comes closest, I think.  Section 2, especially.



>
> > 2.5.1.  None
> >
> >    A result of "none" means that no records were published by the domain
> >    or that no checkable sender domain could be determined from the given
> >    identity.  The checking software cannot ascertain whether or not the
> >    client host is authorized.
> >
> > [MSK: s/means that/means/, s/or that/or/]
> >
> > [MSK: What constitutes "checkable"?]
>
> It means a domain could not be extracted to be used in check_host()
> (CheckHost).  The two possible conditions are "couldn't figure out what
> domain
> to query for a TXT record" and "queried for a record, got no DNS errror,
> and
> did not get an SPF record back (could have gotten other TXT records."  It
> would be good if someone could suggest a clearer way to put this.
>

A result of "none" means either (a) no syntactically valid DNS domain name
was extracted from the SMTP session that could be used as the one to be
authorized, or (b) no TXT records were retrieved from the DNS that appeared
to be intended for use by SPF verifiers.


>
> > 2.5.4.  Fail
> >
> >    A "fail" result is an explicit statement that the client is not
> >    authorized to use the domain in the given identity.  The checking
> >    software can choose to mark the mail based on this or to reject the
> >    mail outright.
> >
> > [MSK: We should probably give a sentence somewhere above this about
> what's
> > meant by "mark the mail".  Maybe even a small section about possible
> "fail"
> > actions that underscores the fact that rejection vs. marking is a choice
> > and neither is specifically required would be a good idea.]>
>
> I think change the second sentence to something like "Disposition of SPF
> fail
> messages is a matter of local policy.  See [new part of section 9] for
> considerations on developing local policy." Then we'd add what you're
> suggesting to section 9.  That makes it very clear that the mark/reject
> decision is up to the receiver and not a normative part of the protocol.
>

That sounds much better.  I'll wait to see what you develop there.


>
>
> >    example, the recipient's Mail User Agent (MUA) could highlight the
> >    "softfail" status, or the receiving MTA could give the sender a
> >    message using greylisting, [RFC6647], with a note the first time the
> >    message is received, but accept it on a later attempt based on
> >    receiver policy.
> >
> > [MSK: Are there any implementations that do this?]
>
> Yes.  Tumgreyspf can do this.  It's a blended SPF/Grey listing application.
>

Hmm.  It sounds complicated.  Although it's possible and legal, does it add
anything here to call it out as an example?  I'm pushing for simplicity
here.


>
> > 2.5.6.  TempError
> >
> >    A "temperror" result means that the SPF client encountered a
> >    transient error while performing the check.  Checking software can
> >    choose to accept or temporarily reject the message.  If the message
> >    is rejected during the SMTP transaction for this reason, the software
> >    SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3
> >    enhanced status code.
> >
> > [MSK: Do we really need to spell out SMTP reply codes and enhanced status
> > codes?  Isn't it enough to say those codes are defined in RFC5321 and
> > RFC3463, and leave it at that?]
>
> I think we should.  There was an erratum about one of them being missing
> and
> it would be odd to resolve that erratum by removing them all.
>  Additionally,
> I'm not sure it's 100% obvious.  When we were reviewing that erratum, we
> discovered RFC 4408 got one of them wrong.  I think there is an
> interoperability point here about consistency that it's worth not removing
> text for.
>

What do others think?  I always prefer to refer to other protocols (or
specific parts of them) rather than copying details from them.


>
> >    are, and are not, authorized to use a domain name for the "HELO" and
> >    "MAIL FROM" identities.  Loosely, the record partitions all hosts
> >    into permitted and not-permitted sets (though some hosts might fall
> >    into neither category).
> >
> > [MSK: That sounds confusing.  How is that possible?]
>
> Pass = permitted and Fail = not permitted.  The none, neutral, softfail,
> permerror, and temperror results are variants of "I don't know".  I don't
> know
> are the ones that are in neither category.  I'd appreciate someone
> providing
> recommended text to make this clearer.
>

You don't need to.  I originally read "neither" as "either".  It's fine the
way it is.


>
> > [MSK: As I found in the experiment survey, there are some domains that
> have
> > as many as 37 records at the domain level.  We might want to include any
> > other permanent references we can find that establish other TXT records
> > published at the domain level that might interfere with these
> guidelines.]
>
> If someone want to look into gathering a list, I don't object, but I'm not
> sure of the value.  Many/most uses are not standardized, so whatever we do
> will be guaranteed to be substantially incomplete.  I'm not sure what
> benefit a
> partial list would do.
>

The point of this would be to encourage implementers to harden their code
against receiving TXT records that have nothing to do with SPF.  As an
opposite example of sorts, ADSP, DKIM, VBR, and various other protocols
have all had to be hardened against the notion of asking for one of their
own TXT records and getting back an SPF record because of the use of DNS
wildcards since SPF pre-dates them.  DMARC will have to do this too.

We could reference those as examples of other protocols that use DNS TXT
records, and due to wildcarding, an SPF implementation needs to anticipate
getting data it doesn't expect.  In practice this is far less likely than
the opposite, but who knows what the future will yield.


>
> > 4.  The check_host() Function
> >
> > [MSK: I'm reading this on the assumption that "check_host()" is replaced
> by
> > "CheckHost".  Let's see if that works.]
>
> FWIW, I see what you're going after here and I think it 'works', but I
> don't
> think we should change it.  It's a distinction without a difference and the
> existence of references to both check_host() and CheckHost is documentation
> would be confusing.  I'm not worried about references withing 4408bis, but
> in
> other documents.
>

I commented on this above already.  This was just one example of dealing
with the concern.  There might be something much simpler we can do.


>
> > 4.3.  Initial Processing
> >
> >    If the <domain> is malformed (label longer than 63 characters, zero-
> >    length label not at the end, etc.) or is not a fully qualified domain
> >    name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
> >    check_host() immediately returns the result "none".
> >
> > [MSK: I suggest <domain> be defined in terms of whatever a legal domain
> name
> > is in [RFC5321], as amended by EAI, and further require that it be
> > fully-qualified.  In terms of I18N, we should just do what DKIM did to
> > handle this case.]
>
> What did "DKIM do"?
>

I'm referring to Section 3.5 of RFC6376, the definition of "d=".


> >    Note that records SHOULD always use either a "redirect" modifier or
> >    an "all" mechanism to explicitly terminate processing.
> >
> > [MSK: So there's a default, but people SHOULD NOT rely on it?  That seems
> > awkward.]
>
> SPF records are read by humans in addition to computers and they are often
> confused about this feature of the protocol.  There is an implicit result,
> but, as the "Zen of Python" says, "Explicit is better than implicit."  The
> default result is fine for the silicon based computers that read SPF
> records,
> but the carbon based ones do better if one specifies it.
>

We should say at the end "Although the latter is the default (specifically
"?all"), it aids debugging efforts if it is explicitly included."

(At least, I think it's "?all", but whatever it is should go there.)


> >    For several mechanisms, the <domain-spec> is optional.  If it is not
> >    provided, the <domain> is used as the <target-name>.
> >
> > [MSK: How are <domain-spec> and <domain> different?  Do we need them
> both?]
>
> Domain-spec is a defined ABNF term.  Domain isn't.  It's one of the input
> arguments to check_host()/CheckHost defined in section 4.1.  In the case
> of an
> SPF record like:
>
> example.com In TXT "v=spf1 a:mail.example.com -all"
>
> the domain is example.com, an input value applicable to the entire
> evaluation
> (see redirect= for a limited exception to this) while domain-spec is a
> property associated with a particular mechanism or modifer.
>
> I think they are distinct enough that we ought not try and combine them.
>

OK, then I think the right thing would be to say that they are
syntactically identical, but used in different parts of the evaluation
process.  In ABNF, something like this would do:

domain = <whatever the definition we want to use is>

domain-spec = domain
  ; syntactically identical to "domain", but used differently in the
evaluation

Dave, do you have any other insight here?


>
> >    If no CIDR-length is given in the directive, then <ip> and the IP
> >    address are compared for equality.  (Here, CIDR is Classless Inter-
> >    Domain Routing.)
> >
> > [MSK: Provide a reference to the definition of CIDR, and make sure
> > "CIDR-length" is defined there or use the term that document uses.]>
> >    If a CIDR-length is specified, then only the specified number of
> >    high-order bits of <ip> and the IP address are compared for equality.
>
> If someone knows/would look up the reference, I'd appreciate it.
>

RFC4632 is the current reference, but alas it contains no ABNF.


> >    Mechanisms after "all" will never be tested.  Any "redirect" modifier
> >    (Section 6.1) has no effect when there is an "all" mechanism.
> >
> > [MSK: Unless it appears before "all", right?]
>
> I'm not sure how well it's defined, but the spec at least hints in more
> than
> one place (and this is one of them) that modifiers are processed after
> mechanisms.  I believe that's the original intent and we ought to clarify
> things to explicitly say so.
>

I think that needs to be stated explicitly someplace, maybe an "overall
flow of the evaluation process" paragraph or something before it gets too
detailed.


> >    In hindsight, the name "include" was poorly chosen.  Only the
> >    evaluated result of the referenced SPF record is used, rather than
> >    acting as if the referenced SPF record was literally included in the
> >    first.  For example, evaluating a "-all" directive in the referenced
> >    record does not terminate the overall processing and does not
> >    necessarily result in an overall "fail".  (Better names for this
> >    mechanism would have been "if-pass", "on-pass", etc.)
> >
> > [MSK: Interesting.  Should we make a new name for it, synonymous with
> > "include", to facilitate introduction of a new name in a future version?]
>
> I don't see how we can do that without running into transition problems.
>  You
> can't publish both the new/old name as the new name would cause an error on
> existing implementations, so it couldn't be deployed as part of SPF v 1.
> This is one of the changes (like combining a/ip4/ip6) that would be good to
> consider in a future update that is free to worry less about backward
> compatibliilty.
>

I hadn't thought of a/ip4/ip6.  This makes me think a short appendix about
"notes for future revisions to SPF" or such might be a good idea.


>
> >    The "include" mechanism is intended for crossing administrative
> >    boundaries.  Although 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.  For
> >    example, if example.com and example.org were managed by the same
> >    entity, and if the permitted set of hosts for both domains was
> >    "mx:example.com", it would be possible for example.org to specify
> >    "include:example.com", but it would be preferable to specify
> >    "redirect=example.com" or even "mx:example.com".
> >
> > [MSK: I get that it's preferable, but I don't see why.  What difference
> does
> > it make?]
>
> It's a question of how the records expand and what results you get.
>
> example.com IN TXT "v=spf1 include: another.example.net ?all"
> example.com IN A 192.0.2.1
> another.example.net IN TXT "v=spf1 a -all"
> another.example.net IN A 192.0.2.200
>
> This will match for mail from 192.0.2.200 since the domain used in the
> evaluation of another.example.net's SPF record is another.example.net.
>  The
> result for mail from any other IP address is Neutral because include with
> just
> match/notmatch and the original SPF record's "all" mechanism is what
> controls
> the result if nothing matches.
>
> With include you are specifying you want another domain's authorized hosts
> to
> be authorized for your domain, but you still want to control the sender
> policy
> from this one (what result to give for things that don't match).
>
> Similarly, consider:
>
> example.com IN TXT "v=spf1 redirect=another.example.net"
> example.com IN A 192.0.2.1
> another.example.net IN TXT "v=spf1 a -all"
> another.example.net IN A 192.0.2.200
>
> In this case, mail from 192.0.2.1 matches the record since the check_host
> expansion is done using the orignal domain name, not the domain-spec of the
> redirect modifier.  The result is fail is the mail doesn't match.
>
> Redirect is much more like a common code element to be shared among
> records in
> a single ADMD.  You could control both authorized hosts and policy for an
> arbitrary number of domains from a single record.
>

Your example is a lot more illustrative than the paragraph I cited.
Perhaps a briefer summary of the difference would be helpful.  The concept
that speaks to me as a coder is something like "redirect never returns".
For example, in C, if you do this:

status = foo();
return status;

You have the choice to use the return value from foo() as it does, or to
insert code before the "return" to do your own thing and eventually return
your own result (which "include" does), while:

return foo();

This executes foo() and its return value is the return value of the caller
with no opportunity to do something different (which "redirect" does).


> >
> > 5.5.  "ptr" (deprecated)
> >
> > [MSK: Wouldn't it be easier to drop this section?]
>
> It's in use.  We can't drop it, only discourage it harder.
>

I would remove it to an appendix or something if we don't intend for it to
be part of the live protocol.

But this is another example of the question, which I think is still being
discussed, about whether it's appropriate to remove or at least deprecate
things.  The same survey that started the other argument finds 93 domains
using "ptr" out of over 150,000 reporting.  If it's okay do deprecate ptr,
then it's okay to deprecate macros.  And if it's deprecated and moving from
Experimental to Proposed Standard, I think this is a serious consideration.


> >    Check all validated domain names to see if they end in the
> >    <target-name> domain.  If any do, this mechanism matches.  If no
> >
> > [MSK: So if xebay.com is validated, and <target-name> is ebay.com, the
> > mechanism matches?  Surely not, but it illustrates that the definition of
> > this is weak.]>
>
> That's meant to be limited to subdomain matches.  We should improve the
> language.
>

Something about a "right-to-left label-for-label subset match" might do.


>
> > 5.6.  "ip4" and "ip6"
> >
> >    These mechanisms test whether <ip> is contained within a given IP
> >    network.
> >
> >    IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
> >    IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
> >
> >    ip4-cidr-length  = "/" 1*DIGIT
> >    ip6-cidr-length  = "/" 1*DIGIT
> >    dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
> >
> > [MSK: Can't this be simplified to just a "cidr-length", and the above
> three
> > dropped?  Really the only difference is that ip4-cidr-length can't be
> more
> > than 32 and ip6-cidr-length can't be more than 128.  So either say that
> in
> > an ABNF comment for each (and you could make the former be 1*2DIGIT and
> the
> > latter 1*3DIGIT), or simplify.]>
>
> Would that still allow one to use a:example.com/30/64?  That's legit now
> for
> dual homed IPv4/6 hosts.
>

My survey found zero dual-cidr-lengths in use.


>
> >    ip4-network      = qnum "." qnum "." qnum "." qnum
> >    qnum             = DIGIT                 ; 0-9
> >
> >                       / %x31-39 DIGIT       ; 10-99
> >                       / "1" 2DIGIT          ; 100-199
> >                       / "2" %x30-34 DIGIT   ; 200-249
> >                       / "25" %x30-35        ; 250-255
> >
> >             ; as per conventional dotted quad notation.  e.g., 192.0.2.0
> >
> > [MSK: Is there really not a reference for this syntax?]
>
> There probably is, but we didn't find it in 2005.  If someone can dig it
> up,
> I'll add it.
>

I actually can't find one either.  Pete or Dave, perhaps?


> > 7.  The Received-SPF Header Field
> >
> > [MSK: This should be updated as agreed (I think) to say implementations
> > SHOULD generate A-R and MUST NOT generate this, while they SHOULD be able
> > to parse this.]>
>
> We argued about this.  I agree that Section 7 should cover both Received
> SPF
> and Authentication Results.  I think it should also described how to
> create an
> Authentication Results header that has all the information found in a
> Received
> SPF header.
>
> I don't believe that there is an Internet interoperability point in
> preferring
> one over the other.  These are generated and consumed within an ADMD and so
> within that ADMD, they should use whichever works for them.  On that
> basis, I
> think it's reasonable to encourage adoption of Authentication Results by
> software developers so that ADMD administrators can choose.
>

Sounds good to me.


>
> >
> >    key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
> >
> >    key              = "client-ip" / "envelope-from" / "helo" /
> >
> >                       "problem" / "receiver" / "identity" /
> >
> >                        mechanism / name
> >
> >    identity         = "mailfrom"   ; for the "MAIL FROM" identity
> >
> >                       / "helo"     ; for the "HELO" identity
> >                       / name       ; other identities
> >
> > [MSK: Should "identity" be quoted in the "key" list?]
> >
> > [MSK: There are two paths to "key" generating "name": one direct, one
> > through "identity"]>
>
> Is this a problem?
>

I thought it was considered an ambiguous grammar in that case, and thus
"improper".

You should run this through a BNF checker too just to see if any bugs are
found.  There's one on tools.ietf.org someplace.


>
> >    "MAIL FROM" identity was checked, "envelope-from".
> >
> >    client-ip      the IP address of the SMTP client
> >
> >    envelope-from  the envelope sender mailbox
> >
> > [MSK: Suggest "the RFC5321.MailFrom address" or simply "the return-path"]
>
> There's a section at the beginning where we cover all the different names
> for
> mail from.  We ought to use this terminology from there on.
>

Yeah, using one throughout would be ideal.


>
>
> >    macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
> >
> >                       / "%%" / "%_" / "%-"
> >
> > [MSK: The "*delimiter" allows this: %{s.-+,/_=.+,..+.}  What would that
> > mean?]>
>
> Good question.  It's almost 1AM, so I'm not even going to try and figure
> that
> one out right now.  What does it mean?
>

My point is that the grammar allows it, and I'm not certain we want that.
What's the point of allowing lots of delimiters?  How would one apply more
than one?


>
> >       p = the validated domain name of <ip> (deprecated)
> >
> > [MSK: This makes me think we need to say somewhere what it means for
> this to
> > be deprecated.  When verifiers see it, for example, what should they
> do?]>
>
> Deprecated is defined early in the draft.
>

So it does; withdrawn.


>
> >    By default, strings are split on "." (dots).  Note that no special
> >    treatment is given to leading, trailing, or consecutive delimiters,
> >
> > [MSK: In input strings, right?]
>
> Yes.
>

So if the "delimiter" part of the ABNF is "+.", what does a parser do?
Break on +, then within those break on .?  Break on either (like strtok()
does)?


>
> >
> >    Macros MAY specify delimiter characters that are used instead of ".".
> >
> > [MSK: Isn't this redundant to the ABNF?]
>
> Yes, but so is a lot of the text.
>

I guess I'd like to keep that to a minimum.


>
> >    The "p" macro expands to the validated domain name of <ip>.  The
> >    procedure for finding the validated domain name is defined in
> >    Section 5.5.  If the <domain> is present in the list of validated
> >    domains, it SHOULD be used.  Otherwise, if a subdomain of the
> >    <domain> is present, it SHOULD be used.  Otherwise, any name from the
> >    list MAY be used.  If there are no validated domain names or if a DNS
> >    error occurs, the string "unknown" is used.  This macro is deprecated
> >    and SHOULD NOT be used.
> >
> > [MSK: There's probably not a better algorithm, but it's uncomfortable
> having
> > the "any name" part, because two evaluations of the same name could yield
> > different expansions.]>
>
> Multiple PTR names and how that can get confused are part of why this was
> considered unreliable and why I think deprecation is a good idea.
>

Let's add a sentence in there to this effect then.


>
> >    The "t" macro expands to the decimal representation of the
> >    approximate number of seconds since the Epoch (Midnight, January 1,
> >    1970, UTC).  This is the same value as is returned by the POSIX
> >    time() function in most standards-compliant libraries.
> >
> > [MSK:  When?  At time of evaluation?  At time of message receipt?  Some
> > other time?]>
>
> At evaluation.  It has to be.
>

Let's add that clause.


> > 9.3.  Mail Services
> >
> >    MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail
> >    services to third-party domains, such as sending of bulk mail, might
> >    want to adjust their setup in light of the authorization check
>
> > [MSK: I'm getting wary of the use of "domain" now, and in retrospect I
> > should've been looking at this throughout the document.  DNSDIR has been
> > known to get cranky about the use of that word when the specific context
> > isn't clear.  Did you mean ADMD here, or DNS domain name, for example?]>
>
> I can make this one clearer.  If there are others, let's address them.
>

That was the first one that got my attention.  When you post -04 I'll do a
quick pass looking for that word and see if I can spot any that need
massaging.


>
> >
> >    at least 20 seconds.  If such a limit is exceeded, the result of
> >    authorization SHOULD be "temperror".
> >
> > [MSK: Where are we these days on normative language in Security
> > Considerations?  I thought we currently didn't like it.]
>
> So did I, but I got pushback when I tried to move it up into section 4.  I
> think it does fit rather better there.
>

Pete or Barry?


>
> >    (Section 6.2), were generated by the sender policy published by the
> >    domain holders themselves.  As long as messages are only returned
> >    with non-delivery notification to domains publishing the explanation
> >    strings from their own DNS SPF records, the only affected parties are
> >    the original publishers of the domain's SPF records.
> >
> > [MSK: Reference for NDNs?]
>
> If someone could provide this, it would be appreciated.
>

 RFC3464, I believe.

-MSK