ietf-mxcomp
[Top] [All Lists]

RE: Draft Charter

2004-03-16 14:55:48

At 12:21 PM -0800 03/16/2004, Hallam-Baker, Phillip wrote:
Given that this is the charter lets try to avoid all use of terms
that are considered contentious by anyone, in particular 'policy',
'authorization' etc.

Sadly, I think this would leave us with no terms at all.  I think we must
use some of the technical terms of the trade here.


It would be useful for Mail Transfer Agents (MTAs) implementing
message acceptance restrictions to be able to confirm that
information provided by peer MTAs' is consistent with a description
of the configuration of the purported origin.

"is consistent with a description of the configuration of the purported
origin" seems to me personally to be too vague.  We're actually
aiming at something fairly specific, not at a general purpose
descriptive RR.  To take MX records as an example, they mean, essentially,
"you can deliver mail to this domain at this host".  The question
it answers is "where do I send mail intended to reach this domain?
MX record data could have been part of a record that was much
more general, but it got pinned down to a specific function and it
works pretty well.  The key issue here is getting the question that
needs to be asked right, so we can specify the record answering
the question well.

One way of asking the question might be "has the network or domain
associated with this mail exchange listed this MTA in the DNS as being
able to take this action"?  In everyday English, "does this domain
list this host as able to act as an outbound mail server?" is one question
that falls under that general rubric.  That may not be the right question, but,
in my opinion, the question we answer needs to be at about that level of
specificity to be really useful.  Note that we don't need to get this question
right in order to specify how an MTA uses it; we need to get this question
right so that the DNS can store an answer, rather than a free-form description.
(And none of this means, of course, that the  receiving MTA will make its
decision solely based on the listing--it is information it uses to make
its determination.)

Here's another shot, striking the "implementing message acceptance"
and describing things slightly more from the "what gets stored" side
than the "how it gets used side.
++++++++++++new++++text+++++++++++++++
It would be useful for those maintaining domains and networks
to be able to specify that individual hosts or nodes are authorized
to act as MTAs for messages sent from those domains or networks.
This working group will develop a DNS-based mechanism for
storing and distributing information associated with that authorization.
The primary current use case for this facility is to allow recipient
MTAs to confirm that peer MTAs' actions are authorized by
specific domains or networks.  This will help combat a certain
class of domain forgery common in spam.  The solution chosen,
however, should be generally useful for others which might
check this authorization data.

+++++++++end++++++++++++++++++++++++++


<Prev in Thread] Current Thread [Next in Thread>