ietf-clear
[Top] [All Lists]

[clear] Consensus on Multiple SRV RRs

2005-07-02 13:26:00
On Sat, 2005-07-02 at 16:48 -0400, John Leslie wrote:
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.

If there is a possibility of two RR appearing in a resolver due to a
record modification and some overlap in the TTL of old to new, then:

  451 Requested action aborted: local error in processing

would address this error and not require any intervention for the
problem to be resolved.

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

This allows for some overlap then.

   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...)

If it requires human intervention, then  you would be correct.  Is this
sure to be the case?  

-Doug