Marshall Rose
<mrose+internet(_dot_)ietf(_dot_)mxcomp(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
wrote:
On May 13, 2004, at 05:53, John Leslie wrote:
[Marshall Rose wrote:]
a clarifying question: earlier in your message when the MARID RR is
described, there is no mention of IP addresses embedded in the RR. (or
perhaps there was and i missed it).
I was intentionally vague, not wanting to get bogged down in syntax
if it could possibly be avoided.
However, the inspiration (as I mentioned) was Dave Crocker's CSV
proposal, which uses SRV records, in which the RR contains a "target"
domain name which refers to one or more A(ddress) records. DNS servers
automatically return the IP addresses as "additional" data.
i wasn't thinking this was syntax. what i'm trying to understand is
what "objects" are stored in the RR, not how they're encoded...
Please understand that I intend to be as syntax-agnostic as possible:
any syntax included in this response is illustrative only.
For "the MARID record", I envision a SRV-like record including:
- a domain string which leads to IP address(es) being returned, one of
which hopefully matches the IP address of the sending MTA
- a count of IP addresses or other method to indicate whether the
returned list of IP addresses is the entire set of known- or believed-
good IP addresses for HELO
- a number (possibly even a multi-dimensional number) defining the
MARID level, meaning <hands=waving> the version of the MARID spec
being followed by that domain plus possible flags showing options
supported </hands>
- one or more identifiers of reputation services recommended by that
domain to vouch for their policies and administration of MTAs.
(This doesn't actually fit in a SRV record: if that path is chosen,
this would have to fall in a separate record.)
- a text string for expansion options to be defined later. (Likewise.)
I intend that "the MARID record" shall be inserted at the subdomain
level matching the HELO/EHLO string, and at any subdomain for which
the management of the sending MTA may wish to support MARID checking
when it appears as the right-hand side of an email address.
From whatever subdomain the MARID record may be placed at, I intend
a subdomain named "_HELO" (or any other string the WG may prefer) to
include regular PTR-like records in arrangement similar to in-addr.arpa
to return strings indicating which of four sets an IP address falls
into. I definitely expect DNS records there to include wildcards.
I intend a separate subdomain named "_MAILFROM" (or whatever) to
include the same kind of records. (If DNS maintainers want these
two subdomains to reflect identical information, that's easily done
in zone files, e.g.)
A single DNS query would be done to the appropriate subdomain to
resolve the IP address of the sending MTA in either case. (This is
necessary for certain cases of the HELO check where the original
MARID query does not return that IP address automatically or does
not return a complete list adequate to determine that the IP address
in question is _not_ authorized.)
one of the things that the 30% solution has going for it is that it
concisely lists whats in the RRs, what the operands are and what the
operations are. it would be helpful in understanding the 40% solution
if it was similarly organized.
I perfectly willing to (try to) work with Dave Crocker and anyone
else interested in fleshing out the details;
In fact, I am corresponding with Dave Crocker. No guarantees...
but it was my understanding that we were planning to pass semantics
to DNS experts who would do that kind of work. Is that still part of
the game plan?
i don't think we're talking about semantics. i look at the 30% proposal
and in one screen i understand exactly what the inputs and outputs are
and how to evaluate the function in between. there isn't any semantics
there, they aren't needed. i can't say the same for the 40% proposal.
there isn't a concise list of the inputs and outputs.
Let's try (though I must resort to syntax):
At HELO/EHLO:
{ Query for SRV at "_SMTP._TCP.<HELO string>"
Response:
- <list of IP addresses>
- count of IP addresses believed good
- MARID level supported
- count of suggested reputation services
- count of extension strings
if ( <IP not resolved as good or bad> )
{ Query for PTR at "<IP encoded>._HELO._SMTP._TCP.<HELO string>"
Response:
- string denoting known-good, believed-good, unknown, or believed-bad
or
- error "no records found" (meaning "unknown")
}
Query for PTR at "_REP._SMTP._TCP.<HELO string>"
Response:
- <domain-name of reputation service> (any number of these)
}
At RFC2821-MAIL-FROM:
{ Query for SRV at "_SMTP._TCP.<MAIL-FROM domain>"
Response:
- <list of IP addresses>
- count of IP addresses believed good
- MARID level supported
- count of suggested reputation services
- count of extension strings
Query for PTR at "<IP encoded>._MAILFROM._SMTP._TCP.<HELO string>"
Response:
- string denoting known-good, believed-good, unknown, or believed-bad
or
- error "no records found" (meaning "unknown")
Query for PTR at "_REP._SMTP._TCP.<MAIL-FROM domain>"
Response:
- <domain-name of reputation service> (any number of these)
}
The queries at MAIL-FROM should not be necessary if the HELO
check shows known-good IP and a trusted reputation service vouches
for the sending MTA to support your desired MARID level.
The list of IP addresses returned for the SRV query at MAIL-FROM
should not be used to verify the bounce address. Instead the PTR
query should always be done.
Expansions for RFC2822 checking are out of scope right now.
In all cases, queries are to your local resolver, which is
expected to cache replies it receives from other hosts.
--
John Leslie <john(_at_)jlc(_dot_)net>