ietf-mxcomp
[Top] [All Lists]

Re: Using MX as the pointer to the other RR

2004-06-04 08:54:20

This is also an issue for Email Service Providers (ESPs) that provide hosted outbound email. Very often we do not control their DNS directly and find that coordinating DNS changes with clients can be difficult and error-prone (due to humans involved in the process, not technical challenges). Anything that could move that responsibility from our client to us is a significant benefit and will assist adoption.

~Josh

-----Original Message-----
From:   Nate Leon [mailto:nleon(_at_)mailfrontier(_dot_)com]
Sent:   Thu Jun 03 22:47:00 2004
To:     MARID WG
Subject:        RE: Using MX as the pointer to the other RR


This was raised (probably by the same guy :-) at the SPF BOF.  Suresh
Ramasubramanian from Outblaze strongly echoed his sentiment.  I didn't
hear any disagreement.  More work for implementers, but interesting.

Nate



-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Andrew 
Newton
Sent: Thursday, June 03, 2004 10:14 PM
To: MARID WG
Subject: Using MX as the pointer to the other RR



At the INBOXEVENT, I had an interesting talk with a gentlemen working for an email hosting provider. His company hosts email but rarely DNS for their customers (the split was something like 2,000 domains that they host vs. 65,000 that are customer hosted). As I recall, there are a couple of spam-filtering companies that do this too (MX redirection). His comment was that it is very difficult for them to get the customers to correctly add/change MX records and fears that a MARID record would be much more difficult.

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.

Comments?

-andy