ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RE: I think we can punt the hard stuff as out ofscope.

2007-06-09 10:59:09
Jeff Macdonald wrote:
On Sat, Jun 09, 2007 at 07:51:51AM -0700, Douglas Otis wrote:

The discovery process itself might provide a solution. For a message to contain a valid email-address, the domain of this address MUST locate either an MX or A record. The DKIM WG could strongly recommend A record discovery be deprecated, and that only MX records be used for discovery. Within a few years, it should be possible to obsolete use of A record discovery. An email-address would not be valid without an MX record. This would mean that policy placement adjacent to the MX record would be the only location any policy record would need to exist. In this case, the discovery process itself indicates whether or not the sub-domain is USED/UNUSED.

Are you referring to the process that some MTAs follow? For example, if
a MTA needs to deliver a message, it is suppose to find a MX for the
right hand side of the email address and deliver it to the eventual A
record (Hector's claim that some MX records return IPs confused me).

I was referring to MX expansion and how each DNS client within a SMTP client may behave. More below.

Some MTAs, when they don't find an MX record, just lookup an A record
instead and deliver to the resulting IP.

If that's the case, shouldn't the deprecating of A lookups when a MX
lookup fails be brought to the SMTP group?

Yup, and IMO, I can almost guaranteed the idea will be killed ASAP. I would vote against it.

I seriously doubt people will begin to screw around with their various retries logic. Plus, you are going to hear those who say MX is about inbound, not outbound and "Never The Twain Shall Meet."

What I was referring to was MX expansion. MX lookups return the hostnames, not IPs. When you perform MX expansion, you look at the A record per hostname. Each can return 1 or more IP addresses.

Depending on the DNS client you are using, it may or may not automatically expand the host names. How this is done varies by each implementation depending on their sending strategy. For our own SMTP product, our internal DNS client will expand them all and then grab the first X amount or all of them.

You can't really use the lack of A record for a SSP NOMAIL concept for the following reason:

Lets just use a large system for example, like YAHOO.COM:

        nslookup -query=MX yahoo.com

Non-authoritative answer:
yahoo.com       MX preference = 1, mail exchanger = a.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = b.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = c.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = d.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = e.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = f.mx.mail.yahoo.com
yahoo.com       MX preference = 1, mail exchanger = g.mx.mail.yahoo.com

Suppose that when your client begins to expand these, all except two return IP addresses.

Is that enough for this NOMAIL rule?

Or does this apply when no hostname can be expanded?

What if all of them are successful, but no connection can be made to any of the IP addresses? or maybe a certain amount?

Is that enough for this NOMAIL rule?

What each you can make a connection to all of them but they all return 55x at the greeting?

Is that enough for this NOMAIL rule?

I personally agree that each system should have a proper setup, but that is not guarantee in practice.

I recall many years ago how we gave sysops an option to use a very tight MX/A equation to quickly blacklist bad host systems.

This was almost immediately removed as it created more support headaches than it was worth.

People's systems do go down, DNS responses may not be there and we found that allowing retries to expire after 72 attempts, 1 per hour or 3 days. (defaults) reduce these support issues.

And this had nothing to do with small ISP/DNS providers, but VERY VERY VERY large ones as well. Just a few months back I was assisting my brother with his new SMTP setup for his new SOHO. He was having all kinds of strange DNS issues. At first, I just thought that his new DNS MX and hosting A records did not propagate through the network yet. But when resolution problems continued, I finally got in contact with this VERY VERY VERY large DSL/ISP/DNS provider on his behalf.

The answer was simple:

They were having DNS server problems and they didn't bother to them him to change his fixed DNS server IPs in his network setup. Once changed, he is running as smooth as silk.

These things happen.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>