[ietf-dkim] Comment about SSP Draft - MX lookup requirement

[Hector Santos]

Overall, although I do have many comments about the SSP draft, there is 
really just 1 thing that sticks out.

Section 4.4, item 3:

  3.   The Verifier MUST query DNS for an MX record corresponding to
       the Originator Domain (with no prefix).  This query is made only
       to check the existence of the domain name and MAY be done in
       parallel with the query made in step 2.  If the result of this
       query is an NXDOMAIN error, the message is Suspicious and the
       algorithm terminates.

        NON-NORMATIVE DISCUSSION:  Any resource record type could be
        used for this query since the existence of a resource record
        of any type will prevent an NXDOMAIN error.  The choice of MX
        for this purpose is because this record type is thought to be
        the most common for likely domains, and will therefore result
        in a result which can be more readily cached than a negative
        result.

This just seems out out of place for DKIM/SSP.  The SMTP reality is that 
an MX may not be available and most production SMTP software will have 
logic or options for a specific NO MX rule:

       NO MX -> 1 or more A record lookup send mail attempts.

Also, even then, the SMTP software may be doing the MX lookup BEFORE the 
  DATA state which may pre-empts any need for an expensive DATA or 
bounce-attack potential POST SMTP operation.   Therefore, item 3 should 
be an OPTION logic and it should be noted that this may very likely be 
perform PRIOR to any DKIM data points are available.

How did this get in the SSP specs anyway?  I don't recall a "straw poll" 
for it.

We seem to have mixed to different "MAIL FILTER" concepts into one.

Unless we are outright claiming that all DKIM domains MUST have a MX 
record, I think this item should be revisited and hopefully removed. 
Systems are increasingly doing this in some kind of MX concept 
regardless of DKIM or SSP.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com