Re: First draft of the "discussion" paper.

Alan DeKok wrote:

> Working Group: Forces                                November 3, 2003

Should be changed to either "Research Group: ASRG" or to "Network 
Working Group" per RFC 2223.

>    When published, it will be substantially similar to the SPF proposal,
>    which is in turn based on the previous proposals; Vixie, RMX, DMP,
>    DRIP, DSProtocol, SPF.)
> 

Will the MTAMARK proposal will become relevant in any way?

> 
> 2.1.1  Why does forgery exist?
> 
>    Forgery exists because there is no method within SMTP to discover or
>    prevent it.  The protocol was designed at a time where security was
>    not an issue.  Efforts have been made since the publication of the
>    SMTP specifications to block forged e-mails by requiring the sender
>    address domain part to be resolvable.  That method provides
>    protection from e-mails with non-existent sender domains, and indeed,
>    for some time it blocked many spam e-mails. However, once attackers
>    and spam senders began to abuse existing domain names, that method
>    was rendered ineffective.
> 

Should we include a statement on Verisign's SiteFinder here as well or 
not to bother?


> 
> 2.1.2  Why prevent domain forgery, instead of end-user forgery?
> 
>    We propose to discover and prevent forgery of domains, rather than
>    forgery of end-user identities, because there are fewer active
>    domains than users.  While domain-name registries claim to have
>    registered hundreds of millions of domains, most of those domains are
>    inactive.  Statistics from anti-spam organizations indicate that
>    there are only a few hundred thousand MTAs which persist from year to
>    year.  These MTAs are the entities which are best used to address the
>    spam problem.
> 
>    (Ed.: The following paragraphs may not be appropriate for this
>    draft.)

I agree, however they may be suitable for the future in discussions of 
other relevant solutions and proposals.

> 
> 2.4 Limitations of the Proposal
> 
>    As this proposal examines a sub-set of the fields of SMTP, it has
>    certain limitations.  It does not prevent "authorized" abuse, such as
>    spammers registering a domain, and publishing LMAP information for
>    it.  It does, however, make such abuse accountable, and thus far
>    easier to track.

I would add to this that "This proposal does not seek to stop spam, 
rather it is another weapon in the arsenal that reduces the spam problem 
in combination with other solutions."

> 
> 4.1.3 Requirement 2.3, Unencumbered
> 
>    LMAP is not encumbered by any restrictions that we are aware of.

This section is mainly for IPR issues. HOWEVER, the author of SPF is 
considering a patent according to:

http://spf.pobox.com/misc.html

This needs to be clarified.

> 
> 5.1.1 Factor 4.1 (1), Adoption Effort
> 
>    The adoption effort to publish for LMAP for domains is limited to
>    updating TXT records in DNS.  We expect that administrators for many
>    domains can create this information by following a few simple recipes
>    for common situations, such as:
>  
>         a) permitting any IP address to claim association with that
>         domain,
> 
>         b) permitting only the existing MXs for the domain to claim
>         association,
> 
>         c) permitting only IPs within a particular network or networks
>         to claim association.
> 
>    More complex configurations will require more work by the domain
>    administrator.
> 
>    LMAP currently requires no changes to existing DNS implementations.
>    In the future, if the LMAP information is published in a new DNS
>    record, then implementation changes may be required.
> 
>    For recipient MTAs, LMAP requires that the implementions be upgraded
>    to query LMAP records, parse them, and then perform decisions based
>    on the combination of returned information and local site policy.
>    Earlier variants of the protocol [SPF] have been implemented in some
>    of the widely used MTAs, so we believe that this barrier to adoption
>    is low.
> 
>    The site policy for recipient MTAs is also expected to commonly
>    follow simple recipes, such as:
> 
>           a) when no LMAP record is found, behave in the same manner as
>           previously, when LMAP was not implemented,
> 
>           b) follow the directions of the LMAP response for a domain,
> 
>           c) reject all mail from domains which do not have LMAP records
> 
>    More complex configurations will require more work by the domain
>    administrator.

What is needed to be addressed here is the fact that until most people 
start publishing LMAP records, a receiving MTA cannot use option (c) for 
fear of blocking legitimate email.

Yakov