Re: So here it is one year later...

The MARID list has become a cesspool of misinformation and trolls.
For that reason, I have not been posting to it and I would encourage
others to ignore the "information" posted here.  The following post by
Doug Otis is an prime example of just how bad most posts here are.


In <[email protected]> Douglas Otis <[email protected]> writes:

> On Fri, 2005-01-28 at 04:20 +0100, Frank Ellermann wrote:
>> Douglas Otis wrote:
>
>> > applying a record against different algorithms than that
>> > intended when published is inherently deleterious
>> 
>> Indeed.
>> 
>> > Once again the algorithm changes and still this draft uses
>> > the same labels and record identifiers?  Classic.
>> 
>> This "new" draft is technically nearer to the last pre-MARID
>> "old" draft than draft-lentczner-spf-00 was.  The latter was a
>> rather quick hack salvaging all syntax improvements found here
>> (= mxcomp) after MARID was killed and the old draft expired.
>
> This draft is attempting to make significant algorithmic changes to the
> initial draft, as well as how these records are used.

Discussions about the SPF specification are best discussed on the
SPF-discuss mailing list.



> Some examples:
>
>    SPF clients MAY check the "HELO" identity by calling the check_host()
>    function (Section 4) with the "HELO" identity as the <sender>.  If
>    the HELO test returns a "fail", the overall result for the SMTP
>    session is "fail", and there is no need to test the "MAIL FROM"
>    identity.
>
> A test against HELO that goes from unknown, to not tested, to fail?
> This a change in algorithm, as is the hunt for alternative records,
> where a pass may not be based upon address compliance.  One wonders how
> macros are applied when the same check_host routine is recycled. 


This is not an example of changing semantics and/or algorithms.  As
pointed out by Frank, this is consistent with the pre-MARID
specification of SPF.  The problem is not that draft-schlitt-spf-00
changed things back, but that the IETF, via the MARID WG, allowed it
to change in the first place.


>    An SPF record published at the zone cut for the domain will be used
>    as a default for all subdomains within the zone (See Section 4.5.)
>    Domain owners SHOULD publish SPF records for hosts used for the HELO
>    and MAIL FROM identities instead of using the zone cut default
>    because the fallback requires additional DNS lookups.  The zone cut
>    default does reduce the need to publish SPF records for non-email
>    related hosts, such as www.example.com.
>
> Again, another change in algorithm.  This also means TXT RR placed at
> the zone apex may now be problematic as how it becomes applied and to
> which identity.  

This is not an example of changing semantics and/or algorithms.  As
pointed out by Frank, this is consistent with the pre-MARID
specification of SPF.  The problem is not that draft-schlitt-spf-00
changed things back, but that the IETF, via the MARID WG, allowed it
to change in the first place.


>    If no matching records are returned for the <domain;>, the SPF client
>    MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat
>    the above steps.  The <domain>'s zone origin is then searched for SPF
>    records.  If an SPF record is found at the zone origin, the <domain>
>    is set to the zone origin as if a "redirect" modifier was executed.
>
>    If no matching records are returned for either search, an SPF client
>    MUST assume that the domain makes no SPF declarations.  SPF
>    processing MUST abort and return "None".
>
> Yet again another change in algorithm isn't it?

This is not an example of changing semantics and/or algorithms.  As
pointed out by Frank, this is consistent with the pre-MARID
specification of SPF.  The problem is not that draft-schlitt-spf-00
changed things back, but that the IETF, via the MARID WG, allowed it
to change in the first place.


>    This mechanism matches if <ip> is one of the MX hosts for a domain
>    name.
>
>    MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
>
>    check_host() first performs an MX lookup on the <target-name>.  Then
>    it performs an address lookup on each MX name returned.  The <ip> is
>    compared to each returned IP address.  To prevent DoS attacks, a
>    limit of 10 MX names MUST be enforced (see Section 10).  If any
>    address matches, the mechanism matches.
>
> A limit change is an algorithmic change that could not be possibly
> foreseen by earlier publishers.  Who is responsible when their mail goes
> missing?

While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice.  As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit.  This change only effects abusers and
misconfigured systems.


>    Note regarding implicit MXes: If the <target-name> has no MX records,
>    check_host() MUST NOT pretend the target is its single MX, and MUST
>    NOT default to an A lookup on the <target-name> directly.  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.
>
> Would this be yet another algorithm change?

No.  This has *always* been the case.

>   In pseudocode:
>
>    sending-domain_names := ptr_lookup(sending-host_IP);
>    if more than 10 sending-domain_names are found, use at most 10.
>    for each name in (sending-domain_names) {
>      IP_addresses := a_lookup(name);
>      if the sending-domain_IP is one of the IP_addresses {
>        validated-sending-domain_names += name;
>      }
>    }
>
> Yet another change to the algorithm that introduces a new limit.

While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice.  As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit.  This change only effects abusers and
misconfigured systems.


>    Pseudocode:
>
>    for each name in (validated-sending-domain_names) {
>      if name ends in <domain-spec>, return match.
>      if name is <domain-spec>, return match.
>    }
>    return no-match.
>
>    This mechanism matches if the <target-name> is either an ancestor of
>    a validated domain name, or if the <target-name> and a validated
>    domain name are the same.  For example: "mail.example.com" is within
>    the domain "example.com", but "mail.bad-example.com" is not.
>
>    Note: Use of this mechanism is discouraged because it is slow, is not
>    as reliable as other mechanisms in cases of DNS errors and it places
>    a large burden on the arpa name servers.  If used, proper PTR records
>    must be in place for the domain's hosts and the "ptr" mechanism
>    should be one of the last mechanisms checked.
>
> One wonders how this mechanism is to be discouraged?

By saying, in the spec "this mechanism is discouraged" and by having
the various SPF wizards not generate it.


>    SPF implementations MUST limit the number of mechanism that do DNS
>    lookups to at most 10, if this number is exceeded, a PermError MUST
>    be returned.  The mechanisms that count against this limit are
>    "include", "a", "mx", "ptr", "exists" and the "redirect" modifier.
>    The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and
>    therefore do not count against this limit.  The "exp" modifier
>    requires a DNS lookup, but it is not counted as it is used only in
>    the case of errors.
>
>    When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
>    there MUST be a limit of no more than 10 MX or PTR RRs looked up and
>    checked.
>
> I would also describe this as an algorithmic change that could not have
> been anticipated by the publishers.

While this is, indeed, a change from the last pre-MARID SPF spec, this
limit has been in place in my libspf2 implemenation since long before
MARID existed, and hence is an existing practice.  As discussed *many*
times on SPF-discuss, I can not find *any* legitimate emailers who
have come close to this limit.  This change only effects abusers and
misconfigured systems.


>                                      And the following regarding
> forwarding:
>
>    There are several possible ways that this authorization failure can
>    be ameliorated.  If the owner of the external mailbox wishes to trust
>    the forwarding service, they can direct the external mailbox's MTA to
>    skip such tests when the client host belongs to the forwarding
>    service.  Tests against some other identity may also be used to
>    override the test against the "MAIL FROM" identity.
>
>    For larger domains, it may not be possible to have a complete or
>    accurate list of forwarding services used by the owners of the
>    domain's mailboxes.  In such cases, white lists of generally
>    recognized forwarding services could be employed.
>
> Some other Identity?  Generally recognized forwarding services?  Would
> this open the door for abusing the typical alma mater?  This is a mess.

As noted in Section 9, this is is non-normative.  If you don't agree
with what is said, you are free to do anything you want.  This is just
for your information.



> This draft at long last recognizes wildcard labels are a problem.  Why
> not also recognize a need to _change_ revisions when algorithms change
> and the need for a standardized prefix rather than a record tag?  These
> are rather significant changes being made, why suggest otherwise?

The section on wildcards was added as part of the MARID process and
remained in the draft-schlitt-spf-00 version because it is useful.
The changes to the algorithms that were added as part of the MARID
process have been removed.  Changes to the algorigtms from the
pre-MARID SPF specs have all been implemented by at least one system
and have been checked, via wide surveys, that they do not conflict
the install base of legitimate SPF records.


I find it very amusing that you are now complaining about the process
limits being a change, since you have long complained about the lack
of process limits in previous versions of the SPF spec.  


-wayne