ietf-clear
[Top] [All Lists]

[ietf-clear] Revised CSV-CSA specification

2005-02-22 20:00:03
Richard Dawe <rdawe(_at_)messagelabs(_dot_)com> wrote:

In section five when talking about the Weight field of the DNS SRV
record, it is not specified what to do when encountering a Weight that
uses the reserved bits.

The Port field later says to ignore the reserved bits, since they're
meaning is unknown. Perhaps some similar text needs to be added to the
Weight field's text?

   IMHO, we were thinking that a receiving SMTP server SHOULD give an
error if any reserved bits are not zero.
] 
]    +--------------+----------------------------------------------------+
]    |   Bit Value  | Meaning                                            |
]    +--------------+----------------------------------------------------+
]    |       1      | Ignore Target: The domain name in the Target field |
]    |              | is a placeholder, and any IP addresses it resolves |
]    |              | to MUST NOT be used for authentication.            |
]    |       2      | Authorized: Any host with a valid claim to this    |
]    |              | name is authorized to send mail.                   |
]    |       -      | Other bit values are reserved for expansion and    |
]    |              | must be set to zero.                               |

   (Now that I look at it, I think that should be a capital-MUST...)

   There's a trade-off between ease of extension and assurance that bits
are not being used for (experimental) conflicting purposes. If we should
at some future time decide that something additional needs to be defined
within the Weight field, I believe we're quite concerned that its meaning
be absolutely unencumbered: thus we'd expect to bump a version number
(in the Priority field), and allow for publishing multiple SRV records
during a transition.

   I certainly recognize that the transition would be a significant
hassle, and frankly we don't expect to go there. But we _really_ don't
want to get into a situation in which CSV-CSA records are interpreted
in a vague, diverging way.

   The fundamental reason to have CSA at all is to give an unambiguous
statement that a particular sending SMTP server is authorized to do
what it's doing. We should be very careful to avoid leaving room for
a situation in which version-1 receivers think it's authorized while
version-2 receviers think it's not. :^(

   (If folks have in mind any actual expansions to this field, I'd much
rather see us reserve particular bits for particular functions, and say
that receiving SMTP servers SHOULD ignore those bits if they don't care
about that function.)

   The Port field is quite a different story. It is intended to be
reserved for assertions which need not have any effect on CSA processing
at all: thus, additional assertions may be added without any need to
bump a version number.

   

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