ietf-clear
[Top] [All Lists]

[clear] Consensus on Multiple SRV RRs

2005-07-02 11:49:28
Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
[John Leslie wrote:]

The CSA spec shall be updated to state that domains MUST NOT publish
multiple version 1 (priority==1) CSA SRV records for the same HELO
string. Receiving SMTP servers MAY return a permanent error in response
to the HELO/EHLO if more than one is found.

... RFC 2821 says:

4yz   Transient Negative Completion reply
      The command was not accepted, and the requested action did not
      occur.  However, the error condition is temporary and the action
      may be requested again.  The sender should return to the beginning
      of the command sequence (if any).  It is difficult to assign a
      meaning to "transient" when two different sites (receiver- and
      sender-SMTP agents) must agree on the interpretation.  Each reply
      in this category might have a different time value, but the SMTP
      client is encouraged to try again.  A rule of thumb to determine
      whether a reply fits into the 4yz or the 5yz category (see below)
      is that replies are 4yz if they can be successful if repeated
      without any change in command form or in properties of the sender
      or receiver (that is, the command is repeated identically and the
      receiver does not put up a new implementation.)

So this last sentence would imply a 5xx response for misconfigured CSA SRV
records, and this tallies with common responses to bad MX records (if the
MTA software is paranoid enough to check them for RFC1918 addresses etc.).

The 4xx I referred to above can come from lower-level DNS problems that
prevent a DNS lookup from succeeding (bad delegation, etc.). The exact
meaning of "without any change ... in properties of the sender or
receiver" isn't totally clear because this kind of broken-DNS 4xx response
requires someone to fix something in order to be resolved. But if you
understand "properties" to be restricted to things that are directly
email-related (e.g. MTA software and configuration, MX records, CSA SRV
records) as opposed to incidentally related (e.g. DNS delegation) then I
think it makes sense.

   I tend towards the 5xx, because it's a situation which will require
human intervention: the extra SRV record is not in the least likely to
go away by itself.

   I also tend towards 5xx because 4xx errors usually require (e.g.) five
days before a human sees them.

   But regardless, we're talking about a MAY here; and I'd be quite happy
with an implementation which returned the error intermittently -- so
long as the problem is brought to the attention of a human being capable
of fixing it, we've done all we should.

   (Of course, programming this sort of intermittent response to cause
human action is rather more difficult if we must return a 4xx...)

--
John Leslie <john(_at_)jlc(_dot_)net>