Re: design specifics --- the config label

Meng Weng Wong wrote:
> 
> On Fri, Oct 03, 2003 at 11:56:38AM -0400, Alan DeKok wrote:
> |
> |   It looks like there is significant overlap between the proposals in
> | terms of goals and limitations.  This means that we should quickly be
> | able to come up with a unified proposal.
> |
> |   I would like to have a rough draft of a unified proposal by the end
> | of next week.
> 
> Does anyone have an objection to doing the config label?

The same objections that I have to TXT records, in general, for these
proposals:

* Potentially very large DNS responses.
* Having to search multiple TXT records in the response to find the ones
	you're currently interesting in.
* Complicated syntax's that the MTAs need to be taught how to parse.

> The thing that returns "permit:mx; permit:spf; permit:host=foobar.com;
> permit:cidr=special-list.foobar.com; deny:default".

Shouldn't ``deny:default'' be implied?

> If not, shall we use config._smtp_client.DOMAIN label or something else?
> 
> Any comments on the syntax of the above?

The protocol need to be simple to implement in the MTA. You seem to be
suggesting something that requires a lot of lookups and other work to
answer the question "Is this IP address permitted to claim some association
with this domain name?". MTAs will need to determine the answer to that
question for every message and/or SMTP session; it must be easy, fast,
and economical for busy MTAs to determine.

> If we're going to do CIDR in TXT, I believe Hadmut has spent the most
> time thinking about those issues.

I still believe that CIDRs and wildcards that indicate that the IPs are
associated with the domain name are an invitation for spammers and lazy
(over worked) administrators to designate overly large ranges of IPs as
associated with a domain name.

WARNING: Alternate proposal for the RMX/DMP/SPF/Vixie bookkeeping ahead.

Unlike checking the HELO parameter, checking the sender domain needs to
handle the case of more that one outbound sending administrative
organizations (ISPs). And the domain owner may not be reasonably able
to implement dynamic DNS updates from the sending administrative
organizations.

I propose the following (using the notation from the DRIP document.

Domain owners implement the following "mail delegation" records that
point to the list of authorized outbound providers for the domain.

sources._email_.${DOMAIN}.		IN	PTR	${PROVIDER1}
					IN	PTR	${PROVIDER2}

Each outbound provider lists the IPs that are authorized to send mail
(for one or more domains) using the same DNS method that DRIP uses;
only in the ``senders._email_'' space instead of the ``relays._email_''
space used by DRIP.

${IPS}.${IPV}.senders._email_.${PROVIDER1}.	IN	${TYPE}	${IP}

The ${PROVIDER*} domain name would likely be something like:

	pool7.cust.${ISP}

This proposal is easy for MTAs to implement, domain name owners to
implement, and sending administrative organizations to implement. It's
fast, the number of lookups is two (best case). Parsing the lookup
results is very simple.

> Who has experience doing RFCs?  I believe there's an XML formatting
> scheme but I don't know much more.

http://xml.resource.org/

> We could start collaboratively editing a document on a Wiki somewhere.


Raymond S Brand