RMX+SPF melt

On Sat, Oct 04, 2003 at 02:56:18PM -0400, Meng Weng Wong wrote:
> 
> SPF: Falls back to EHLO/HELO domain name only when envelope sender is
> null.  If the EHLO/HELO domain name is not an FQDN, SPF returns
> "unknown" and leaves policy decisions to the discretion of components
> elsewhere in the MTA.
> 

That's a pretty good method to solve the empty sender address
problem. 

So for the mapping of ESA (envelope sender address) to DNS we could
do it like these examples:

<>       ->     _mta@HELONAME   ->[LOOKUP]
<john>   ->     john@xxx        ->[LOOKUP]
                where xxx is a default of the receiving MTA

<john@>  -> as above?

<@domain> -> ???

<john@onecomponent>  -> append a default component or discard?


<[email protected]>  -> [LOOKUP]








> Domain owners may specify a variety of lookup mechanisms: they include
> "mx", "host", "cidr", "include", and "spf".

Having a list of lookup mechanisms in DNS which is processed by
some interpreter at the querying MTA is similar to RMX. 

I propose to melt this together into a general list of lookup
mechanisms and to leave it to the decision of the domain admin whether
he likes to use spf, acl or whatever. 


About the RMX encoding I meanwhile came to the conclusion that both
a TXT entry and a new RR have their advantages and disadvantages. 
I'm currently thinking about simply having them both:

If a client is performing an RMX lookup, it does an ANY query
on _rmx.DOMAIN. From all records received it always interprets all
TXT records with textual representation and RMX records with
binary encoding. With this method, people can start to use it
immediately with the existing TXT records, and can move to 
RMX RR once new versions of the DNS software have been installed.

regards
Hadmut