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