Dear Tarun,
> The issue of technical problems cropping up due to this also looks
> exaggerated to me. Clearly, any danger to SMTP servers can not be a concern
> as they would probably add wildcards for "A" type record and not "MX"
> records.
I can't understand the full impact of this problem because I'm not clear
what NetSol are doing. But based on my partial understanding of the NetSol
modifications, I feel that wildcard "A" records too will cause problems.
All MTAs on the Internet are supposed to search for "MX" records first,
and if no "MX" records exist, search for "A" records, and then actually
_deliver_ to those records. This much I am quite confident about; I've
been hacking Sendmail configs for more than a decade now.
Therefore, let's see what the impact is in the old and new scenarios:
1. If the MTA makes a DNS lookup and doesn't get back any response, it
retains the mail in the outbound queue, for retry. No change in the
new scenario.
2. If the MTA gets a confirmed reply from the DNS query, giving "MX"
records, it tries delivering to the "MX" servers in sequence and
retains the mail in queue if it can't get a connection. This too
will not change in the new scenario.
3. If the MTA gets no MX records, but gets a confirmed "A" record, it
will try delivery to this server. If it cannot connect to this server,
it retains the mail in its queue for later retry. If it connects to
this server, and succeeds, well and good. If it fails, it bounces
the mail. No queueing here.
THIS IS WHERE the change will probably come. In the old scenario,
for valid domain names (e.g. typos), if the recipient's DNS server
was slow/dead, then the DNS query would time out, and the MTA would
try A record query. That too would time out, and the mail would
remain in the outgoing queue.
In the new scenario, the sending MTA will try MX record, get no
response, then try A record, get the wildcard catch-all A record,
and try opening an SMTP connection to it. This will either fail at
the connection stage or the (catch-all) recipient server will return
an error after looking at the MAIL-FROM and RCPT-TOs. In either
case, the sending MTA will bounce the mail back, not keeping it for
retries later.
I'm not 100% certain that my explanation is correct, but this seems
okay.
> Can somebody more knowledgeable enlighten me on what kind of things I can
> expect to break because of this from a system administration point of view
> and how can they be repaired.
I don't see how this can be repaired. If your users are sending mail to,
say, idbi.co.in (a notoriously slow mail receiving server, BTW), and
their DNS responses time out, your users will get their mails back
immediately as bounces. Similarly, if someone from outside tries to
send mails to your domain, and your DNS server is a bit slow, then the
sender will get his mails back immediately, and your users (the intended
recipients) will never know that a trivial transient error caused incoming
mail to bounce.
Oops: technically, idbi.co.in is an incorrect example, this malaise will
not affect the country-specific domain hierarchies. (Or will it?)
Comments on the correctness of my explanation invited. I need to know
how right/wrong this is. (Technically, not ethically or politically,
please.)
And on a more conceptual note, I feel that this modification, if I've
understood correctly, is plain bad engineering. (I'm not referring to the
politics and ethics here; those are not subjects I would like to debate at
this point.) I think that one of the important conceptual contributions
of the relational database model is the incorporation of a NULL value as
a legit value for a cell in a table. Ditto, the NaN ("not a number")
bit-pattern for IEEE standard floating point representations. It is
important that an error status or a no-data status be made to look
clearly different from legit values. This is what I understand as a
necessity for good engineering design. A global wildcard "A" record
violates this.
Shuvam
_______________________________________________
ilugd mailing list
[EMAIL PROTECTED]
http://frodo.hserus.net/mailman/listinfo/ilugd
