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

From: Hector Santos <[email-masked]>
Date: Fri, 02 Nov 2007 11:30:45 -0400

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

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Thu, 1 Nov 2007 12:57:31 -0400 (EDT)

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

Hector, 

As the text states, the above test does not require that the MX
record exists. It just requires that *something* exists. As long
as something exists, the result of MX lookup will be "no data" or
an MX record, but it won't be NXDOMAIN.

	Wietse

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Nov 2007 11:03:36 +0100

On Thu, Nov 01, 2007 at 12:57:31PM -0400,
 Wietse Venema <[email-masked]> wrote 
 a message of 38 lines which said:

> As long as something exists, the result of MX lookup will be "no
> data" or an MX record, but it won't be NXDOMAIN.

Perfectly right but one should note that some broken DNS servers reply
with NXDOMAIN when they should not. Yes, they are completely broken
but they exist.

Example:

% dig MX ns.yp.to

; <<>> DiG 9.3.4 <<>> MX ns.yp.to
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59696
                 
NXDOMAIN but the domain exists:

% dig ANY a.ns.yp.to
...
;; ANSWER SECTION:
a.ns.yp.to.             259200  IN      A       131.193.36.25
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 6 Nov 2007 13:47:41 -0000

>a.ns.yp.to.             259200  IN      A       131.193.36.25

This particular case happens to be misconfigured glue; the only place
where a.ns.yp.to exists is in the servers for to., not yp.to.  That's
typical of this kind of breakage.

A reasonable question is in how many cases does such a domain want to
send or receive mail.  I would be surprised if the number were greater
than zero; I would be astonished if the number were large enough to
care about.

Every spec is misimplemented somewhere.  If you make perfect
implementations of something a prerequisite, you'll never be able to
do anything.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.