[ On Monday, September 17, 2001 at 11:37:53 (-0400), Michael Richardson wrote: ]
> Subject: Re: [Exim] DNSsec records and exim
>
> Greg> If you are using that name in either MAIL FROM: or RCPT TO:
> Greg> parameters
> Greg> you should probably keep an MX for it....
>
> Why?
>
> An A record can be delivered to. Some suggest that this wasn't the original
> intention (no MX == no email), but it is how the spec is.
Why? Why not? Just because some 16-year old, non-standards-track RFC
that was explicitly written only to provide backwards compatability for
the sake of all the dead-head sticks-in-the-mud people who weren't
adopting DNS quickly enough says you don't have to doesn't mean you
shouldn't.
Modern RFCs are a little less forgiving. (Not that I personally
consider the RFCs to be the final word and to be written in stone, mind
you! ;-) Eg. from RFC 2821:
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
[[ concerning only HELO/EHLO and POSTMASTER ]]
5. Address Resolution and Mail Handling
Once an SMTP client lexically identifies a domain to which mail will
be delivered for processing (as described in sections 3.6 and 3.7), a
DNS lookup MUST be performed to resolve the domain name [22]. The
names are expected to be fully-qualified domain names (FQDNs):
mechanisms for inferring FQDNs from partial names or local aliases
are outside of this specification and, due to a history of problems,
are generally discouraged. The lookup first attempts to locate an MX
record associated with the name. If a CNAME record is found instead,
the resulting name is processed as if it were the initial name. If
no MX records are found, but an A RR is found, the A RR is treated as
if it was associated with an implicit MX RR, with a preference of 0,
pointing to that host. If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.
Note that the above clarfies and perpetuates the stupidity of the
"implicit MX" rule, but note too that the first lookup is always going
to be for an MX. You SHOULD ALWAYS use only FQDNs that resolve to MX
records in the domain part of MAIL FROM: and RCPT TO: parameters. Just
because it works without them doesn't mean you should rely on that fact.
Properly documenting your SMTP hosts by giving them all proper MX
records is good not only for you, but for everyone! (As a side note I
should also mention that you cannot send me e-mail unless the domain
part of your sender address, as I receive it, resolves to an MX record,
and I'll further point out that I don't bounce very much e-mail due to
this rule -- less than for any other "correctness" rule I enforce.)
> And MAIL From:
> will almost always have people's workstation in it, which may be very much
> non-deliverable.
That's simply not true, at least not for any client MUA using SMTP to
deliver e-mail. The SMTP Envelope sender address will almost always be
the user's proper address -- the same one you would use in the RCPT TO:
command to send them a message, and so it must be in order for bounce
addressing to work properly.
I've extensiely tested many many many client MUAs in this respect, and
in Smail I've implemented checks to verify that the sender address is
valid, right down to being a valid mailbox if the domain part is locally
deliverable. This works with all clients I've tested so far, at least
so long as they are correctly configured (and the purpose of this check
in smail was to explicitly identify and block e-mail from incorrectly
configured clients -- email that could not be bounced!).
There are many problems with MUAs using command-line invocation of
sendmail or whatever on Unix boxes, but this is mostly because most
client MTAs (or their parent MTAs) are mis-configured.
> Greg> I'm not so sure about that. Any mailer should looks for the A RR
> Greg> (not AAAA) for every MX, and may complain if one is not found....
>
> Then IPv6 will never get deployed if all machines must always be dual stack.
I really don't know what's going to happen for SMTP over IPv6. RFC 2821
still doesn't mention IPv6 w.r.t. DNS (only w.r.t. literal address
representation). Domain names are still only referred to in terms of MX
and A records and there is no mention anywhere of AAAA records. I know
what the logical thing to do is, but it would be nice to see some of the
inticracies spelled out in an RFC. Even RFC 2893 makes no mention of
SMTP (though it does suggest "A6" will supplant "AAAA" records).
> Greg> BTW, those AAAA records are apparently not visible to the world
> Greg> either:
>
> Greg> $ host -a lox6.sandelman.ottawa.on.ca nic.sandelman.ottawa.on.ca
>
> NOX6.
>
> (which is actually for "new lox"...)
Hmmm.... sorry.... very confusing names you're using there! ;-)
> Greg> !!! sandelman.ottawa.on.ca SOA primary istari.sandelman.ottawa.on.ca is not advertised via NS
>
> Greg> $ /sbin/ping ns.flora.ottawa.on.ca
> Greg> PING ns.flora.ottawa.on.ca (209.195.78.66): 56 data bytes
>
> That's a different, more recent problem.
and it's getting worse since you added a third and also unreachable NS
to your zone file:
$ host -C sandelman.ottawa.on.ca
sandelman.ottawa.on.ca NS nic.sandelman.ottawa.on.ca
istari.sandelman.ottawa.on.ca mcr.sandelman.ottawa.on.ca (200109162 3600 900 3600000 3600)
!!! sandelman.ottawa.on.ca SOA primary istari.sandelman.ottawa.on.ca is not advertised via NS
sandelman.ottawa.on.ca NS lotharon.endicor.com
Nameserver lotharon.endicor.com not responding
sandelman.ottawa.on.ca SOA record not found at lotharon.endicor.com, try again
sandelman.ottawa.on.ca NS ns.flora.ottawa.on.ca
Nameserver ns.flora.ottawa.on.ca not responding
sandelman.ottawa.on.ca SOA record not found at ns.flora.ottawa.on.ca, try again
Having one lame or unreachable server makes things slow -- having two
lame or unreachable servers makes things slower than molasses in
January!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@???> <woods@???>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
