ietf-mxcomp
[Top] [All Lists]

Re: Alternative to TXT or new RR

2004-06-17 09:32:26

On Wed, 2004-06-16 at 22:27, Greg Connor wrote:
--Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:

Meng Weng Wong writes, about "what if there were no TXT":
I'm guessing an SRV lookup against DOMAIN.COM with a
reserved port number would return a domain name, something like
MARID-RECORD.DOMAIN.COM, and then something like

I'm pretty sure we'd be doing a SRV lookup for _marid._udp.<domain> and
then asking that server whether to fail/pass/... the message.

The entire SPF/CID/XML thing would never be published - the policy would
be executed by the same entity that chose the policy. Only the IP
address, email address and pass/fail/... result would cross the net.


Interestingly, SPF supports this mode of operation already, today:

 - A DNS request is sent to the domain the message claims to be from
 - The DNS response tells where to reach an authentication server via UDP
 - The receiver contacts the authentication server with a single UDP 
packet, including info the initial DNS response indicates is needed such 
as: MTA IP, Helo address, from address (complete or localpart only)
 - The authentication server responds with a one-packet UDP response saying 
approved or not.

The mechanism used to invoke this behavior is called "exists" and the UDP 
authentication server is....  A DNS Server :)


And No, this reply is not meant as a joke.  The exists: mechanism is there 
for a reason.  There are some policies that can't be readily described by a 
one-packet response.  For those unique situations, a second query might be 
needed, giving the server some additional info.  It also works well for 
situations where the domain owner doesn't want to reveal the complete 
policy (and prefers to answer questions one at a time) and cases where the 
policy might change on the fly (like a rate-limiting server that might 
answer YES for a questionable email/ip combination 10 times and then switch 
to NO, or many other cases where the domain owner wants more control over 
the individual yes/no decisions.

The exists: mechanism isn't there by accident... there are some cases where 
it is actually needed, just not the majority.  It's similar to DMP actually 
only a bit more flexible.  Some sites will need it for special purposes, 
and most will not.  If the first DNS reply packet is enough, great.  If a 
second request is needed, the first packet says where to go and what extra 
information is needed.

Is it possible to create a specialized new server that receives UDP packets 
and replies with UDP, to pass authentication info?  Sure.  Would it be 
substantially different from a normal DNS server?  The server might be 
custom, but the client doesn't have to be.  Implementing a custom server 
doesn't get around the one-packet size limit, unless you want to implement 
your own session-over-packet method to reorder and verify/retransmit 
missing packets, and if you need that you might as well use TCP.

If there is to be an authentication server used for mail, then 

http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt

defines this process and does not require parsing TXT packets to find
it, but instead uses a conventional SRV record.  This mechanism can
offer dynamic services and provide assurances about the person sending
mail independent of the mail channel.  Mail still works! : )

It seems absurd to suggest a rate limiting mechanism will be useful for
either an SPF or CID approach.  The only thing safely achieved would be
to mark mail as checked, but even that information would be prone.  Is
it logical to expect a receiving SMTP server to drop mail based on
cached information now claimed to be rapidly changing?  With most lists
being open (little of the mail will be dropped or blocked), mail will be
marked at the MUA and put into the "maybe" folder next to the "spam"
folder.  SPF and CID will not ensure mail came from any specific domain
as there would be no incentive to for such intensive checking to be done
in transit if it resulted in no benefit for the service provider.  ; (

-Doug