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

[Hector Santos]

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