--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.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>