On Fri, 4 Jun 2004, wayne wrote:
In <EB3FF3D8-B5E5-11D8-88FE-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
So he had an interesting idea. He suggested that instead of looking
for the MARID record in the domain of the sender, look for it at the
MX target of the sender. This solves his problem since his DNS zone
is the MX target. This also leads to a solution to the wildcard issue.
So, example.com has MX records:
example.com MX 1 foo.com
example.com MX 1 bar.com
Now, are you suggesting that the MARID record would have to be placed
in *both* foo.com and bar.com? What if they conflict? What about
mail servers out there that depend on the falling back to A records
and have no MX records?
I agree with all points made by Wayne.
Additionally I also would caution that for many ISPs same incoming server
handles email for thousands of domains and thereafter retransmits it to
appropriate client. But the client may not be actually sending email
through that same isp and may have their own outbound email servers
(common for T1/SDSL corporate clients). In such case each client would
have different set of _marid records while lookup is expected on one
default _marid.food.com record.
Similar and very common scenario is that even if client has their own mail
server often ISP would still provide backup mx service and their server
would be listed as last one in the list of MXs. Also there are well known
case when company outsources spam filtering and their MXs are entered in
dns but after processing the email is sent to list of "real" client
incoming mail servers using hidden dns record.
There is however a possible use of MX records that can solve wildcards
although I'm not sure if I like it or not ...
What could be done is that for MX listed hosts, there is created _marid
dns subzone and under that subzone there added actual domain that we're
querying on. i.e. if we have kudos.example.com, the first check is for
MX on kudos.example com which may possibly be wildcard from example.com:
$ORIGIN .
*.example.com. MX 1 foo.com
*.example.com. MX 1 bar.com
Now we check on kudos.example.com._marid.foo.com and for that both
foo.com and bar.com would have to have _marid subzones (potentially
specify that only lowest number MX record needs to have this). There
they could have to have additional dns record like:
$ORIGIN foo.com.
example.com._marid IN NS dns1.example.com.
and dns1.example.com would then have:
$ORIGIN example.com._marid.foo.com.
kudos IN TXT ...
Or they could even have
$ORIGIN example.com._marid.foo.com.
* IN TXT ...
The above wierd complex scenario would allow ISPs to handle different
situations and setup different dns records depending on what client domain
it is and when necessary and required to allow for example.com administrators
to handle MARID records for their domain directly. However if there are
multiple different MX servers and we don't check the lowest one (or if
MX priorities are all the same) then potentially bar.com would also need
to be checked and that means record needs to be duplicated. But its
possible to use CNAMEs to handle all this:
$ORIGIN example.com._marid.bar.com.
kudos IN CNAME kudos._marid.example.com.
$ORIGIN example.com.
kudos._marid IN TXT ...
On the other hand if email is not outsourced in such complex way, which is
probably majority of cases, then there would be direct record like:
$ORIGIN foo.com.
*._marid IN TXT ...
The above is almost what Andrew Newton originally meant. Except to really
have wildcards work we'll have to have most people who setup _marid records
to use them (i.e. *._marid :) and for people who do want wildcards they
have rather complex way in entering this into dns correctly depending on
how their email is outsourced.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net